diff options
| author | Max Kellermann <max@duempel.org> | 2013-11-08 11:54:30 +0100 |
|---|---|---|
| committer | Max Kellermann <max@duempel.org> | 2013-11-08 12:02:21 +0100 |
| commit | 2789493a5f6bdc8239c321c9d15987bf596f0b09 (patch) | |
| tree | acc56cfa51645a6d22eb52fb1f2227726abb56a0 /src/PlayerThread.cxx | |
| parent | 4ed06354474141059db90a2aa6dab1edcebdd78c (diff) | |
| download | mpd-2789493a5f6bdc8239c321c9d15987bf596f0b09.tar.gz mpd-2789493a5f6bdc8239c321c9d15987bf596f0b09.tar.xz mpd-2789493a5f6bdc8239c321c9d15987bf596f0b09.zip | |
PlayerThread: fix stuck MPD after song change (0.18.2 regression)
Commit 77c63511 caused MPD to become stuck right after a song change.
The problem was that at some point, the MusicBuffer became full, and
the DecoderThread working on the next song waits for the PlayerThread.
However, the PlayerThread was stuck in a loop of g_usleep() calls, and
never bothered to tell the DecoderThread that the MusicBuffer is not
full anymore. This bug is very old, but its chance to occur went from
nearly 0% to nearly 100%.
The fix is to wake up the DecoderThread before waiting for it. As a
side effect, I replaced the g_usleep() call with a Cond::Wait() call.
Diffstat (limited to 'src/PlayerThread.cxx')
| -rw-r--r-- | src/PlayerThread.cxx | 12 |
1 files changed, 8 insertions, 4 deletions
diff --git a/src/PlayerThread.cxx b/src/PlayerThread.cxx index cb3d6a9a4..6fb41bf35 100644 --- a/src/PlayerThread.cxx +++ b/src/PlayerThread.cxx @@ -36,8 +36,6 @@ #include "util/Domain.hxx" #include "Log.hxx" -#include <glib.h> - #include <string.h> static constexpr Domain player_domain("player"); @@ -1043,8 +1041,14 @@ Player::Run() output thread is still busy, so it's okay */ - /* XXX synchronize in a better way */ - g_usleep(10000); + pc.Lock(); + + /* wake up the decoder (just in case it's + waiting for space in the MusicBuffer) and + wait for it */ + dc.Signal(); + dc.WaitForDecoder(); + continue; } else if (IsDecoderAtNextSong()) { /* at the beginning of a new song */ |