Bugzilla – Bug 3986
Create symbolic links from within Slimserver
Last modified: 2011-11-06 23:22:27 UTC
I'm told that this is the place to make suggestions. If not, then please forgive the intrusion. I run SlimServer 6.3.1 on a ReadyNAS NV, which ought to be a marriage made in heaven, except for the fact that the SlimServer installation expects to find all music in the pre-defined /media share, whilst, in my reality, it is distributed across a user-define share. The ReadyNAS, like most NAS units I assume, has no shell so it is impossible to create symbolic links from /media to actual locations in any manner intelligible to SlimServer. I've tried from both Windows and Ubuntu clients without success, and have since been assured that it "cannot be done that way". Would it be technically feasible for the SlimServer software, itself, to create such links using path information entered through a new section in the GUI? If so, can I persuade someone to do it? Better yet, these links could be made read-only such as to prevent reckless users os SqueezeBoxes/SoftSqueezes from accidentally/deliberately deleting/moving/scrambling the NAS owner's carefully contrive file storage schema. As a non-coding user, I see it as my duty to provide challenges to the developer community. Regards, Andrew Borland.
This is indeed the place to make suggestions. Thanks! We're still learning about the issues that come from working with NAS devices. In this specific case, it seems to me that although while this would technically be possible, it might be a confusing and strange user experience. Using your music server software as a utility to create symbolic links on your filesystem is not intuitive. :) I will talk to Infrant and see if they have considered this issue in the past.
Andrew, have you tried changing the music search path in the 'Server Settings' area to a path which would enable our scanner to find all the music? Our scanner will of course ignore non-music.
Chris, I had early on, sort of, tried changing the search path, but... The text field, being grey, looked non-user-editable (even if, at the time I had understood the relationship between the default value and the way shares are laid out on the NAS) and clicking on "change" failed to bring up any sort of a browse dialogue. My failure didn't exactly surprise me as I had been under the impression that, on a NAS, I couldn't change away from the default anyway. I realise now that that isn't how the interface works and that I can in fact point the search function to any ONE media tree (by editing the text and then pressing change to make it stick) so I am part way to the answer. I would still, very much, like to be able to point to mutiple search roots simply because, if I point to the very top of the share, I'll pick up all sorts of stuff that I don't want cluttering up the squeezebox browser (lo-fi copies intended for portable use, edits in progress, etc.) It does occur to me however, now that I know I can change the search path away from the Infrant default share, that my goal could just as easily be achieved by having multiple fields under "Music Folder(s)". Shall we say half a dozen for starters? As for intuitive: Coming from a Windows background, there is nothing intuitive about symbolic links in the first place (mount this, mount that, ln -s this that), so why not use my music application to create them :) I didn't even know they were called symbolic links until I started researching the way SlimServer manages its search paths, so you could call them anything you liked to avoid confusion.
For the record, Infrant noted users can make symbolic links by mounting NAS volumes via NFS. In a future release they plan to give end-users limited shell access which should solve this problem. The request for multiple music paths is bug 607.
Thanks for the update.
Unassigned bugs cannot have a priority.