Bugzilla – Bug 8966
SqueezeCenter should handle 'failures' in the DB or Cache directory better...
Last modified: 2009-09-08 09:22:03 UTC
Rather than constantly restarting when SqueezeCenter runs into an error, we should have a 'method' of showing the user something serious has failed. Perhaps a very basic text-based-webpage that gives the user some options like "wipe out DB/cache", "show me the error message", etc... We could have some kind of fail-safe mode where the second time SC starts up, it starts with -d_startup 1 and sends the output to a log file that is then visable in some basic web page... pretty much anything other than what we're doing now ... restart and pray it works.
bug 8108 deals with the same issues
It's not the same issue... one issue is a corrupted DB. The other issue is the DB server not even starting up... Both result in the same end-case for the user, but they happen for different reasons.
A more-ideal user experience could be done with a 'pre' web interface... Perhaps SC could start up initially with a super-basic web interface that shows the status of it loading up. That web interface could be configured to show the user any DB or Cache failures and give them basic options: Message: You're SqueezeCenter caching database has been corrupted. No settings or information has been lost, but we need to rebuidl this database before we can finish starting up. Would you like me to do this? Option 1: yes, rebuild and start up. Option 2: no, quit SC One advantage of this type of system wouls be that the "pre-webserver" could also send back statistics to us to give us a real idea of the number of DB, Cache, and other failures that occur. It could even send back automatic log messages for troubleshooting these errors.
would it make sense to also tie this into the cleanup script mherger is working on?
Retargeting to 8.0.
There should be no need for a "pre" web interface. Why should the web interface (or any interface for that matter) require the database? SC doesn't store _any_ of its configuration data in the database. This behavior is long lost holdover from the pre 6.0 days when cache=database and all data was loaded directly into server memory. The server should at least start up and do something coherent when it's unable to connect to the dbms. Just shutting down or continuously restarting is as unfriendly as you could possibly get. Display a nicely worded, helpful error message in all interfaces. This is another bug that has little or nothing to do with a database schema redesign.