Bugzilla – Bug 607
multiple music paths
Last modified: 2013-08-16 05:14:57 UTC
I would like to have the ability to have slimserver access multiple music paths. This would be particularly useful to allow slimserver to pull music from multiple NAS devices or network shares.
you should be able to accomplish this with shortcuts, either shorcuts to mapped drives or shortcuts to UNC paths.
*** Bug 757 has been marked as a duplicate of this bug. ***
KDF: now that we have the nifty multiple importer thing, how hard would it be to add support for specifying multiple audiodir paths? I was thinking that entering multiple paths, separated by commas or semicolons would be a sufficient UI, but there's some underlying stuff that would need to be changed to make the scanning work and have things appear as a single virtual audiodir...
well, the nifty importers arent something we actually HAVE yet :) Its lined up, ready to go somewhere, but the exact destination isn't defined. Mainly datastores vs plugins. However, the music folder stuff was never part of that, so it a separate issue. Tricking the server into reading multiple folders is easy enough. Its the combining back into what looks like a single source yet still refers properly to the file system and vice versa that gets difficult. I'm not sure if the most direct way would be to fake multiple folders to look like shortcuts. Theh problem is then it doesn't directly match the filesystem. If we consider the musicFolderScan a simply another importer, then we could just feed one folder at a time to the scan and have it all be transparent, and we'd have to rely on the security controls of the os to determine what folders can and cannot be added.
step one is going to simply enable a scan of multiple directories. Every other aspect of audiodir will then only refer to the FIRST audiodir in teh list. This list will be comma or semi-colon delimited. The method for backward compatibility wil create a function called Slim::Utils::Prefs::getAudioDir, which will replace all cases of Slim::Utils::Prefs::get('audiodir'). This may break plugins that make use of that call, but they would break anyway if they read the whole list. To get the split array, use Slim::Utils::Prefs::getAudioDirArray()
Created attachment 245 [details] first step this adds the ability to set mutiple paths, comma separated or semicolon separated. the scan will then handle all the folders. Browsing Music folder still only uses the first folder in the list. That will come in time.
I'm sure how to fix the browse for web or player ui. trying to read the array and do a for loop results in a server crash every time, due to deep recursion in Parse.pm. something else is at fault for that. however, bypassing this crash, gets no results. the browse is too indirect I guess. any ideas?
ok, looks like the HUGE roadblock on this bug is going to be Utils::Misc::virtualToAbsolute. given /music, it could return the array of audiodirs (ie c:\music, d:\othermusic). however, given /music/artist how should it decide between something like c:\music\artist and d:\othermusic\artist ? one option would be a new virutal level: /music/1 => c:\music /music/2 => d:\othermusic, and so on. OR add a new level to the browse mode and browse web UI to have /music show the list of audiodirs (if more than one) and /music/artist would be which ever base dir was chosen previously.
I agree, I think a new virtual level is in order. If the user has just one audiodir, then when they browse, they see the contents of that audiodir. If they have more than one, then it appears as a virtual directory containing the audiodirs. Look at it this way, the top level is a kind of playlist containing the subdirs!
Created attachment 264 [details] latest patch this now makes the audiodir an array pref while preserving the old singleton pref, updating that setting to the array if requied.
feedback on this was nil, and I'm at a dead end on it. passing back to Dean until this finds more interest/usefulness.
Dan and I had some discussions about issues around Browse Music Folder and relying less on the file system scanning and more on the database. I think that that work should be combined with this work for an overhaul of the file system browsing/import to be more flexible. Not sure if that should be tackled for 6.0, I'll let Dan make that call.
Marking items that aren't going to be addressed immediately in 6.1 as future. Please update if this is in error or the bug has already been addressed.
To consider for 6.2
Sorry, not going to make it for 6.2. In the mean time, use shortcuts or symlinks to have one music folder refer to the other.
*** Bug 2614 has been marked as a duplicate of this bug. ***
Here's a very good reason (IMO) to implement this: It would permit SlimServer to actually validate access to all the folders, as it does now for the single music folder. This would test against permission and network access issues that will otherwise go unseen by the user when using shortcuts/links. With shortcuts, all the user knows is "it didn't work". If tested in the settings, SlimServer can flag inaccessible folders and suggest possible causes and fixes. One common problem is the renaming of shares and folders. Without actually trying to follow an old link, the user won't know that it's no longer valid. If instead, users could test access to the folders (ideally, add a button to test access to existing folders to the setings page) within SlimServer, then they could easily see which are still working. Even more difficult are changes in permission - a shortcut/link may be valid for the user, but fail for SlimServer.
*** Bug 6812 has been marked as a duplicate of this bug. ***
Hello :) this old bug seems to have been fixed by 7.7
And maybe bug 3673 as well.