From 2789493a5f6bdc8239c321c9d15987bf596f0b09 Mon Sep 17 00:00:00 2001 From: Max Kellermann Date: Fri, 8 Nov 2013 11:54:30 +0100 Subject: 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. --- src/PlayerThread.cxx | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) (limited to 'src/PlayerThread.cxx') 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 - #include 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 */ -- cgit v1.2.3