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.

PlayerThread: fix stuck MPD after song change (0.18.2 regression)
2789493a · Max Kellermann · 4ed06354 · 2789493a · 2789493a
Commit 2789493a authored Nov 08, 2013 by Max Kellermann
Hide whitespace changes
Inline Side-by-side

Showing with 9 additions and 4 deletions

NEWS NEWS +1 -0

PlayerThread.cxx src/PlayerThread.cxx +8 -4

No files found.
--- a/NEWS
+++ b/NEWS
 ver 0.18.3 (2013/??/??)
+* fix stuck MPD after song change (0.18.2 regression)

 ver 0.18.2 (2013/11/07)
 * protocol:

--- 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 */