From now on, struct Song will be used by the database only, and
DetachedSong will be used by everybody else. DetachedSong is easier
to use, but Song has lower overhead.
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.
