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/decoder/FfmpegMetaData.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/decoder/FfmpegMetaData.cxx')
0 files changed, 0 insertions, 0 deletions