Commit 13208bf5a7 added range support to
the `move` command, but applied the wrong offset to the `to` variable.
When the source range is before the current song, and the song thus
gets decremented by the range size, then the final destination offset
must also be decremented by the range size.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/663
On linux-rt, kernel IRQ threads are configured with priority=50, and
this change configures MPD somewhat below that priority, leaving some
room for other programs to be configured in between.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/643
Without requesting the property, "good" WebDAV servers would not send
it, and so MPD could never recognize a directory, failing the database
update.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/660
Apparently, libmpcdec sets gain/peak variables to zero if they are not
present. This clashes with our formula and results in bogus values
which cause noise during playback.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/640
This commit adds a PlaylistPlugin attribute "as_folder" which for now
is only enabled in the "CUE" playlist plugin (which handles separate
"*.cue" files). If a playlist with this flag set is being scanned
during database update, it will be parsed and its contents will be
added to the database. This allows clients to inspect them like
directories and its contents will be searchable.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/39
The new Response instance in the `catch` block didn't have the
`command` attribute set, so the error response didn't indicate which
command had failed, which however is required in the MPD protocol.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/628
SID files are generally collections of tunes, so a SID name field makes
sense as an MPD album. The SID tune information list (STIL) has name
and title fields for individual tunes, when such are known, but MPD is
currently not using the STIL.
High Voltage SID Collection (HVSC) metadata fields are encoded in
windows-1252, as described in DOCUMENTS/SID_file_format.txt:
https://www.hvsc.c64.org/download/C64Music/DOCUMENTS/SID_file_format.txt
If utf-8 transcoding fails, or the ICU library is unavailable, fall
back to plain ASCII and replace other characters with '?'.
Version 10.2+0.93+1 was released five years ago in 2014 and is the
first version to feature cdio_cddap_free_messages(). There is no way
to check the libcdio-paranoia version at compile time, so let's just
remove support for older versions instead of attempting to fix the
cdio_cddap_free_messages() check at build time.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/613
This reverts commit f7ed7446ae. It was
a bad idea, because MAD_F_MIN and MAD_F_MAX do not represent the
clamping limits, but the theoretical minimum and maximum values of the
mad_fixed_t data type.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/617
This is useful in multiple mpd instances scenario, or multiple pulse outputs defined on the same mpd instance.
It is actually a more flexible way to route flows than the "sink" parameter, letting the PulseAudio routing do its job, but with the ability to isolate routing for each output.
If not specified, the role remains like it was before this commit, ie "music"
The check IsSeekableCurrentSong() was added by commit
44b200240f 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.
Applying software volume to S16 samples means several bits of
precision are lost; at 25% volume, two bits are lost. Additionally,
dithering adds some noise.
The problem gets worse when you apply the software volume code twice:
for the software mixer volume, and again for the replay gain. This
loses some more precision and adds even more dithering noise, which
can become audible (see
https://github.com/MusicPlayerDaemon/MPD/issues/542).
By converting everything to 24 bit, we need to shift only two bits to
the right instead of ten, losing nearly no precision, and dithering is
not needed. Even if the output device is unable to play S24 directly,
we can convert back to S16 with only one stage of dithering.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/542
MPD used to do that when this code lived in the player thread, but it
was removed by commit 98a7c62d7a4f716d90af6d78e18d1a3b10bc54b3; and
the replacement code in the ALSA output plugin didn't have it.
Without this timer, DispatchSockets() may disable the
MultiSocketMonitor and if Play() doesn't get called soon, it never
gets a chance to generate silence. However if Play() gets called,
generating silence isn't necessary anymore...
Resulting from this misdesign (added by commit ccafe3f3cf in 0.21.3),
the silence generator didn't work reliably.
Apparently, if snd_pcm_drain() returns EAGAIN, it does not actually
want to be called again; the next call will snd_pcm_drain() will also
return EAGAIN, forever, even though the PCM state has meanwhile
switched to SND_PCM_STATE_SETUP. This causes a busy loop; to fix
this, we should always check snd_pcm_state() to see if draining is
really required.
Workaround for a regression caused by commit
a06bf388d9, revealing a problem with
discarding odd numer of frames in the DSD_U32 and DoP converters,
causing distortions with DSD_U32 and DoP on 32 bit CPUs.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/469
Instead of passing tag and group, pass an array of tags. To support a
nested return value, return a nested std::map of std::maps. Each key
specifies the tag value, and each value may be another nesting level.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/408
Since we now don't duplicate all items, we can easily remove the 64kB
limit from OpusReader::ReadString() and instead silently ignore and
skip all strings which are longer than 4 kB.
This fixes a tag duplication bug with Opus file containing a very long
`METADATA_BLOCK_PICTURE` tag, which occurred because the Opus plugin
returned false after parsing all tags, and then the MPD core fell back
to FFmpeg which scanned the tags again.
Return `404 not found` for some common well-known paths, as clients requesting them usually do that automatically and don't expect endless audio stram.
Closes#572
This reverts commit ff3e2c0514. 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
Commit b3a458338a added a LocateUri()
call to several playlist commands, which applied InputPlugin URI
scheme verification to playlist URIs. This broke the SoundCloud
playlist plugin which uses "soundcloud://" URIs for which no input
plugin exists.
This commit allows the caller to specify the kind of plugin which
shall be used to verify the URI. Right now, only "input" is
implemented; "storage" uses the "input" verification for now; and
"playlist" has no verification at all (for now).
Closes https://github.com/MusicPlayerDaemon/MPD/issues/528
smutbert