support multiple music_directory paths

[twojstaryzdomu]

Feature request

MPD appears to support a single music_directory path. Enabling additional directories via multiple music_directory calls would be a convenient feature.

A single music_directory works only on the assumption the user keeps their music in a single location. Some users may have their music on multiple drives, including removable ones, which they may be connecting at any time when MPD is already running.

Failure to find the directory at start time should not be taken as assumption the path won't ever become available during the lifetime of the MPD process.

The simplest use case for missing paths at start time is for use with removable media, which sit in mountpoints under /media/<username> (controlled by udisks2), which may not be present if no removable media is inserted. It would be up to the user to scan the media, so polling for changes (with auto_update) need not apply to the directory.

To clarify how it would work: a user could set their local music_directory and add a second music_directory clause pointing to /media/<username>. The former would work with auto_update, whilst the latter path would be scanned for files whenever the user specifically requests MPD to do so.

[MaxKellermann]

How would this work, at the protocol level? Do you know that MPD can integrate with udisks2 to integrate removable media into its database?

[twojstaryzdomu]

Reading through the code, I've just stumbled upon the udisks2 plugin. Does it support any media inserted, by specifying udisks://, without the label or name? If the label of the media has to be known upfront, it may be difficult to use without access to the MPD configuration (other than a rescan option, which again may be automated by including udev rule whenever a user inserts or removes removable media). Users expect to insert and remove media without making configuration changes every time a new one is added.

At protocol level, supporting multiple paths, with non-existent ones at mpd start time, may require three changes, if there isn't already code present to enable those:

1. MPD needs to virtualise all music_directory paths provided in a common structure. Be aware some music may be available locally, and some sit on removaable media. A user will want to access both. Failure to find a path should prompt for MPD to record it for a subsequent rescan.
2. Auto_update needs to be aware of path type at any given time. Any non-existent paths are assumed to be unpollable and excluded from auto_update. If a path becomes missing and unpollable, such as caused by removing a usb stick, auto_update ignores it until a rescan.
3. At user requested rescan time, MPD attempts to walk all the paths including non-existing ones. Existing paths that become non-existent are flagged as non-existent and their music directory contents removed until a future rescan. Failure to access a path prompts MPD to add it to the non-existing path list, pending a future scan.

The reason why considering non-existing path is needed is simple: without any media inserted, /media/<username> is missing, so it is not possible to use /media/<username> as a generic placeholder for all removable media, without seeing the message "exception: Failed to access /media/<username>: No such file or directory".

[MaxKellermann]

Reading through the code, I've just stumbled upon the udisks2 plugin. Does it support any media inserted, by specifying udisks://, without the label or name?

No. You can obtain a list of available media using the listneighbors command, see https://mpd.readthedocs.io/en/latest/protocol.html#mounts-and-neighbors because udisks is both a storage and a neighbor plugin, see https://mpd.readthedocs.io/en/latest/plugins.html#neighbor-plugins

At protocol level, supporting multiple paths, with non-existent ones at mpd start time, may require three changes, if there isn't already code present to enable those:

None of those 3 changes describe how this works at the protocol level, because none of this is about the protocol.

When you do "lsinfo", which music_directory will be displayed?

[twojstaryzdomu]

It wasn't clear it was MPD internal protocol that you meant.

music_directory "/media/<username>"
music_directory "/misc/local"

lsinfo displays whichever directory is configured last as music_directory. Any earlier directory does not appear to be looked at. From the example above, /misc/local comes last so that's what is examined for music. /media/<username>, whether present or not, won't be examined. Granted, if the order were reversed, i.e.

music_directory "/misc/local"
music_directory "/media/<username>"

the user's removable media directory coming last, it would be examined at a user initiated rescan, even if originally missing at MPD start time.

Still, only a single path is supported. True, protocol may require some constructs for adding/removing paths. To extend the present syntax, for adding & removing paths, the following config file parameters could work:

music_directory+ <path>
music_directory- <path>

That way, the compatibility with the existing behaviour of music_directory, where the last parameter provided overrides earlier ones, would be maintained.

[muesli4]

I just tested the udisks neighbor plugin and it seems to work fine. I guess the only issue related to this is the static nature of the current approach. This could be solved if the clients themselves implement the neighbor and mounting functionality. But this still puts a burden on the user to manually add it every time and the client.

One could write a separate MPD client to deal with neighbor events and then just mount them and do some action (see blocker here https://github.com/MusicPlayerDaemon/MPD/issues/1270). I guess this is the least invasive solution. Otherwise, MPD itself could provide this auto-mount functionality. But I do not know how it works with the other neighbor plugins.

And then there is the issue about what should happen if you have songs in the queue or some playlist and unplug it (see https://github.com/MusicPlayerDaemon/MPD/issues/1142).

[twojstaryzdomu]

All of tgis

I just tested the udisks neighbor plugin and it seems to work fine. I guess the only issue related to this is the static nature of the current approach. This could be solved if the clients themselves implement the neighbor and mounting functionality. But this still puts a burden on the user to manually add it every time and the client.

One could write a separate MPD client to deal with neighbor events and then just mount them and do some action (see blocker here #1270). I guess this is the least invasive solution. Otherwise, MPD itself could provide this auto-mount functionality. But I do not know how it works with the other neighbor plugins.

And then there is the issue about what should happen if you have songs in the queue or some playlist and unplug it (see #1142).

Clients typically lag behind in functionality and tend to overlook features overly complex to implement or such that users won't ever look at.

While a udisks plugin certainly showcases functionality of MPD, it won't be used much unless you are in the position to perform media discovery, uuid look ups only to mount a usb drive. Not many users will. Many (like myself) will depend on a set and forget configuration.

This request isn't about removable media anymore. It's up to the user what directories to set up for MPD. The requested feature would benefit any use case with music in multiple directories.

The existing removable media mounting mechanism in most OS distributions is perfectly fine for the job of mounting media. No plugins are strictly necessary to support adding/removing multiple media. Let KISS prevail here. Many unnecessary problems mentioned in your post could be avoided, had there been support for multiple directories in MPD.

[muesli4]

Clients typically lag behind in functionality and tend to overlook features overly complex to implement or such that users won't ever look at. [..] This request isn't about removable media anymore. It's up to the user what directories to set up for MPD. The requested feature would benefit any use case with music in multiple directories.

I would assume since udisks2 is also available as storage plugin you should be able to set it up in the configuration exactly as you intend to. There is just a little bit of documentation lacking there.

[twojstaryzdomu]

I would assume since udisks2 is also available as storage plugin you should be able to set it up in the configuration exactly as you intend to.

No, I'm not aware the udisks plugin works that way. You need to list the media manually with one plugin then mount them or input the device UUID upfront. Too much hassle if the goal is to access the media already automounted under /media by the OS.

There is just a little bit of documentation lacking there.

Indeed, the non-existent documentation is poor encouragement for the layman to try them out. I did and these plugins are impractical in an static configuration environment, with limited access by users.

Most clients support rescanning so users can perform that step easily themselves without raw access to the obscure interface that plugins currently use. The OS is doing the automounting just fine. All that is missing is support for multiple music_directory locations (with one of them being /media in my use case).

Given the multitide of options in MPD, partitions, multiple music outputs, etc., I was surprised NOT to find support for multiple music directories.

[maxmitti]

Correct me if I’m wrong, but can’t you just mount all dynamic mountpoints inside the configured music_directory, or alternatively somewhere else and add symlinks inside the music_directory pointing to the mountpoints?

The same works for multiple directories in general.

On changes you just trigger a rescan as you already suggested.

[twojstaryzdomu]

Correct me if I’m wrong, but can’t you just mount all dynamic mountpoints inside the configured music_directory, or alternatively somewhere else and add symlinks inside the music_directory pointing to the mountpoints?

It's not ideal, it won't work with nfs specific music_directory. Nfs access actually works better in mpd than over a static mount or an autofs, which still suffers from issues, like need to restart the service after a failed attempt to resolve a server name initially or recovery problems. Multiple music_directories give the flexibility to pick any type of sources, be it a path or a plugin, mixing them as needed.

Also, if a linked to directory is ever moved you need to remember to update the links instead of mpd configuration.

[zoj613]

Is it not possible to create a symbolic link to achieve the same effect? Say create one directory that is called /Music/, which contains symbolic links to all other multiple directories that have music.

Music/
    symlink1_pointing_to_music_dir_1
    symlink1_pointing_to_music_dir_2
    symlink1_pointing_to_music_dir_3

and then inside of mpd.conf have music_directory "/Music/" follow_outside_symlinks "yes", and follow_inside_symlinks "yes"

[twojstaryzdomu]

No, it's not the same effect. First of all, you need file system level access in order to be able to do that. Consider working in a limited shell scenario. On the other hand, configuration access may be granted to a single read-write mpd configuration file, but nothing else. Second issue and I think that may be the crux that it does not support mixing plugin music_directory sources (such as nfs://) with a file system-based one. Third, it's a poor man's hack, concealing the fact that mpd does not support multiple music sources at the same time...

[zoj613]

I understand. Maybe someone who is using mpd on a personal computer with music stored in multiple directories (including external harddrives) might find this hack useful in the meantime.

[maxmitti]

Yes, that is what I meant, too. It works well for physically attached storage. It also works with NFS and other stuff that can be mounted on the system level, but as @twojstaryzdomu pointed out it is rather suboptimal.

At least for NFS and other protocols MPD supports the client protocol mount command seems like a good solution to me. Afaik, the mounts are not persisted during MPD restarts, or am I wrong? That would be an important addition I guess.

As for the udisks2 support it might be an idea to make the drive identifiers more useful. Iirc they are not that human-friendly.

Edit: Sorry if some things were answered already. I didn’t see the new responses.

[twojstaryzdomu]

Indeed, @zoj603, you're right as rain and I'd thought of your suggestion as a possible solution before raising the issue.

MPD provides an impressive set of options that extend quite a bit beyond the basic player and yet it falls short in this instance to provide a simple parameter to pick more than one music source.

[maxmitti]

@twojstaryzdomu have you tried the mount command so far?

[twojstaryzdomu]

@twojstaryzdomu have you tried the mount command so far?

I suppose you mean the internal mount command that for instance is mentioned in #1270?

I'm reluctant to use that since the mount command is internal to MPD but it isn't part of the configuration. Given the listing capabilities, it's a great facility for a future client to interact with MPD, but I don't see that having an equivalent in a config file. At least one that is mentioned in the mpd.conf manpage.

mount, list are great for interactive or programatic use, like in the client that you are developing. These commands address a different set of challenges to a suggested static mpd.conf option, defining multiple music_directory sources.

[maxmitti]

Yes, i mean that. However it is not internal, otherwise it could not be used via the protocol. mpc supports it.

I would suggest to try it out even if it has no place in the config yet. Because if it works well for your use case you can advocate for adding it to the config. And adding mount to the config seems much more likely than adding something completely new, imo.

Just be sure to configure the cache_directory, because afaik that is necessary for mount to work.

[twojstaryzdomu]

IIRC internal commands are no good match. mpd.conf is parsed only when mpd starts. There isn't really any need for mount, only the ability to use multiple paths.

I think the complexities of the listing & mounting of drives outweigh the simple scenario merely to be able to specify multiple paths in the mpd.conf file. There isn't any need to extend the internal commands.

One way to handle multiple paths would be to extend the syntax for the parameter music_directory in mpd.conf to include multiple paths, separated by a semi-colon. That way, it would remain backwards compatible with all earlier setup, all the while allowing newer clients to take advantage of the extension.

[maxmitti]

@twojstaryzdomu why do you keep calling it internal? What makes it internal?

And like I said above, I would be fine already if mounts were persisted in some way, if they are not already. I just said that adding mounts to the config would be an idea since you said that you want some config way.

[twojstaryzdomu]

@maxmitti, I take back that proposal. extending client-level commands merely to be able to support multiple paths that you specify in a static mpd.conf file sounds overkill.

mount doesn't sound like it has anything to with multiple paths anyway. It's a client-level command. The fact you need to add some cache_directory earlier defeats the simplicity of the exercise. Config file parameters need to be self-sufficient, not depending on one another. That's one reason why config file parameters can't be a good match for client-level commands.

Over-engineered solutions tend to be ignored in favour of simpler ones. Invoking an obscure set commands is perfectly fine for client protocol but not a good idea when it comes to config files that need to be simple for users' sakes.

If all the users need is to be able to specify multiple known paths in mpd.conf, I'd suggest extending music_directory to include paths separated by a semi-colon. That solution follows KISS.

Besides, mpd clients tend to lag behind in protocol changes that aren't core functionality. If the set of paths ever changes, it's by far easiest to update mpd.conf and restart mpd. Doubtless, that will work with all the clients.

[maxmitti]

I don’t get what your problem is. Configuring the cache_directory is a one time thing. Especially if specifying mount points would be done via the config that would be done in one go anyway.

@maxmitti, I take back that proposal. extending client-level commands merely to be able to support multiple paths that you specify in a static mpd.conf file sounds overkill. […] It's a client-level command.

While I was also talking about adding config options to specify mount points in the config, I would not necessarily say that it is an extension of a client command. It would be merely a second way to use the mounting mechanism, which just happens to be only exposed as a client command currently. I am just calling it mount command now, since that is how it is currently known.

mount doesn't sound like it has anything to with multiple paths anyway.

If you are concerned about the naming of the config value, I would guess that there can be found a name that is more intuitive. At least I didn’t suggest any specific name yet.

Over-engineered solutions tend to be ignored in favour of simpler ones. Invoking an obscure set commands is perfectly fine for client protocol but not a good idea when it comes to config files that need to be simple for users' sakes.

I don’t think my proposal would be considered over-engineering, since it is only adding another way to use existing behavior. (As I have said above, it is not about extending a command. It is about using an existing mechanism.)

One of the main advantages of reusing the mount mechanism would be that it is clear how the different directories integrate with each other, because mount points are specified as a directory in the main music_directory, i.e. there is no question which directory to use for example with lsinfo, as @MaxKellermann asked. Another main advantage would be that it is probably very little work to implement it, because the mounting mechanism is already fully implemented.

Besides, mpd clients tend to lag behind in protocol changes that aren't core functionality. If the set of paths ever changes, it's by far easiest to update mpd.conf and restart mpd. Doubtless, that will work with all the clients.

This argument is completely irrelevant. Mount points work completely fine without specific client support already (which you would have seen if you at least tried it once). Client support is only needed currently to specify mount points, but would be completely unnecessary if they can be specified via config instead. And just as you say it would be a config change and restart as well when changing paths. However, additionally it could also be done live via the client protocol without any need for restarting.

[twojstaryzdomu]

Fine, how it's implemented under the hood is irrelevant to a user as long as it is simple and self-contained. If it's implemented in the wrong way, you clutter up the software with bad design and the feature won't see much use due to complexity.

If support for multiple directories is still going to take the literal mount with some cache_directory prereqs then it does not meet the principle of KISS. If the simple ability is going to be exposed to the user in a user-friendly way, by way of a single mpd.conf parameter, then perfect.

By analogy, think of how cumbersome would be to have say the ls command with special prereqs, whenever you want to list more than one directory. Luckily, ls designers understood what is essential to good design. Secondary group records in /etc/group are an equivalent example to my proposal how to expose multiple paths support to users.

Would the solution you have in mind be capable of extending music_directory's syntax with multiple semi-colon separated paths? Again, that's only one suggested way of going about the task in a user-friendly way.

Wrapping around plugin code is only fair to accommodate users who just wish to specify an additoinal path (or any number) without going through the nitty-gritty of mounting, listing etc.

[maxmitti]

I would let someone who is well aware of MPD’s code decide whether it is KISS or not.

Currently the cache_directory is needed (see https://mpd.readthedocs.io/en/latest/user.html#mounting-other-storages-into-the-music-directory). Maybe one could find a reasonable default value (implicitly or in the default config). However it’s not a big issue in my opinion, because the necessity would be mentioned in the doc anyway.

In theory it would be possible as an extension of music_directory, however I it seems sub-optimal to me, because you would still need to specify in which directory the mount point should be. I think a different syntax would be more appropriate, however it is called. I could imagine specifying each directory as a group item with target and url settings, similar to how audio_outputs are configured. (As usual, the naming should probably be different, I am just making something up for examples.)

external_directory {
    target "foo";
    url "nfs://bar/foo";
}

Or if a completely new config syntax is accepted, it could be specified as some kind of map of target directory => url mappings.

external_directories {
    "foo" => "nfs://bar/foo"
    "baz" => "http://foobar/baz/"
}

Edit: While the map syntax looks much neater, I would actually go for the group syntax, because it would make it possible to add more settings in the future. For example, for specifying to use a proxy database for that directory. (I am still hoping for the addition of that feature.)

[twojstaryzdomu]

In theory it would be possible as an extension of music_directory, however I it seems sub-optimal to me, because you would still need to specify in which directory the mount point should be.

And why exactly do you need to specify the mountpoint? You certainly don't need to for music_directory! Isn't this an example of over-engineering or feature creep that isn't requested at all here?

Think about what users need this for. They want all of their music, from multiple sources, made available within a single hierarchy exposed by mpd. They'll likely won't care where that sits so long as they can readily pick it from an mpd client. A client need not even know under which mount a song is found, provided that mpd does the fair job of providing a handler for that.

I somehow don't think there is any need for mpd to be a file system manager for music, exposing the exact hierarchy based on mount sources. The existing hierarchy exposed in mpd as artists/albums/song names/other tag properties is quite enough.

For the ability to specify paths, whose mountpoint in mpd name is largely irrelevant, I'd just go with the simple semi-colon separated or rely on music_directory1, music_directory2, etc.

[maxmitti]

The need to specify the mount point is simply to keep everything else working as is. Specifically it answers the question which directory to pick as the “root” (see https://github.com/MusicPlayerDaemon/MPD/issues/1252#issuecomment-908452071).

I have seen your answer, proposing to just use the first or last in the config file, however that is not a suitable solution in my opinion.

You certainly don't need to for music_directory!

Yes, because it is the only music directory which should obviously also be the root.

You might be happy with the tag based database view, but there are many users (including me) who use the actual folder structure view.

I get that it is an extra step to do for the user, but you can consider it as a label for that folder, instead of some actual folder hierarchy. Furthermore, we are talking about people who specifically setup a client-server-model music player, it is not a choice that people who want the (setup-wise) easiest possible music player make. And it only affects those who actually need that feature, the basic single music_directory setup would stay the same anyway.

And I still don’t think that it would be over-engineering, because it actually makes the implementation simpler and already works like that.

[twojstaryzdomu]

It's

I get that it is an extra step to do for the user, but you can consider it as a label for that folder, instead of some actual folder hierarchy.

Mountpoint name is clutter, does not serve any purpose in the context of mpd.

Simpler implementation does not rule out over-engineering. The mount plugin itself a is an example of cluttering up mpd with a feature set not traditionally associated with a music player. OS based automounters have been around for much longer than mpd and are more fitted for the job. I understand your wanting to piggy-back on that functionality but while it makes sense for an informed user such as yourself, most won't even bother about mountpoint. Time is wasted explaining why you'd want to specify one in the first place, merely to be able to add another music source.

Users likely won't care there is a plugin underpinning support for multiple music sources.

So let's do that stuff under the hood and not encumber the user with specifying items that aren't strictly necessary (like mountpoint name) when specifying more than 1 music source. Not doing so runs the risk of feature creep and making the simple configuration files unnecessarily complex.

Besides no other playback software that I know of requires you to pick a mountpoint for a music source directory.

How it is implemented internally is irrelevant, what matters is how it's exposed to a user.

[twojstaryzdomu]

I get that it is an extra step to do for the user, but you can consider it as a label for that folder

Don't force users to select labels that aren't strictly necessary for the software to work. If they choose to do so voluntarily, fine, but no value here for most users wanting a shared hierarchy of all of their music on different media.

Yes, because it is the only music directory which should obviously also be the root.

Would wrapping around all the music found under all the sources to make it appear as if all were in root be a solution? No mountpoints necessary, all in line with KISS. That way forward would favour the simplest 2ndary group-style record for music_directory.

However, if a user should choose to maintain label/mountpoint per music source, fine, use the map syntax.

The reason being the disconnect to the syntax for a single path (music_directory) and multiple paths (maps, mountpoints) is uncanny. It'll no doubt raise some eyebrows if implemented the wrong way.

Pulseaudio is a good example of bad decisions and missing features leading to users leaving in droves for simpler audio engines (hopefully...). Only recently did PA expose a view of the default sink, volume level etc. with get- query commands. At a time when PA is slowly becoming irrelevant, for various reasons. While I don't claim mpd is anything close to the state pulseaudio is these days, I'm an advocate for simple solutions, wrapped around internally to accommodate users without a great need to read through plugin manuals to use a simple feature.

[maxmitti]

The mount plugin itself a is an example of cluttering up mpd with a feature set not traditionally associated with a music player.

Similarly, supporting file access via NFS (and other protocols) is also not traditionally associated with music players. Anyway, I would say that MPD is not a traditional music player.

OS based automounters have been around for much longer than mpd and are more fitted for the job.

Yet you were not satisfied when I suggested OS level mounts. However, I agree that it is not optimal for non-local storage.

How it is implemented internally is irrelevant, what matters is how it's exposed to a user.

Of course the user doesn’t care about implementation details, but the maintainer probably does.

That way forward would favour the simplest 2ndary group-style record for music_directory.

That might be an idea, but the question arises what happens to conflicting (matching name / relative path) folders and files.

[twojstaryzdomu]

Similarly, supporting file access via NFS (and other protocols) is also not traditionally associated with music players.

NFS, Samba make sense since they act as a music source similar to cloud based source. And players do have support for those.

Anyway, I would say that MPD is not a traditional music player.

The problem starts when run-of-the-mill features are missing and priority is given to clutter. Handling multiple paths is nothing special for audio players, whilst mounting internally via a label is.

That might be an idea, but the question arises what happens to conflicting (matching name / relative path) folders and files.

Does the user care what the label for their source is when all they want a single hierarchy view? Likely not. Just handle that internally somehow, use the full path for it and the problem is solved. mpd is a music player, some choices fitting in a file manager won't be relevant here. What matters first and foremost is that music can be played and easily viewed from a single hierarchy. If you argue some users will need separate hierarchies, then it follows the example of partitions, nice in theory but a minority feature. I don't think it would be used much.

Multiple media with music are in contrast a common occurrence, hence the need to add the feature. A single music_directory source only follows an idealistic assumption of an organised developer. Single use case. Currently, the usage of an nfs:// source with music_directory rules out a local one and vice versa. Users aren't like that, for many reasons. Limited storage is a good argument why.

OS based automounters have been around for much longer than mpd and are more fitted for the job.

Yet you were not satisfied when I suggested OS level mounts. However, I agree that it is not optimal for non-local storage.

The point was not whether mount is unnecessary in mpd. It may be fine internally for some things. It seems like a bad design idea to copy its interfaces as is (i.e. requiring a mandatory label) to implement multiple paths. Hence the idea to wrap around it in a smart way.

In a music player, you don't need a mount label. Think what you see in the client. You see artist/album/song/other tag. If you're truly intent on knowing the source a song comes from, add a tag that represents the source. Just don't require additional variables (mountpoints/mount labels) for a user to maintain in the configuration.

[maxmitti]

That might be an idea, but the question arises what happens to conflicting (matching name / relative path) folders and files.

Does the user care what the label for their source is when all they want a single hierarchy view? Likely not. Just handle that internally somehow, use the full path for it and the problem is solved. mpd is a music player, some choices fitting in a file manager won't be relevant here. What matters first and foremost is that music can be played and easily viewed from a single hierarchy. If you argue some users will need separate hierarchies, then it follows the example of partitions, nice in theory but a minority feature. I don't think it would be used much.

I’m not against the idea in principle. I was just asking how you would address possible conflicts. Think about the following two questions, where dir1 and dir2 are two different “music_directory”s enabled at the same time:

• What happens if multiple “music_directory”s have a folder with the same name, let’s assume dir1/foo and dir2/foo? Possibly merging the contents?
• What happens if multiple “music_directory”s have a file with the same name, let’s assume dir1/foo/bar.mp3 and dir2/foo/bar.mp3? Of course, this is probably not a common case, but it can happen, especially if you assume that users’ libraries are not that organized.

[twojstaryzdomu]

• What happens if multiple “music_directory”s have a folder with the same name, let’s assume dir1/foo and dir2/foo? Possibly merging the contents?

A directory is a unique entity within a given music source. I'm not against having some sort of top level directory within mpd hierarchy for mpd's internal uses. The full path can serve as a natural top level mountpoint for a hierarchy. Since that will stay internal to mpd, I wouldn't trouble users to define a variable they're unlikely ever to refer to interacting with mpd.

• What happens if multiple “music_directory”s have a file with the same name, let’s assume dir1/foo/bar.mp3 and dir2/foo/bar.mp3?

It's the same scenario if you had dir1 & dir2 within the same music source. There can be no contention really, as the handles are different. I suppose you meant what happens when dir1/foo/bar.mp3 exists in 2 different music_directory sources? In that case the internal top level hierarchy starting point will tell these two apart. And again, the user need not have to specify a variable for mpd they won't ever see. The full path to the music source is a sufficient identifier. Forcing a user to define a mandatory label that isn't seen within a single hierarchy defeats simplicity. Adding a tag that indicates the music source for a song should suffice. It would enable users to group music by music sources.

Of course, this is probably not a common case, but it can happen, especially if you assume that users’ libraries are not that organized.

Libraries tend to be in various states of disarray before they reach the optimal goal of being perfect. I don't assume the best case scenario is possible for many users.

[maxmitti]

I suppose you meant what happens when dir1/foo/bar.mp3 exists in 2 different music_directory sources?

What I mean is that there are two music_directory settings defined. One I call dir1 and the other dir2. The names are just for discussion purposes and to specify in the config, not to be part of the library as seen by MPD. Only the contents of the directories should be part of the MPD library.

According to what you proposed earlier the contents of both dir1 and dir2 would be merged and represented as the contents of MPD’s root. But yes, what I’m asking is what happens if there is a file (or folder) with the same name in both directories, such that they would result with the same path in the virtual directory. You can’t ignore this and rely on tags, because songs are added to the queue via their file path and nothing else, regardless of how you browse the library.

[muesli4]

Mount points are persistent and they are not the same as filesystem mounts. Since this functionality is already there, it is best to build on it. Perhaps, you can break down this issue into several ones:

• Remove music_directory and provide a new section called storage where the mount points are specified (in addition to dynamic functionality). If / is specified, the mount point is mounted to the top level directory in the virtual filesystem.

  storage
  {
      mount "nfs://file-server/my-collection" /nfs
      mount "/local/collection" /
  }

  If you leave away the mountpoint you could mount to the root directory of the virtual filesystem.

• Add additional parameters to the mount point functionality (both config and commands) to specify priority or shadowing behavior.
• Improve names of neighbor plugin URLs if possible.

Doing so would increase the success of getting anything done. And it seems to me the discussion here is getting more complicated to follow.

[twojstaryzdomu]

Only the contents of the directories should be part of the MPD library.

There is nothing that warrants that. Internally, mpd is free to create anything, in the discussed case a top level entry for each music source. It doesn't matter from a users perspective as they won't see the entry at any point. Externally, the user provides only the mount source.

According to what you proposed earlier the contents of both dir1 and dir2 would be merged and represented as the contents of MPD’s root. But yes, what I’m asking is what happens if there is a file (or folder) with the same name in both directories, such that they would result with the same path in the virtual directory. You can’t ignore this and rely on tags, because songs are added to the queue via their file path and nothing else, regardless of how you browse the library.

I answered this. You use the full path as top level entry in the hierarchy for each music source.

[maxmitti]

Mount points are persistent […]

Nice, good to know.

Perhaps, you can break down this issue into several ones:

* Remove `music_directory` and provide a new section called `storage` where the mount points are specified (in addition to dynamic functionality).  If `/` is specified, the mount point is mounted to the top level directory in the virtual filesystem.
  ```
  storage
  {
      mount "nfs://file-server/my-collection" /nfs
      mount "/local/collection" /
  }
  ```

  If you leave away the mountpoint you could mount to the root directory of the virtual filesystem.

* Add additional parameters to the mount point functionality (both config and commands) to specify priority or shadowing behavior.

* Improve names of neighbor plugin URLs if possible.

Doing so would increase the success of getting anything done. And it seems to me the discussion here is getting more complicated to follow.

Yes, that is more or less what I was imagining. Thanks for the input.

[twojstaryzdomu]

Mount points are persistent and they are not the same as filesystem mounts. Since this functionality is already there, it is best to build on it. Perhaps, you can break down this issue into several ones:

* Remove `music_directory` and provide a new section called `storage` where the mount points are specified (in addition to dynamic functionality).  If `/` is specified, the mount point is mounted to the top level directory in the virtual filesystem.
  ```
  storage
  {
      mount "nfs://file-server/my-collection" /nfs
      mount "/local/collection" /
  }
  ```

That is PRECISELY the over-engineering I have asked to be avoided. Both /nfs and / are unnecessary from a user's perspective and mpd should handle naming the top level directory for each music source in mpd's internal tree of music files behind the scenes.

It's bad user experience/design since a case for 1 music source is inconsistent with a case for many sources. Users normally expect some sort of consistency when 1 and multiple items are provided.

What's wrong with extending music_directory to include the following syntax?

music_directory "nfs://file-server/my-collection;/local/collection"

Simple, clear and based on the existing syntax. It's consistent. The user isn't burdened with having to pick some arbitrary top-level mountpoint that's internal to mpd. The user knows immediately how to add any number of music sources. mpd would use the music source as top-level mount path in its internal hierarchy. It's perfect, and user-friendly.

By way of an example the two files would appear within the internal hierarchy (worst case, same relative path):

/nfs://file-server/my-collection/files/some_music.mp3
/local/collection/files/some_music.mp3

No conflict here right? Both entries are unique by their top-level directory. It doesn't matter what it is as long as it's unique. Alternatively:

/1/files/some_music.mp3
/2/files/some_music.mp3

1 & 2 represent the sequence in which the music sources were provided. Different implementation, same net effect to the client.

My point being: internal naming isn't relevant as long as it achieves the same effect externally.

If it requires a wrapper to handle it, fine, as long as the user isn't: 1) exposed to inconsistent, complex multiline syntax when transitioning from a single music source to multiple music sources 2) made to pick variables that are internal to mpd and never exposed to the user (the mountpoint in mpd).

This discussion serves as a good example how bad design can stem from insistence to rely on existing mechanisms as-is, without wrapping around them for user's sake.

[maxmitti]

Actually, since mounts are already persistent I don’t care about a config entry. I was just suggesting it because @twojstaryzdomu insists on having it in the config.

Both /nfs and / are unnecessary from a user's perspective and mpd should handle this behind the scenes.

Except that they are visible in the folder view, lsinfo and probably more commands, if you choose to use additional folders somehow (whether automatically chosen or not) in order to avoid path conflicts.

[twojstaryzdomu]

Except that they are visible in the folder view, lsinfo and probably more commands, if you choose to use additional folders somehow (whether automatically chosen or not) in order to avoid path conflicts.

Updated earlier comment with two examples. I prefer the former, with top-level directories named after the music sources, but ultimately it doesn't matter.

mpd users don't traditionally run lsinfo, clients & developers do. Users tend to run an mpd client and play their music from there.

[muesli4]

Mount points are persistent and they are not the same as filesystem mounts. Since this functionality is already there, it is best to build on it. Perhaps, you can break down this issue into several ones:

* Remove `music_directory` and provide a new section called `storage` where the mount points are specified (in addition to dynamic functionality).  If `/` is specified, the mount point is mounted to the top level directory in the virtual filesystem.

storage { mount "nfs://file-server/my-collection" /nfs mount "/local/collection" / }

That is PRECISELY the over-engineering I have asked to be avoided. Both /nfs and / are unnecessary from a user's perspective and mpd should handle naming the top level directory for each music source in mpd's internal tree of music files behind the scenes.

It's the functionality that is already there. I guess some users may want this but you would have to ask @MaxKellermann.

It's bad user experience/design since a case for 1 music source is inconsistent with a case for many sources. Users normally expect some sort of consistency when 1 and multiple items are provided.

What's wrong with extending music_directory to include the following syntax?

music_directory "nfs://file-server/my-collection;/local/collection"

MPD already has a virtual filesystem in the sense of a library. The root of which is the directory specified. Thus, changing this would break existing functionality.

Simple, clear and based on the existing syntax. It's consistent. The user isn't burdened with having to pick some arbitrary top-level mountpoint that's internal to mpd.

It does not tell the user how they are accessible. And the mount points are not internal to MPD they are visible in the library.

/1/files/some_music.mp3
/2/files/some_music.mp3

1 & 2 represent the sequence in which the music sources were provided. Different implementation, same net effect to the client.

My point being: internal naming isn't relevant as long as it achieves the same effect externally.

The thing is, this already exists. Some users may want to use this or are doing so already.

This discussion serves as a good example how bad design can stem from insistence to rely on existing mechanisms as-is, without wrapping around them for user's sake.

You could make the same argument about unix filesystems. I do not think it is bad design per se. You always need to think about what the requirements were when it was designed.

[twojstaryzdomu]

It's the functionality that is already there. I guess some users may want this but you would have to ask @MaxKellermann.

Do not assume what is good for a developer is good for a user. Requiring mounts with its over-the-top syntax for more than 1 music source is bad design, not consistent with a single music_directory and as such not for the casual user. For developers orientating their clients around it is perfectly fine.

MPD already has a virtual filesystem in the sense of a library. The root of which is the directory specified. Thus, changing this would break existing functionality.

How would mounting as per these examples exactly break existing functionality and which functionality precisely?

It does not tell the user how they are accessible. And the mount points are not internal to MPD they are visible in the library

Explain what a user is not told following my proposal how to handle it. On the contrary, you get a full path to the music source first, followed by a relative path within the source. That serves hierarchical record and sufficiently unique.

You could make the same argument about unix filesystems. I do not think it is bad design per se. You always need to think about what the requirements were when it was designed.

mpd isn't exactly a file system manager nor should it strive to become one. Intending to duplicate unix file systems functionality in mpd and requiring users to follow the same semantics (mountpoints) is over-engineering and ignoring the use case of a music player with a single hierarchy of tracks available across all devices.

mounts are fine when wrapped around to hide the cogs and wheels from the user. What's good for a developer isn't always good idea for a user.

Some common config file parameters, like password or metadata_to_use, take reasonable syntax to perform the necessary work behind the scenes. Other parameters have syntax that varies with type, like audio_output, and as such it's reasonable to have its syntax implemented as a hash/map. For multiple music sources in music_directory, the mountpoint can be easily derived from the mount source, so it's more like the former. Besides, complex syntax invites user issues.

[bhurt1]

I have a no brainer solution, create a directory inside your music folder, I call it add, and just simply symlink all your music files there. I know its sounds too easy a solution when we could spend now 42 comments on how to solve an easily solvable problem. I'll do that while you rack your brains and can't get a working solution.

[muesli4]

It's the functionality that is already there. I guess some users may want this but you would have to ask @MaxKellermann.

Do not assume what is good for a developer is good for a user. Requiring mounts with its over-the-top syntax for more than 1 music source is bad design, not consistent with a single music_directory and as such not for the casual user. For developers orientating their clients around it is perfectly fine.

It is there already.

MPD already has a virtual filesystem in the sense of a library. The root of which is the directory specified. Thus, changing this would break existing functionality.

How would mounting as per these examples exactly break existing functionality and which functionality precisely?

I guess you can not specify the name.

It does not tell the user how they are accessible. And the mount points are not internal to MPD they are visible in the library

Explain what a user is not told following my proposal how to handle it. On the contrary, you get a full path to the music source first, followed by a relative path within the source. That serves hierarchical record and sufficiently unique.

The name of mounts are sometimes a bit cryptic. Using them as first path segments may actually be confusing for users. If the user does not care it is better to mount everything to the top level directory:

mount a
mount b

However, if the user cares, he can optionally specify where in the virtual file system of MPD he wants parts to be mounted:

mount wife a
mount mine b

@bhurt1 Imagine your drive is not ready yet or you use a more exotic source, you can't do that with symlinks. However, with this, everything is handled by MPD.

Some common config file parameters, like password or metadata_to_use, take reasonable syntax to perform the necessary work behind the scenes. Other parameters have syntax that varies with type, like audio_output, and as such it's reasonable to have its syntax implemented as a hash/map. For multiple music sources in music_directory, the mountpoint can be easily derived from the mount source, so it's more like the former. Besides, complex syntax invites user issues.

Except that it is not complex and this YAML-style configuration is used in many other parts of the MPD config already.

edit: I was wrong about the hierarchical nature of the virtual MPD filesystem. It enables mounting to labels and those are "mounted" at the top level.

[bhurt1]

Exactly what I said, you just overcomplicated something that needn't be. Let's be clear, I understand all of this stuff but I live by the KISS metric. Unless you like to be the last mnemonic of that phrase. And, I don't like sym links as a solid solution, but here it works for me. Exotic, you must be pluggin and rewritin at speeds that is stupendous, again keep it simple, and don't get stupid, with organization it can be handled handily. I stand by my long standing mnemonic, KISS.

[twojstaryzdomu]

@bhurt1 cut the simpleton sarcasm. Links may indeed be simpler to undersand but don't cover all cases. You don't always have the luxury of defining those, such as when the source isn't a local path (say you mix nfs based sources) or no file system access, except for the edit ability of the music_directory field. Technically there is autofs but it's terribly unreliable (though improving) and users would need root to tinker with it anyway. The mount command is bad design - something an overly eager developer would expose to the world when it is targetted at developers designing their clients to talk to mpd. The labels mentioned above are unnecessarily duplicating a POSIX file system paradigm in a music client. And writing xmls or jsons is an exercise in troubleshooting bad syntax for errors and typos. Most users don't wish to read documentation to accomplish an ordinary task. MPD is otherwise a player that does its job but due to such cruft it is still rough around the edges.

Symbolic links in a single directory enable a facility externally but have som0e limitations (you don't know what sources a user will want to expose to mpd). Suppose your link points to a protocol name like a music streaming service or nfs://, does it work for you? Contrast that with updating the syntax of a single command to include mulitiple semicolon separated items, of any type possible. And speaking of KISS, you mistake your no brainer with a bodge which is what links are. All configuration should ideally remain in one place. Not part configuration file, part file system placement or internal command dressed as a unix style command, without much need for it.

Here's KISS at it's simplest:

music_directory="/music;nfs://server:/music2;streaming_servicename://credentials ...

Except to pull that off, you need to stop thinking like a developer or a unix file system enthusiast and consider how other established linux software defines it configuration. Do we have xmls or jsons in systemd configuration? No, because it's one thing they did right. Jsons are a programmer's way to indicate they want to force their users to study their painstakingly written documentation. And to @muesli's recalling other uses of jsons in mpd. True, yet in audio devices for instance invariably takes multiple key value entries. Music sources are standarised protocol://login-options:path, of which only path is mandatory for local paths. It's possible to paste them in a single line rather than discover tools for bad json troubleshootiing by users too quick in their edits

[bhurt1]

I think you answered your pillory of my answer, and I mean that, although probably more correctly the pillory of this problem. The problem doesn't exist, it's been livin rent free in your head for yrs now. somehow you can't accept that it can be solved simply., And if it can't, cuz there are limitations, build your own or move on, that's what linus did, and here we are, you and me, you are so wrapped in bs you can't think straight.

[twojstaryzdomu]

somehow you can't accept that it can be solved simply.

As stated, it doesn't cover all cases, anything that's not within the local file system won't work. I'd like links to work like you propose but it just doesn't work that way for virtual file systems (yet).

And if it can't, cuz there are limitations, build your own or move on

Or open an issue. If everyone just shrugged their shoulders like you propose, many sensible ideas wouldn't make it. The fact a poor man's work-around of sorts exists doesn't make it any less of a feature request (which is what it was opened as). Developers are free to pick what they consider a feature worth adding and going by their response, no such feature will be added.

it's been livin rent free in your head for yrs now. you are so wrapped in bs you can't think straight.

On the one hand you raise a fair point but on the other you seem a plain troll. This just isn't the place for sorting out personality issues.

[bhurt1]

you are a pure degenerate, you call features of linux that are by far superior to win, a poor mans work around, and you say I am sorting out personality issues ? Its obvious you are projecting by confession. I understand I covered more ground in fewer words than you can say in , a few explitives. so deal with it. As is painfully obvious and your need to try and call ppl stupid or simpleton, as you said, is again confession by projection, a common liberal tactic. So I ask are you going to be able to work for the next month after I have talked this way to you, like a true liberal twitter lord.

[twojstaryzdomu]

you are a pure degenerate

How old are you? Your manner of talk is clearly intended to abuse as such it has no place here. Such statements appear to come from someone in need of an anger management class not a person with anything of value to add.

you say I am sorting out personality issues ? Its obvious you are projecting by confession

Well someone who goes on rants to call someone

degenerate

or

you are wrapped in bs

is in need of professional help, not compulsively posting here.

But worst of all

liberal twitter lord.

Github isn't twitter in case you haven't noticed to be hurling abuse at others. I called out your incendiary manner of talk. Seen enough evidence in my lifetime so far folk who go on rants to insult others have personality problems. Luckily I don't have twitter.

' '

Self censorship? No consistency in your sworn use of expletives.

call ppl stupid or simpleton

Wrong on both counts. Not stupid and not people, but your sarcastic talk. Read what I wrote again.

features of linux that are by far superior

Symbolic links aren't superior when you need to set them up as a bodge to work around the hard limit of 1 music_directory path. And they're not superior when they can't point at an external service like nfs://.

[MaxKellermann]

@twojstaryzdomu don't waste your time with pricks like that. I have blocked them now.