Bugzilla – Bug 4082
Installer should backup existing plugins folder in update installations from <6.5
Last modified: 2009-09-08 09:11:33 UTC
Installing SlimServer 6.5 over an existing 6.3 (or earlier) will break many of the plugins. Eg. RandomPlay would display numbers instead of genres in the web display due to old style templates remaining in the HTML folder. Another critical folder might be Cache (html templates again). It might be best to back them up or rename them and start from scratch. Users will have to update most plugins anyway.
This seems like a good idea to me, although it's too late at this point to put it in to 6.5
But then it should clearly be said that earlier installations have to be removed. Old HTML templates surviving the update lead to trouble.
cc'ing Dean as well for him to ponder
Crap. It's too late for this. Please update the readme files appropriately. Also, if there are well-known bad actors, can we disable them in PluginManager.pm explicitly by name/version?
Skins are already cleaned up. Is it hard, adding the plugins folder, too? Just purge before installing. And add a note to the readme, too.
Ok, I hate people doing what I'm going to do. I'll do it anyway: isn't it as simple as adding something like DelTree(NewServerDir + AddBackslash('Plugins') + AddBackslash('RandomPlay'), true, true, true); to the installer script (on Windows, obviously)?
It would be better to do this in SlimServer, IMO - so then we don't need to alter each of the installers. The only problem child I know about is kdf's old RandomPlay plugin, which is now part of the server. Kevin - what was the name of that before? Plugins/RandomPlay.pm ?
yup. i believe that was it.
I also see issues with Live365, MoodLogic, MusicMagic: they will keep old, incompatible skins. Oh, and there's a first comment about this in the forums: http://forums.slimdevices.com/showthread.php?t=27415
The other issue here is that plugins must be loaded to check for ::enabled() - which is broken. Also - Slim/Utils/PluginManager.pm line ~196. We checked to see if the enabled() function exists to run it - but continue on our merry way if the enabled() function DOESN'T exist, which should by it's very nature indicate an old plugin.
> We checked to see if the enabled() function exists to run it - but continue on > our merry way if the enabled() function DOESN'T exist, which should by it's > very nature indicate an old plugin. You mean >=6.5 compatible plugins _must_ have enabled()? Didn't know that (and thus mine don't have it all)
My thoughts: This 'bug' is mainly a support and customer satisfaction issue. If nothing is done it will generate extra support calls and forum traffic. When users install and the first thing they notice is that the server does not start the will be unhappy (ask my kids if how long the server is allowed to be unavailable..) If you decide to do something with this bug it must be done before going live with 6.5. After release of 6.5 you can close this bug as the harm is done. It's too late for well thought complete solutions. The easy way is to rename the current plugin directory and point the user in the readme.txt to information which is needed to get the pluging working again. This should then be the first item in the readme (IMHO) as it concerns removing functionality which the users added himself. Pointing them to the wiki page and tell them to look for 6.5 versions of their favourite plugin. Buy some time(?): Do not put in the automatic update feature before 6.5.1 and solve it there. You can assume that most techies will find out the existence of 6.5 through the forum and webpage and many can solve the problems with some pointers. The average user will then be prompted to update after 6.5.1 and then a full blown migration solution is in place.. :-) Added value is that 6.5 is then tested in a large community before released to the 'rest of the world'. Thanks, Willem Oepkes
Michael - as it's written, no - you don't need enabled() - but what is the point of having it, if the PluginManager code doesn't force you to have it?
> Michael - as it's written, no - you don't need enabled() - but what is the > point of having it, if the PluginManager code doesn't force you to have it? If enabled() doesn't exist just give it a try - which doesn't mean it won't work even if it's an old plugin. I do have some plugins made compatible with the whole 6.x server series. I never bothered about checking the version to enable/disable it. Not forcing the existing of enabled() is legacy.
Ok - so for 6.5, we're going to ignore the old RandomPlay plugin. For 7.0 we're going to revamp the plugin architecture.
I've commited change 9842 which removes some known bad plugins. If there are any more, please let me know. Other plugin issues will need to be resolved in 7.0
Is this bug still valid?
I'd assume it's still true, but of little importance by now as the masses are already on 6.5.x
The plugin architecture change has now been completed.
This bug is being closed since it was resolved for a version which is now released! Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html If you are still seeing this bug, please re-open it and we will consider it for a future release.