Bugzilla – Bug 1361
if ~/Music is an alias (not a symlink) on OSX, slimserver won't start
Last modified: 2011-03-16 04:18:46 UTC
mkdir /Users/jan/Music: File exists at /Users/jan/Library/PreferencePanes/SlimServer.prefPane/Contents/server/Slim/Utils/Prefs.pm line 115 Compilation failed in require at /Users/jan/Library/PreferencePanes/SlimServer.prefPane/Contents/server/Slim/Buttons/Plugins.pm line 20. BEGIN failed--compilation aborted at /Users/jan/Library/PreferencePanes/SlimServer.prefPane/Contents/server/Slim/Buttons/Plugins.pm line 20. Compilation failed in require at /Users/jan/Library/PreferencePanes/SlimServer.prefPane/Contents/server/Slim/Buttons/Common.pm line 15. BEGIN failed--compilation aborted at /Users/jan/Library/PreferencePanes/SlimServer.prefPane/Contents/server/Slim/Buttons/Common.pm line 15. Compilation failed in require at /Users/jan/Library/PreferencePanes/SlimServer.prefPane/Contents/server/Slim/Buttons/Settings.pm line 11. BEGIN failed--compilation aborted at /Users/jan/Library/PreferencePanes/SlimServer.prefPane/Contents/server/Slim/Buttons/Settings.pm line 11. Compilation failed in require at /Users/jan/Library/PreferencePanes/SlimServer.prefPane/Contents/server/Slim/Display/Display.pm line 14. BEGIN failed--compilation aborted at /Users/jan/Library/PreferencePanes/SlimServer.prefPane/Contents/server/Slim/Display/Display.pm line 14. Compilation failed in require at ./slimserver.pl line 205. BEGIN failed--compilation aborted at ./slimserver.pl line 205.
reproduced in trunk r2948, osx 10.3.8
dan to take another quick look at this
Ah this issue is fixed, at least the part where it won't start. Dan is looking into alias support in general.
Actually, this bug has resurfaced in v6.2.2 (nightly 3/31). The exact same issue: if ~/Music is an alias, slimserver won't start and gives an error... starting slimserver in CLI mode yields: [Bork3x:SlimServer.prefPane/Contents/server] % ./slimserver.pl mkdir /Users/cepheid/Music: File exists at /Library/PreferencePanes/SlimServer.prefPane/Contents/server/Slim/Utils/Prefs.pm line 356 If ~/Music is a regular folder, it works fine. If it's an alias, the above error occurs. So, this bug should be re-opened... unless you want me to submit a NEW bug report for it? This is with OS X 10.3.9, SlimServer v6.2.2 (nightly 3/31).
Out of curiosity, is anyone still following this bug? It should be reopened as the bug has resurfaced in v6.2.2, as I reported previously. Should I open a new bug, or is someone following this and can reopen it for me?
This bug looks like it should have been reopened. Better late than never.
best to reassign to qa so it gets reviewed again.
Did you see this in 7, Dan?
I was looking for bugs related to using aliases in Mac OS and saw this one. It appears that someone reported it reopened in comment #4 but the bug remained "fixed". Is it in 7, I don't know.
I just tried this with a fresh install of SqueezeCenter 7 and the default music folder changed to an alias with both Mac OS X 10.4 & 10.5. SqueezeCenter crashed immediately after start on both systems. I am going to reduce the severity of this bug because it should only affect users that have changed the default music folder to an alias before installing SqueezeCenter. This was not something that was even easy to do with Mac OS X 10.5 because I had to enable and login as root to make the change. Is there a reason that SqueezeCenter 7 is even accessing that folder before the user has a chance to choose what music source to use? Might be another bug.
But what happens if you choose an alias as the music folder even after you've started SqueezeCenter? It's very possible that some people might want to have SqueezeCenter pointed to an alias instead of a regular folder, e.g. if they use multiple programs all pointing to that alias and want to update only the alias (one-time) instead of all the other utilities (e.g. if they store their music folder on one or more external hard drives and switch between them). If SqueezeCenter can't handle an alias at all, IMHO that's more severe.
That is correct, SqueezeCenter cannot handle Mac OS X alias at all at the moment. If a user was to choose an alias for a directory after SqueezeCenter is installed it simply will not work. It won't crash SqueezeCenter however. Related Bug 5584 covers aliases and provides a workaround. Related Bug 5552 covers scanning of the music folder before the wizard is completed leading to a crash in this instance.
could somebody give the patch in bug 5584 a try? It would add support for aliases on OSX.
change 25259 - expand music path if it's an alias, or SC will crash at startup