scanner triggers mount mechanism non-interactively when a symlink pointing at plugin-style target is encountered

[twojstaryzdomu]

Feature request

As my earlier request was closed without the ability to clarify the use case, I open one that clearly states what is requested.

mount:

1. requires user interaction
2. clients don't support it
3. it doesn't work when a user needs mpd to pick up all of his sources when mpd restarts.
4. is not available in mpd.conf

Seeing as there is unwarranted insistence to use internal mount command, even though it requires user interaction, can you consider enabling the scanner to trigger the mount mechanism automatically when a symlink pointing at a plugin-style is encountered?

I don't think the goal should be to make mount prominent. Most users just want to see their music, configured before mpd starts, not after, without having to interact with the client.

[MaxKellermann]

No, that would be abuse of symlinks. Symlinks are supposed to be solved to real paths by the kernel, but you want to make them files holding arbitrary data to be parsed by one certain application.

[twojstaryzdomu]

No, that would be abuse of symlinks. Symlinks are supposed to be solved to real paths by the kernel, but you want to make them files holding arbitrary data to be parsed by one certain application.

How would that be abuse? A symlink may point at anything really. There is no rule or law that says a symlink may not point outside of the local file system hierarchy or at a protocol. Or that it's the kernel (or rather a file system) that picks it up.

Kernel will happily ignore the fact.

In this instance when all that a user wants is to combine music hierarchies non-interactively (i.e. specify them ahead of mpd starting, in the filesystem or configuration files) the user of the hapless interactive mount plugin, symlinks pointing at plugin-based sources could work nicely.

Just have the scanner dereference the symlink and initiate a specific plugin without user interaction. That's all I ask for here. The mount can do the work under the hood, if you insist on it so much, but the magic would happen with the scanner dereferencing the symlink, recognising it points at plugin-style source, initiating it and adding the input source to its internal hierarchy.

Your plugin system is quite up to the task when it can be configured ahead of the client.

Without the proposed feature or music_directory accepting multiple sources, there is no way to configure non-interactively two or more non-local sources.

Symlinks have been proposed as a way to combine multiple local sources. It works non-interactively. What doesn't work is combining a non-local source and a local one.

A scanner initiating your plugin subsystem when it encounters a special symlink would relieve the user of having to interact to set up non-local music hierarchies via command line upon mpd restart.

Or another alternative is to add a configuration option, but that effectively boils down to enhancing music_directory, or adding an alternative configuration statement.

[twojstaryzdomu]

mount is currently like requiring to tune your tv channels every time you turn it on. mpd is currently allowing 1 channel preset via music_directory; all the others have to be configured (tuned) interactively.

[maxmitti]

According to https://github.com/MusicPlayerDaemon/MPD/issues/1252#issuecomment-950177183 the mount points are already persistent. So your analogy with having to retune every time is incorrect.

[twojstaryzdomu]

You have to jump through the hoops to configure more than 1 music source / tv channel. That is inconsistent. You have to name hierarchies, rather than have a combined hierarchy.

If scanner supported protocol-based symlink targets, it would be a non-issue. You set up your symlinks however you like within a directory that you provide as music_directory. The scanner does the rest, automounting (another facility conveniently borrowed from the OS in addition to mount) plugin targets as needed.

[twojstaryzdomu]

Here's a more detailed proposal:

Suppose a user sets up a remote link in a directory (/music) that is already configured in mpd as a music_directory:

# ln -s nfs://remote_host/music /music/remote_music
# find /music -printf "%P %l\n"
[...]
/music/remote_music nfs://remote_host/music

1. The file scanner tries to resolve the link.
2. The file scanner checks if the link is local.
3. If not, it matches the link against a list of known source input protocols.
4. The scanner uses the details of the link to initiate an internal mount:
   • the name of the link (remote_music in the above example) as the internal mount name
   • the target of the link (nfs://remote_host/music) as the mount target

That way, the existing mount facility stays the same and is made use of. The change needs to happen at the file scanner level only.

Many users might find this simpler to writing json style syntax to include more than 1 music source. Setting up a symlink is quicker & less error prone to writing and updating a storage definition.

The symlink automounter could be enabled via an mpd.conf parameter for users that choose to maintain a single music_directory with symbolic links underneath.

[muesli4]

Many users might find this simpler to writing json style syntax to include more than 1 music source.

Who?

Setting up a symlink is quicker & less error prone to writing and updating a storage definition.

I don't think so. In a configuration file you have all directories listed that should be used. In your solution you have to look in several levels of the file system. Then what about links that are intentionally there but not meant as a "mountpoint" for MPD?

So let's look at your initial issues again:

requires user interaction

I do not see the problem here.

clients don't support it

Maybe you should change the clients then or write your own for that purpose.

it doesn't work when a user needs mpd to pick up all of his sources when mpd restarts.

As already pointed out, it is persistent.

is not available in mpd.conf

Perhaps this could be unified. And I also see a use case for dynamic mount points that persist. You do not want to change the configuration every time someone just wants to plug in their music and play.

[twojstaryzdomu]

Many users might find this simpler to writing json style syntax to include more than 1 music source.

Who?

I would. And several users that I'm speaking here for.

Setting up a symlink is quicker & less error prone to writing and updating a storage definition.

I don't think so. In a configuration file you have all directories listed that should be used. In your solution you have to look in several levels of the file system. Then what about links that are intentionally there but not meant as a "mountpoint" for MPD?

This argument doesn't make sense. The whole point for extending the syntax for symlinks to allow a SEPARATE hierarchy to be used, complete with non-local sources. With symlinks, you could easily create links outside your regular hierarchy to EXCLUDE items 'that are intentionally there'.

So let's look at your initial issues again:

requires user interaction

I do not see the problem here.

It's ludicrous. By analogy, would you really see no problem there with having to type you hostname and IP address every time when your host boots? Your argument adds no value if you cannot prove why a user interaction requirement isn't problematic.

clients don't support it

Maybe you should change the clients then or write your own for that purpose.

Interesting, I made a point clients do not support a feature I find poorly designed and you choose to make a veiled insult.

And maybe you should refrain from making comments that add no value in what is clearly labelled as a feature request?

It is telling that no mpd clients I know of offer any features around issuing internal mount commands. It is clear to me developers do not wish to contribute time to build client features around it.

it doesn't work when a user needs mpd to pick up all of his sources when mpd restarts.

As already pointed out, it is persistent.

is not available in mpd.conf

I do not think so. Please look up the word persistent in the context of an application.

They do not persist across mpd restarts. How can mounts be persistent if they are not available in the single configuration file (mpd.conf) that mpd reads on start up?

The fact you can send low level command AFTER mpd is up does not make them persistent.

[muesli4]

Setting up a symlink is quicker & less error prone to writing and updating a storage definition.

I don't think so. In a configuration file you have all directories listed that should be used. In your solution you have to look in several levels of the file system. Then what about links that are intentionally there but not meant as a "mountpoint" for MPD?

This argument doesn't make sense.

Which one and why?

The whole point for extending the syntax for symlinks to allow a SEPARATE hierarchy to be used, complete with non-local sources. With symlinks, you could easily create links outside your regular hierarchy to EXCLUDE items 'that are intentionally there'.

Separate from what? The music directory? If so, then that is not in your "proposal".

So let's look at your initial issues again:

requires user interaction

I do not see the problem here.

It's ludicrous. By analogy, would you really see no problem there with having to type you hostname and IP address every time when your host boots? Your argument adds no value if you cannot prove why a user interaction requirement isn't problematic.

That is simply a false analogy because it does not represent the state as is.

clients don't support it

Maybe you should change the clients then or write your own for that purpose.

Interesting, I made a point clients do not support a feature I find poorly designed

Then open issues or create pull requests that improve it.

and you choose to make a veiled insult.

I guess you see what you want to see.

And maybe you should refrain from making comments that add no value in what is clearly labelled as a feature request?

Why is it that every issue you open turns into a shit show?

It is telling that no mpd clients I know of offer any features around issuing internal mount commands. It is clear to me developers do not wish to contribute time to build client features around it.

it doesn't work when a user needs mpd to pick up all of his sources when mpd restarts.

As already pointed out, it is persistent.

is not available in mpd.conf

I do not think so. Please look up the word persistent in the context of an application.

It is there after a restart of the daemon.

They do not persist across mpd restarts. How can mounts be persistent if they are not available in the single configuration file (mpd.conf) that mpd reads on start up?

That is what everyone is saying. They are.

The fact you can send low level command AFTER mpd is up does not make them persistent.

The least you could do is try it out yourself. But it seems even that is too much to ask.

[twojstaryzdomu]

Why is it that every issue you open turns into a shit show?

@MaxKellermann can you ban this guy from here? He's clearly unable to separate his sympathies from bare facts and now resorting to verbal abuse and ungrounded insinuations.

@muesli4 this is a low moment for anyone technically versed. The inability to keep a discussion impersonal precludes any discussion with an individual lacking basic manners.

[MaxKellermann]

I agree @muesli4 was quite rude, and this sentence was unnecessary confrontation and bad language, and I'd prefer they'd try to be more constructive here, but that alone does not justify a ban. Let's all calm down a bit and try to get back to the real technical issue here. (Sorry I havn't been replying a lot here, on vacation right now and have been very busy at dayjob recently.)

[muesli4]

Do whatever you must. I have no interest in being here any longer. I was trying to have a factual discussion until I got accused of insulting and being unhelpful from someone that writes in caps and acts like a child.

[twojstaryzdomu]

Then I will pass on the opportunity to explain why I find offensive ridiculous suggestions to change a client solely on the grounds it does not support a poorly designed feature you seem to be partial to and I am not for reasons in the OP. Not to mention your poor use of language to offend. Likewise I wouldn't assume a person I'm talking to hasn't tried a feature he's finding issues with.