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.
Allows big-endian users to configure the fallback byte order to
little-endian. Without this setting, MPD assumes native byte order if
the CD drive can't decide.
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.
Add a new CommandResult code called "FINISH" which, unlike "CLOSE",
will attempt to flush the output buffer. This is a one-shot attempt;
it will do one write, and not try again.
Postpone the write using IdleMonitor instead of scheduling a write
event. This reduces the number of system calls, because we don't need
to register and unregister the write event in epoll.
Prior to version 0.3, the "length" callback returned a "long" instead
of AFfileoffset. Now that this API bug fix is a few years old, let's
drop 0.2 support for good.
Migrate from the old curl_multi_perform() API to the newer
curl_multi_socket_action() API (since CURL 7.16).
This allows working around a bug with HTTP redirections with epoll:
when CURL closes a socket and the new one happens to have the same
file number, MPD did not have a chance to remove the old one from
epoll and subsequently attempted to use EPOLL_CTL_MOD, which was not
allowed by epoll, because it's a new socket now.
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".
This prevented using the "volume_normalization" feature with some
codecs (e.g. mp3), because the normalization code requires 16 bit
samples. If the codec happens to deliver formats other than S16, the
AutoConvert filter succeeds to initialize the conversion filter, but
the returned input audio format was wrong.
Max Kellermann