shorter
Signed-off-by: Rosen Penev <rosenp@gmail.com>

SonarLint reports the latter to be better:

std::scoped_lock basically provides the same feature as std::lock_guard,
but is more generic: It can lock several mutexes at the same time, with a
deadlock prevention mechanism (see {rule:cpp:S5524}). The equivalent code
to perform simultaneous locking with std::lock_guard is significantly more
complex. Therefore, it is simpler to use std::scoped_lock all the time,
even when locking only one mutex (there will be no performance impact).
Signed-off-by: Rosen Penev <rosenp@gmail.com>

From the feature request: "I generally like to have crossfade on, but
when it happens during such short tracks (e.g. 20 seconds or less) it
doesn't really sound good as those tracks are not really meant to be
crossfaded and intended to act as a bridge on their own."

Sounds reasonable.  This commit doesn't add an option, but hard-codes
the limit to 20 seconds.  If it turns out that users want to have it
configurable, we can still add the option.

Closes https://github.com/MusicPlayerDaemon/MPD/issues/1184

"DEFAULT" is a bad name - all it says is that it's the default value,
but it doesn't say what it means.  The name NOTICE mimics the syslog
level.

This fixes a spurious "single" mode bug which occurs when using "play"
or "seek" to start playback on the song that is currently paused: in
that case, the main thread never queues the next song, and at the end
of the song, the player thread exits Run(), stopping playback, and
after that, the main thread starts the next song without considering
"single" mode.

By calling OnPlayerSync(), we ensure that the main thread gets a
chance to queue the next song before the player thread exits the Run()
loop.

Closes https://github.com/MusicPlayerDaemon/MPD/issues/850

When the client wants to seek, but the decoder has already finished
decoding the current song, the player restarts the decoder with an
initial seek at the new position.  When this initial seek fails, MPD
pretends nothing has happened and plays this song from the start.

With this new flag, a restarted decoder marks the initial seek as
"essential" and fails the decoder if that seek fails.

Closes https://github.com/MusicPlayerDaemon/MPD/issues/895

Without this, the Pause() call would drop the ring buffers and would
skip a considerable portion of the end of the song.

Closes https://github.com/MusicPlayerDaemon/MPD/issues/824

Signed-off-by: Rosen Penev <rosenp@gmail.com>

Introduced in C++17. It replaces gcc's warn_unused_result.

Found with modernize-use-nodiscard.
Signed-off-by: Rosen Penev <rosenp@gmail.com>

Found with modernize-use-bool-literals
Signed-off-by: Rosen Penev <rosenp@gmail.com>

Works around build failures with ccache which may feed processed code
to GCC, which doesn't have the "fall through" code comments.

The check IsSeekableCurrentSong() was added by commit
44b20024 in version 0.20.19, but it
caused a regression: by doing the branch only if the current song is
seekable, the player would restart the current song if it was not
seekable, and later the initial seek would fail; but we already know
it's not seekable, and so we should fail early.

This reverts commit ff3e2c05.  The
check was necessary, after all, because this is what checked whether
the decoder had finished the current or the next song.

> The "queued" flag can only possibly be set if the decoder is still
> decoding the current song or if the decoder is stopped.

That was wrong because ProcessCommand() sets `queued=true` and also
starts the decoder (if it was idle).

> This is also what the following assert() checks.

That was also wrong, because the assert() has two conditions.

Closes https://github.com/MusicPlayerDaemon/MPD/issues/566

If the decoder finishes decoding the current song between the two
IsIdle() checks, MPD stops playback instead of starting the decoder
for the next song.

This is usually not visible problem, because the main thread restarts
it via playlist::ResumePlayback(), but that way it, ignores "single"
mode.

As a workaround, this commit adds another "queued" check which
re-enters the player loop and checks again whether to start the
decoder.

Closes https://github.com/MusicPlayerDaemon/MPD/issues/556

The "queued" flag can only possibly be set if the decoder is still
decoding the current song or if the decoder is stopped.  This is also
what the following assert() checks.  This check was not necessary.

Since we switched from autotools to Meson in commit
94592c14, we don't need to include
`config.h` early to properly enable large file support.  Meson passes
the required macros on the compiler command line instead of defining
them in `config.h`.

This means we can include `config.h` at any time, whenever we want to
check its macros, and there are no ordering constraints.

This fixes a valgrind warning because `buffer_before_play`
initialization needs to know the audio format from the decoder.

This emits the event even if PlayerControl::Play() is used to replay
the current song, which emits the missing "player" idle event.

Closes #381

Previously, there was the setting `buffered_before_play` which
specified a percentage of the audio buffer, defaulting to `10%`.  That
was working well enough for quite some time, until high-quality audio
formats became common.

At 44.1 kHz, 16 bit stereo, MPD collected 2.3 seconds worth of data in
the buffer before starting playback.  With the same default settings
and 192 kHz, 24 bit stereo, that was only 0.27 seconds.

Making this depend on the byte size only leads to high latency at low
quality, and too little data at high quality.  The natural choice
would be to use a duration instead of a byte size, which should give
the same good experience with all audio formats.

Since the `buffered_before_play` configuration setting was not
understood well by users and caused more harm than good, this commit
deprecates it.  It has now no effect.

Simplify the formula, and I guess this makes the formula more
reliable.  Imagine somebody configured `buffered_before_play` larger
than 25%; then the decoder would be woken up all the time.  This
doesn't seem logical.  On the other hand, it's easy to understand that
the decoder should be woken up below 75% buffer fill.

Calculate the value only once.

Shouldn't ever happen, but who knows...