Music Player Daemon

says the `name` directive should correspond to the name the pulse server uses internally. What does that mean? No, it doesn't say that. It says "Some plugins also use it internally, e.g. as a name registered in the PULSE server." This means that the PulseAudio output plugin transfers this name to t...

Derive from `class SocketMonitor`: https://github.com/MusicPlayerDaemon/MP ... onitor.hxx
... and implement the virtual method `OnSocketReady()`.
Call `Schedule*()` to start polling for events, and `Cancel()` to stop polling.

Example, old and bugged (indentation added for readability): Album: Brave New World Artist: Styx Artist: Iron Maiden Date: 2000 Date: 1999 The top level is "Album" (i.e. grouped by "Album", which is contrary to what you requested), followed by a list of all artists, followed by a list of all dates. ...

The date doesn't belong to an artist, it belongs to an album. I don't think that's correct. There can be multiple artists for one album because multiple artists can publish albums under the same name, and then those distinct albums have different dates. For example, Styx have released the album "Br...

And how do you know which Date value belongs to which Artist?

I have no idea how you did it previously, because as I said, the response did not make sense and did not do what was documented. Why do you believe the "new format" is "harder to handle"? (Note, it's not the "new format" - it's the old format, the one that has always been documented.) What's really ...

The original "group" implementation was bugged; it did not work as documented, and the way it worked, it did not make any sense. Therefore, it was fixed in MPD 0.20.22 two years ago, to follow the documentation.

You need a tiny client which listens for "mixer" events and then reads the volume level from MPD, transmits it to your amplifier, and gets back to waiting for more "mixer" events.

So this was all about hardware which was too slow for the configuration you chose.

MPD has no such plugin, because nobody was interested in writing one. But it would be possible to write one.

There is a way, but you need to write a dedicated client for bridging between MPD's null mixer and your amplifier.

Because the configuration sample is wrong. It doesn't disable resampling, because it is not possible to disable resampling. The option "enabled" does not exist in the "resampler" block. See https://www.musicpd.org/doc/html/plugin ... er-plugins

Obey the message: it is about the FFmpeg input plugin, but you tried to disable the FFmpeg decoder plugin.

Randomly playing around with settings seems more like a playful waste of time than productive problem solving.

A lower bit rate will not reduce the CPU load for resampling.

Nearly all CPU time is spent on resampling. Since I don't have any information about your setup, I can't give any help here. Read https://www.musicpd.org/help/ if you need more help. But what I can say: renicing the process will not solve the problem. If MPD doesn't compete with other processes for ...

Looks like you deleted the file /etc/default/mpd which is part of the package. You need to restore it.

Your MPD version is 21 bug-fix releases behind. First you should update. If this still happens, post a "perf report" of this high CPU usage.

You can use "addid" which returns the song id of the new queue item, and then use "playid" to play that one.

This error you're seeing is a FFmpeg error. But I don't know why the FFmpeg library fails, while the "ffmpeg" command-line tool does not.