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.
After the number of decoded chunks has fallen below the threshold, the
PlayerThread woke up the DecoderThread over and over. This commit
adds a boolean flag that avoids these duplicate wakeups, and thus
reduces the number of system calls.
Map LogLevel::INFO to G_LOG_LEVEL_INFO, and LogLevel::DEFAULT to
G_LOG_LEVEL_MESSAGE. Now client connect/disconnect message are only
logged on log_level "secure".
Share the Mutex between the DecoderThread and the PlayerThread. This
simplifies synchronization between the two threads and fixes a freeze
problem: while the PlayerThread waits for the DeocderThread, it cannot
answer requests from the main thread, and the main thread will block
until the DecoderThread finishes.
Finally restores an important feature that has been broken for several
months when the PlayerThread started working with Song copies instead
of pointers to the Queue's Song instances (commit e96779d).
Fixes a regression from 752dfb3d95 which
caused the current chunk to be flushed as soon as new replaygain
information was found. If this occurs on a tag chunk, it has no data
(length 0) and is then skipped before pushing it to all of the outputs.
This change allows 0-length chunks through if they contain a tag and
they are now appearing in mplayer and mpv properly.
This fixes a deadlock bug introduced by 18076ac9. After all, the
second Cond was necessary.
The problem: two threads can wait for a signal at the same time. The
player thread waits for the output thread to finish playback. The
main thread waits for the player thread to complete a command. The
output thread finishes playback, and sends a signal, which
unfortunately does not wake up the player thread, but the main
thread. The main thread sees that the command is still not finished,
and waits again. The signal is lost forever, and MPD is deadlocked.
