On Mon, Feb 17, 2014 at 11:26:11 -0500, Ben Boeckel wrote:
> Hmm. mpc reports it as being 'off'. If I set it manually with 'mpc
> single off', it still occurs. Same if I turn it on and still when I turn
> it off again. Some bookkeeping gone wrong?
Skimming the git logs, some commits which stood out to me as being possibly
relevant:
commit 4ee147ea34057c0bcef31afed55f98b025b997dc
Author: Max Kellermann <[email protected]>
Date: Wed Nov 13 20:57:09 2013 +0100
DecoderAPI: stop decoder on MPD error
This commit adds the basic infrastructure for reporting bugs from
DecoderAPI.cxx via DecoderThread.cxx to DecoderControl.
commit 2789493a5f6bdc8239c321c9d15987bf596f0b09
Author: Max Kellermann <[email protected]>
Date: Fri Nov 8 11:54:30 2013 +0100
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.
The thing is that no error is reported in the logs, so the first may not be it.
I wonder if the second commit I listed isn't a complete fix? I'll try and get a
bisect going tonight to pin it down (and test if it's still in the latest
release).
--Ben
_______________________________________________
mpd-devel mailing list
[email protected]
http://mailman.blarg.de/listinfo/mpd-devel
