Bugzilla – Bug 15544
Squeezebox Server fails to start with certain characters in server.prefs
Last modified: 2010-03-02 22:54:46 UTC
Created attachment 6471 [details] Problematic server.prefs file I recently had a problem where my SBS failed to run after a forced reboot of my WHS box (due to automatic install of IE8 security update). The event log contained: Faulting application SqueezeSvr.exe, version 28947.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00000000. Fault bucket 1673587793. I tried uninstalling (but took the option to retain settings) and re-installing bot 7.4.1 and the latest 7.4.2. Still no luck, and more event log errors such as: The description for Event ID ( 0 ) in Source ( Application ) cannot be found. Either the component that raises this event is not installed on your local computer, or the installation is corrupted. You can install or repair the component on the local computer, or contact the component manufacturer for a newer version. Product: Squeezebox Server 7.4.2-29879 for Windows Home Server -- Error 1920. Service 'squeezesvc' (squeezesvc) failed to start. Verify that you have sufficient privileges to start system services. After some experimentation and very helpful advice from the forum, it became apparent that my server.prefs file somehow had characters in it which the SBS service did not like: > apps: &10 &4 > presets: &11 &5 I removed those ampersand related fields, tried again, and the service started up OK. I'm running OK now, but mherger asked me to log a bug, so it could be investigated from the point of view of recovering from a bad prefs file. I have attached the one that caused me / SBS problems. The forum thread where this was discussed is - http://forums.slimdevices.com/showthread.php?t=74401 As a suggestion, each time SBS reads (and validates) the file, perhaps it should copy it to server.prefs.good (or something), so a known good file is available for recovery.
the &x and *x are representations of redundant data (see http://yaml.org/spec/1.0/#id2489959). What I don't understand though is why one node would be using two different IDs. Replacing one of them with the other one would probably have resolved the issue too.