for a client connection. It works like the tag_mask and the associated
tagtypes command.
New commands:
- protocol
Shows enabled protocol features.
- protocol available
Show all available protocol features.
- protocol enable {feature...}
Enables protocol features.
- protocol disable {feature...}
Disables protocol features.
- protocol all
Enables all available protocol features.
- protocol clear
Disables all protocol features.
This commit adds also the first protocol feature.
hide_playlists_in_root
Disables the listing of playlists in the root folder
for the lsinfo command.
This allows keeping the ALSA PCM open even if playback is paused. As
a side effect, this allows using the "always_on" option with ALSA
outputs, because "always_on" pauses the output.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/1623
This commit adds the `SHOWMOVEMENT` [tag](https://picard-docs.musicbrainz.org/en/appendices/tag_mapping.html#show-work-movement-4). Historically, this tag originates from iTunes' MP4, but has since become widely used. It is created by Picard's Classical music [plugins](https://picard-docs.musicbrainz.org/en/variables/variables_classical.html) (such as "Classical Extras" or "Work & Movement").
The reasoning behind this tag is to display Work & Movement titles without redundant information and in a more uniform way. Moreover, it additionally serves as an implicit marker denoting classical music tracks (genre tags aren't sufficient).
If the client so chooses to support this tag, they can display `Work` and `Movement` instead of the track title allowing for cleaner display. Other clients can continue to display the `%title%` as before without any fuss.
There were a few macOS related bug reports on the bug tracker which
have been open for years without a volunteer caring for them. The
GitHub actions build has also been broken for a long time due to bugs
in the ancient LLVM toolchain shipped with macOS, making macOS an
unsuitable non-Linux target for testing MPD's portability.
All of this makes macOS support an annoying liability for me. To
avoid more frustration, I'm hereby dropping macOS support completely
from MPD. Maybe this causes enough pain for a new maintainer to
spawn, but maybe nobody cares, so... let's see.
libmad hasn't been maintained for many many years, while libmpg123 is
still maintained.
Our "mad" plugin can't do streams, but MPD will automatically fall
back to "mad" (or "ffmpeg") for streams.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/1954
Since the very beginning when idle subscriptions where introduced
(commit 0bad84066b), waiting for a certain idle mask would clear
all other idle flags as well. This would cause idle events to get
lost.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/1998
Previously, inode numbers were truncated to 32 bits, which could lead
to problems on XFS where inodes are 64 bit; this could lead to bogus
"recursive directory found" errors during database update.
[mk: added commit description and NEWS line]
Closes https://github.com/MusicPlayerDaemon/MPD/issues/2000
The three new compare operators "eq", "gt" and "lt" are casting the values to int.
Sort supports:
- uri: sort by uri
- value: sort by value as string
- value_int: casts value to int
Closes#1894
Some ALSA capture devices can have very large buffers, holding 10
seconds or more audio. Using the maximum buffer size with such
devices leads to unacceptably large, and unnecessary, latency.
Also, some ALSA drivers (e.g. HDA Intel PCH) report an invalid
maximum period size, and the period size that mpd calculates from
the maximum buffer size results in "Invalid argument" error when
applying the hw_params. Note that the "default" capture device on
many cards includes the "dsnoop" plugin which imposes a buffer
size of 16384 frames, so that "alsa://" works OK but
"alsa://plughw" or "alsa://hw" both fail.
Limit the maximum buffer time for ALSA input devices to a more useable
2 seconds, thereby avoiding both the above problems.
Max Kellermann