Bugzilla – Bug 7971
Plugin updates cause trouble with plugin-data.yaml
Last modified: 2008-06-09 09:11:01 UTC
When updating plugins to new versions, there appear to be frequent issues with the plugin not being recognized correctly, especially with the OLD plugin not being removed from the configuration. It has been seen on 7.0 and 7.0.1 Happened with iPeng (there it is clearly visible that the old plugin stays in the configuration since currently people are upgrading from 0.3.9, where the plugin part was called "ipeng_support" to 0.4, where it is called "ipeng" Other plugins I have seen this issue reported on are TrackStat, Biography and Album Review. Systems are OSX, WinXP and Synology DS107 (Linux) A workaround that has worked in ALL cases so far for iPeng is: Delete the plugin-data.yaml file from cache directory and restart SC. It seems to be important to ONLY delete that file, I've seen several reports of people deleting the whole directory and not getting the problem resolved (old plugins still in the configuration).
I'm not sure if this is related or not, but I thought it was worth mentioning in case it explains the behavior. The iPengSupport plugin was released with the same id in install.xml as the new iPeng plugin. The iPengSupport plugin had a higher version (1.0.beta01) than the iPeng plugin version (0.4). So when users upgraded from iPengSupport to iPeng, SqueezeCenter might have detected these as the same plugin if it uses the id in install.xml to detect the actual plugin, but the new plugin had another name. The version was also lowered from 1.0.beta04 to 0.4.
> The iPengSupport plugin was released with the same id in install.xml as the new > iPeng plugin. The iPengSupport plugin had a higher version (1.0.beta01) than > the iPeng plugin version (0.4). Well, that's not a SC bug. It's up to a plugin author to correctly configure it. Adrian - how much of a performance improvement do we see thanks to this caching? I wonder whether it's worth the hassle we're seeing with the cache file being stale on changes etc.
It IS an SC issue if it persists after the old plugin was removed, which is the issue we talk about here
> It IS an SC issue if it persists after the old plugin was removed, which is the > issue we talk about here as in "especially with the OLD plugin not being removed from the configuration."? There's no word in the description that the issue persists after removing the plugin. Is this really the case? Did you at the same time install a different plugin?
Plugin manager should reparse the install.xml files if there is a changed number of plugins or if there is a newer install.xml file than the current cache file. I believe the reason for the cache file was to maintain state across restarts for pending operations such as installations, but this has yet to be really implemented. I think the best short term solution is to store the sum of mtimes of all install.xml files and reparse if this differs from that see summing the actual file mtimes. It is fair to only look at install.xml files as the contents of plugin-data is built from these alone. This would mirror the mechanism used by the stringcache. I'll have a quick look at this.
As I said, I didn't experience it myself. In all cases I had reported about iPeng I made first sure the people removed th old plugin so: yes, that's the case. The old plugin was physically deleted but not removed from the configuration. IIRC that was also the case on the issue with your plugins that I saw on that other thread....
(In reply to comment #6) > In all cases I had reported about iPeng I made first sure the people removed th > old plugin so: yes, that's the case. The old plugin was physically deleted but > not removed from the configuration. I'm not sure how SqueezeCenter detects that the plugin has been removed, but if it looks at the id inside install.xml, the iPeng plugin might have been considered the same plugin as the previously installed iPengSupport plugin, the reason being that I accidently forgot to generate a new id for iPeng. However, the modification time of install.xml of iPeng should still have been changed, so if this is checked it should still have detected the change but apparently didn't. However, I've also seen users having similar issues when upgrading some of my plugins to new versions, so I think there is still something wrong somewhere in the SC code.
If you remove one plugin and add a new one but the mtime on the new install.xml file is not newer than the cache then you would get this problem. If we fix it to ignore the cache if any install.xml file mtime's change then I think we will be ok.
Michael - I've added a change to 7.1 PluginManager.pm in change 19185 to do more validation of the plugin cache. If this works for people we can consider it for 7.0.
Any feedback on my checkin to 7.1 - do we want to consider it for 7.0?
Didn't have a chance to try it, yet. My 7.1 machine is at home and I haven't been there for a substantial amount of time recently ;-) Maybe tomorrow, will report back.
This patch will very likely not make it into 7.0.1. Assigning to QA to test.
Probably related case: http://forums.slimdevices.com/showthread.php?t=47120 Could you please test updates on Linux too? Thanks!