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
The log levels have always been very confusing (and badly named), but
this was most confusing: if there's a log level called "default", why
is it not the default?
Closes https://github.com/MusicPlayerDaemon/MPD/issues/926
Oh the horror! This plugin cannot possibly ever have worked. It was
broken from the start, when it was added in commit 37796699cf nearly
twelve (!) years ago.
The plugin would always read at sector boundaries, so it could only
ever work at multiples of 2 kB.
While libsndfile doesn't like partial reads in the middle of a file
(see commit 95ac6071b9), it allows partial reads at the end of a file.
It doesn't pay attention to the file size when issuing a read.
Commit ecb67a1ed1 (MPD 0.18.12) was a regression: previously,
partial reads at the end of a file were possible, but switching to
decoder_read_full() made this an error condition. This way, a portion
at the end of each file was lost, leading to corruption with gapless
playback (https://github.com/MusicPlayerDaemon/MPD/issues/936).
This fix switches to the newly introduced function
decoder_read_much(), which does the same as the code before commit
ecb67a1ed1.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/936
Our AudioObjectGetPropertyDataT() wrapper throws exception on error,
and calling it from OSXOutput::Disable() can cause MPD crash due to
std::terminate().
Closes https://github.com/MusicPlayerDaemon/MPD/issues/932
When mounting something over a directory that is already a mount
point, CompositeStorage::Mount() silently overwrites the previously
mounted storage, disposing it. After that, SimpleDatabase::Mount()
will fail and handle_mount() will roll back the
CompositeStorage::Mount() command, effectively unmounting what was
there before (and also leaking memory).
Closes https://github.com/MusicPlayerDaemon/MPD/issues/918
Bug #915 is about an I/O exception thrown where none was allowed,
leading to crash via std::terminate(). However, instead of catching
and logging the error inside the decoder plugin, it should be able to
propagate the I/O error to the MPD core, so MPD can avoid trying other
decoder plugins.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/915
The formula in osx_output_score_sample_rate() to detect multiples of
the source sample rate was broken: when given a 44.1 kHz input file,
it preferred 16 kHz over 48 kHz, because its `frac_portion(16)=0.75`
is smaller than `frac_portion(48)=0.91`.
That formula, introduced by commit 40a1ebee29, looks completely
wrong. It doesn't do what the code comment pretends it does.
Instead of using that `frac_portion` to calculate a score, this patch
adds to the score only if `frac_portion` is nearly `0` or `1`. This
means that the factor is nearly integer.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/904
A bug report (https://github.com/MusicPlayerDaemon/MPD/issues/912)
suggests that on Linux, reading on `cifs` files may rarely return 0 (=
end of file) before the end of the file has really been reached. But
that's just a theory which I need to validate, so this runtime check
shall catch this condition before the assertion in
DecoderBridge::Read() crashes MPD. Let's see.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/912
An assertion failure in UpdateQueuedSong() could trigger because the
`prev` parameter is always `nullptr`, but `queued` may be set. And in
fact, calling UpdateQueuedSong() is only necessary when the queued
song was edited, to re-queue it with the new range.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/901
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
