I am using a Squeezebox Duet. When I edit the RSS feeds or podcasts and then restart the server, the edits are gone. This is due to a nonwritable directory. This fixes the problem when executed as root: chown squeezecenter.squeezecenter /var/lib/squeezecenter/prefs/plugin I originally reported this at http://bugs.slimdevices.com/show_bug.cgi?id=9403 , but on second thought, this bug is probably Gentoo-specific. Reproducible: Always Steps to Reproduce: 1. Add some RSS feeds or podcasts to squeezecenter using the web interface. 2. See that they show up on the Controller. 3. /etc/init.d/squeezecenter restart Actual Results: RSS feeds and podcasts are reset to the factory defaults. Expected Results: Still see the self-configured RSS feeds and podcasts.
It would actually also be a good idea to move all directories that squeezecenter writes to to a more appropriate place, like /var or maybe /etc . As far as I understand, /usr/share is not supposed to be a place where applications write to.
(In reply to comment #1) D'oh! It's already in /var . Sorry, was mixing it up with something else.
I'm away over the weekend, but I'll look into this after - thanks!
Stuart, Does this issue ring any bells with you?
That's odd - on my test system, a fresh installation of the squeezecenter ebuild on a clean machine creates /var/lib/squeezecenter/prefs/plugin with the permissions you suggest when you start SqueezeCenter (this directory isn't created by the ebuild, but is created the first time SqueezeCenter is run). I've tried a clean installation, added a plugin, restarted squeezecenter and can see that the directory still has the right permissions and the plugin I've added has successfully saved its preferences in there. However, if you already had that directory created with the wrong permissions (say, because you managed to run SqueezeCenter as root rather than 'squeezecenter'), then it will remain with those permissions and exhibit the failure you identified. Do you think this is what happened? Joe: I could easily add a step to the ebuild to force the permissions under /var/lib/squeezecenter/{cache,prefs}, but as these shouldn't really be there unless put there through the ebuild, and I think the ebuild creates them correctly at the moment, I'm not sure that's the right thing to do. What do you reckon?
(In reply to comment #5) > Joe: I could easily add a step to the ebuild to force the permissions under > /var/lib/squeezecenter/{cache,prefs}, but as these shouldn't really be there > unless put there through the ebuild, and I think the ebuild creates them > correctly at the moment, I'm not sure that's the right thing to do. What do you > reckon? Let's see what the reporter says about this theory. Gerben, can you try a fresh install like Stuart tried and see if your system maintains the state correctly? Do you think the dir could have gotten the wrong perms somehow? -Thanks
Remember, if you're doing a fresh install to test this to remove the /var/lib/squeezecenter directory and subdirectories first (or, rename it if you don't want to lose the contents, of course), as they won't be removed by an unmerge operation. (In reply to comment #6) > (In reply to comment #5) > > Joe: I could easily add a step to the ebuild to force the permissions under > > /var/lib/squeezecenter/{cache,prefs}, but as these shouldn't really be there > > unless put there through the ebuild, and I think the ebuild creates them > > correctly at the moment, I'm not sure that's the right thing to do. What do you > > reckon? > > Let's see what the reporter says about this theory. Gerben, can you try a > fresh install like Stuart tried and see if your system maintains the state > correctly? Do you think the dir could have gotten the wrong perms somehow? > > -Thanks >
I don't remember ever having run squeezecenter as root, at least not willingly. I have had problems several times when stopping or (re)starting the service, though (service didn't start properly, had to zap or remove pidfile by hand, etc.). I'll try a clean install as you indicated, probably tomorrow or Wednesday.
(In reply to comment #8) > I'll try a clean install as you indicated, probably tomorrow or Wednesday. Right. It's been a year now. Closing this old bug. Reopen if you still have same issues with latest.
