Bugzilla – Bug 9085
SS 7.1 update on Mac OS deletes plugin folder
Last modified: 2008-08-11 20:30:25 UTC
Updating SS 7.0 to 7.1. deletes all the plugins from the Plugins folder on Mac OS 10.4.11 (though I suspect this behavior is reproduced on all versions of Mac OS X). I have seen this behavior with an earlier version of SC (perhaps 6.5) as well. Perhaps it has something to do with the fact that the copy command on mac behaves differently from that on windows (where copy is more like merge). If that is the case, perhaps the 'ditto' command could be used. For discussion, please see this thread. http://forums.slimdevices.com/showthread.php?t=50838
In which path did you install your plugins?
Maybe I can give a bit more detail on the issue (as of the thread linked by Nikhil): There are two alternatives as to where you can install plugins on OSX: <youraccount>Library/Application Support/Squeezecenter/Plugins or /Library/PreferencePanes/SqueezeCenter.prefPane/Contents/server/Plugins/ The latter gets wiped, the former doesn't work with all plugins, plugins that bring their own skin (e.g. iPeng or some of Erland's plugins) will not work from there: Skins that don't need access to a plugin can go to: <youraccount>Library/Application Support/Squeezecenter/html Plugins that don't need to provide their own skin (that is: more than their plugin files, like iPeng does) can go to <youraccount>Library/Application Support/Squeezecenter/Plugins but plugins that provide a skin that needs access to the plugin code (e.g. iPeng) need to go into /Library/PreferencePanes/SqueezeCenter.prefPane/Contents/server/Plugins/ maybe the best workaround would be to enable plugins in <youraccount>Library/Application Support/Squeezecenter/Plugins to provide their own skin... and remove the other plugin path alltogether.
> There are two alternatives as to where you can install plugins on OSX: > <youraccount>Library/Application Support/Squeezecenter/Plugins > /Library/PreferencePanes/SqueezeCenter.prefPane/Contents/server/Plugins/ There's the third option which imho should cover all cases: /Library/Application Support/Squeezecenter/Plugins Did you try this? > but plugins that provide a skin that needs access to the plugin code (e.g. > iPeng) need to go into > > /Library/PreferencePanes/SqueezeCenter.prefPane/Contents/server/Plugins/ That's interesting. Does this include plugins which bring just a couple of templates? Would it work in /Library/Application Support/Squeezecenter/Plugins ?
>There's the third option which imho should cover all cases: >/Library/Application Support/Squeezecenter/Plugins >Did you try this? Yes, as I said, that doesn't work. For iPeng at least. >That's interesting. Does this include plugins which bring just a couple of >templates? Would it work in >/Library/Application Support/Squeezecenter/Plugins >? No, skin template files under that directory do not seem to be loaded correctly. You would have to strip the template files and move them to /Library/Application Support/Squeezecenter/html That would mean: a) I would need a separate distribution for OSX b) Users would have to install two partial distributions in two separate locations and c) I would probably have to hire support staff since already today a maximum of 50% of users seem to get the installation done correctly on the first try.
> >There's the third option which imho should cover all cases: > >/Library/Application Support/Squeezecenter/Plugins > > >Did you try this? > > Yes, as I said, that doesn't work. For iPeng at least. Just to be sure: I didn't see you mention the system's Library path, but only the user's. This is not ~/Library but /Library. Did you test this as well? This path is _not_ generated automatically.
OK, that one works. Does this require SC to be installed for all users? Would it be possible to create the folder upon installation? I see all kind of user errors coming by if users have to create that path. BTW, what happened to the plugin installer?
No, that path should be available whether installed for all users or not (see Slim/Utils/OSDetect.pm, line 573). I'm not sure what the exact issue is here: we're allowing for too many paths? They don't behave identical? As for the plugin installer: a lot of great ideas, but not enough priority to get implemented. We really hoped someone in the community would jump the train and give it a go. So... feel free to do so ;-).
The problem is: If the path is not automatically created, users have to. They have to create SqueezeCenter under Application support and Plugins under SqueezeCenter. Since a significant part of my users already end up with an "Plugins/iPeng/iPeng" path upon installation I think this is a source of error that could be gotten rid of by creating the path upon SC install - like the ones under ~/Library
We decided that the real bug was that some plugins (iPeng - others?) didn't work when installed in the right place (Applicaton Support). You should _never_ have to open and put files in the pref pane. Jörg - could you please open a new bug with whatever you know about this issue? - Thanks! Nikhil - this doesn't mean your issue wasn't real. But it's "only" a side-effect of a different problem. Let's try to fix the root cause of it. Thanks for your understanding.
Actually it appears to me that the FUNDAMENTAL issue is already fixed. That was, that for 7.0 when you installed a plugin like iPeng that brings it's own skin, skin inheritance would not work if installed in ApplicationSupport/Plugins. A path like "Plugins/ipeng/whatever.html" would still be resolved, but "ipeng/status.html" would revert to "EN/status.html". This seems to work now, don't know since when, as it is, I still don't catch changes to SC... The issue in THIS bug now is that back the I wrote an installation instruction for iPeng advising people to install iPeng in the pref pane path. This path gets wiped. I will update my installation instructions and issue a thread on the plugins forum.
Great! Thanks for the feedback.
(In reply to comment #9) > Nikhil - this doesn't mean your issue wasn't real. But it's "only" a > side-effect of a different problem. Let's try to fix the root cause of it. > Thanks for your understanding. Not a problem. Thanks for looking into the issue.