Bugzilla – Bug 6210
Plugin prefs data is stored in cache..
Last modified: 2008-12-18 11:12:53 UTC
See http://forums.slimdevices.com/showpost.php?p=244328&postcount=12 Prefs data should be persistent. The cache shouldn't store persistent data. Moving the plugin-data.yaml file from the cache dir to the prefs folder would solve this.
I agree with this. Note that the plugin-data.yaml file isn't the only persistent data in the cache. Some (but not all?) of the plugins that write opml files try to write them to the cachedir if the playlist dir isn't writable. These will also be lost if the cache is deleted. There may be other examples I haven't noticed. This is the reason that for the SC7 RPM, I moved the cache to /var/lib/squeezecenter/cache rather than /var/cache/squeezecenter. IMO, it would be better to separate the dir for the cache data (which can be recreated) from the dir for state data and other things we don't want to lose.
rather certain this is bug 5934, at least the cause of it.
change 14931 - moving state to preferences instead of cache file
I'm seeing something similar to the behavior with the moved log.conf file. I stopped SC7, did an SVN update and restarted. All plugin settings were reset (most enabled). I disabled some plugins and saved the settings and it appears from the timestamp on the file that the plugin-data.yaml file in the cache directory was updated. Restarted SC and plugin settings were reset again.
> I'm seeing something similar to the behavior with the moved log.conf file. I > stopped SC7, did an SVN update and restarted. All plugin settings were reset Should have mentioned this - it's expected behaviour when updating from an earlier SC7 build. > (most enabled). I disabled some plugins and saved the settings and it appears > from the timestamp on the file that the plugin-data.yaml file in the cache > directory was updated. Restarted SC and plugin settings were reset again. The state is now saved in prefs/plugin/state.pref - do you see this file? Is it updated when you change state (can take a few seconds as the file is not written immediately)?
Created attachment 2436 [details] state.prefs Yes, I do have a state.prefs file (attached). I can see, though, that plugin-data.yaml is still being modified. I might have been mistaken that all states were reset after a restart. Now I see that a couple may have been successfully disabled. But what I realize now is that the states aren't being changed when I hit 'Save'. I'm not talking about what may be getting saved to disk, but what appears on the Extras page immediately after saving. For example iTunes, Audioscrobbler, SlimTris, Snow, Visualizer, Prevent - none of them can be disabled. Examples of some that do change are CLI, Digital Inputs, Information Browser.
plugin-data.yaml is still in cache, that's correct. Only the state (enabled/disabled) is stored in the prefs. Everything else is temporary. What skin are you using? If you're in Default, hitting the Enable/Disable button is all you'd have to do. I've tested with most plugins you mention and it worked all as expected.
Ouch... there was a typo in the template for the "old" skins. Should be fixed at change 14933
I'm seeing the same behavior as JZ. When I disable a bunch of plugins from the settings page, their state in state.prefs doesn't seem to get changed. For instance, I disable iTunes, but state.prefs always contains Slim::Plugin::iTunes::Plugin: 1 The only plugin I seem to be able to really disable from the settings page is RS232. If I manually edit state.prefs and set states on selected plug-ins (basically, all the internet radio related plugins) to 0 and restart the service, the Extras setting page Enable/Disable buttons now does reflect the expected values. But as of svn 14940, clicking on the "disable" button for most plugins doesn't seem to change state.prefs.
I should qualify my last statement: "The only plugin I seem to be able to really disable from the settings page is RS232." should read: The only plugin that I TRIED to disable that stays disabled is RS232. The other plug-ins that I try to disable (the internet radio related ones) spring back to life, zombie like, unless I manually edit state.prefs.
> I'm seeing the same behavior as JZ. When I disable a bunch of plugins from the > settings page, their state in state.prefs doesn't seem to get changed. For Please note that the prefs file isn't written immediately. Give it 30 seconds to be updated. I've tested various cases which had been reported (including adding/removing plugins) and it always has been working for me. Will have to test on an other machine.
This is what I'm seeing: stop service manually edit state.prefs to "Slim::Plugin::iTunes::Plugin: 1" start service go to extras setting page Click on the "iTunes integration" Disable button. Observe that the "iTunes integration" now reads "Enable". Wait 30 seconds. Open state.prefs: see that it still reads "Slim::Plugin::iTunes::Plugin: 1" Click "Save Settings" button on Extras Setting page bottom. Observe that iTunes integration button now says "Disable" meaning that the previous state change never "took". Wait 30 seconds. Again, open state.prefs: see that it still reads "Slim::Plugin::iTunes::Plugin: 1"
Ok, now I see it: seems to be a special case for iTunes?!? I've enabled, disabled, restarted, saved etc. successfully until I tried iTunes. Seems there's something odd with it. But Extras handling in general imho is ok. Fell free to open a new bug on this, or I'll do so tomorrow.
I've played with it a bit more and think that there's some kind of conflict caused by data in the old plugin-data.yaml file in the cache. If you delete this file then the problem goes away.
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.