Music Player Daemon

MPD doesn't handle chapters then. It doesn't know about chapters; this is a feature that would need to be implemented in the first place.

I don't see your configuration. You showed two one-line snippets but I don't know if you used both at the same time or switched from one to the other - you posted just two lines without any context. But since those two lines (obviously) conflict with each others, I don't know if there's a MPD bug or...

Much of the discussion centres around how good various versions of MPD sound. Almost all of this discussion is bullshit. My assumption is that someone or a group of people listen to each release before it's released. None of that ever happened. Nobody ever does a listening test before a MPD release...

Seriously, did you read https://www.musicpd.org/help/ ?
"When you do request help, post the following data ..."

It would be possible to write a simple client which copies one instance's state to another instance. But I don't know if such a thing exists. Maybe this would be a useful feature for "mpc".

Duplicate of viewtopic.php?f=8&t=7797

The mount process is finished when the command finishes. But that doesn't imply that the database update is finished at the same time, just like regular database updates aren't finished then. To wait for update completion, use `mpc update --wait`. But that has nothing to do with mounting, that's how...

Of course you can, it's open source! Technically, you don't need that script I linked to, it is just a convenience script to make building for Android easier. You can compile all libraries for Android manually and then use meson/ninja as usual to build MPD for Android. There are more output plugins ...

No, because anybody may do his own build with his arbitrary choices of plugins.

But these are the libraries I compile for Android prior to building MPD; the according plugins are thus enabled in my MPD/Android builds:

https://github.com/MusicPlayerDaemon/MP ... #L169-L179

This crash is inside your dynamic linker and has nothing to do with MPD.

Every MPD source tarball contains full documentation in the "doc" directory. The one on the MPD website is just a copy of that. This has nothing to do with real-time scheduling (MPD 0.20 had that as well, added in v0.19) - this bluez-alsa bug was revealed by a different MPD change which switched the...

I, too, fear this bluez-alsa bug will never be fixed. The bluez-alsa developer appeared to be unconvinced that this is really his bug. Pity.

This is a known bluez-alsa bug, see:

https://github.com/MusicPlayerDaemon/MPD/issues/432
https://github.com/MusicPlayerDaemon/MPD/issues/548
https://github.com/Arkq/bluez-alsa/issues/174

This must be fixed in bluez-alsa.

Just in case "21.4" means "MPD 0.21.4": your MPD version is ten bug-fix releases behind and thus unsupported. If this still occurs with the latest version, write a bug report, and provide more information. (Why do you believe the elapsed time should change? You did not mention that you're currently ...

Never do `mpc ls|mpc add`. This is bloated, error prone and fragile.

You can write `*.mp4` in your `.mpdignore` and MPD will ignore those files during database update.

Then you should configure the "proxy" to connect to port 6700.

Your configuration doesn't make sense. You configured port 6600, but what port is your first MPD running on? And your "proxy" database by default connects to localhost:6600, which means your second MPD connects to itself.

By creating a second configuration file with a different port and different output configuration, optionally attached to the first MPD with the "proxy" database plugin (https://www.musicpd.org/doc/html/user.html#satellite). Then you can create a copy of "mpd.service" which specifies the second confi...