Bugzilla – Bug 8881
Configuration wizard fails to appear on fresh install
Last modified: 2009-07-31 10:25:31 UTC
L.S. The system is an opensuse 11.0 x86 machine. The modules from CPAN are up to date. Perl is of version v5.10.0 mysql Ver 14.12 Distrib 5.0.51a, for suse-linux-gnu (i686) using readline 5.2 Installed from nightlybuids. /var/lib/squeezecenter was rm'ed befor installation squeezecenter-7.1-0.1.21998.noarch.rpm squeezecenter-7.1-0.1.22103.noarch.rpm The center starts and is accessible from remote and player (Duet) server log shows: cat /var/log/squeezecenter/server.log [08-07-26 13:35:34.2869] Slim::Schema::init (161) Warning: Creating new database - empty database or database from 6.3.x found [08-07-26 13:35:37.1744] main::checkDataSource (887) Warning: Schema updated or no tracks in the database, initiating scan. Both firefox 3.0.1 and IE 7.0 do not show wizard page. Upon accessing http://srv01:9000/ I get redirected to: http://srv01:9000/settings/server/wizard.html This displays the rotating balls image and "Squeezecenter wordt geladen" (is being loaded) since my locale is Dutch. Changing the preferred language setting in the browser does change the text, but it still stays in the 'loading' phase. What can I do to check for causes?
Do you have JavaScript enabled? Try clearing the cache and fully reload the page. Also check for JS errors (bottom left in IE), give Firebug a try on FF. This is working fine here.
IE does report an issue with JS. Line 144, Char 2, Error: "'Strings' is undefined" Code 0 And the url Now I did get to see the 1st page once not completely rendered and in the background the revolving animation and 'loading' text was still visible. So it looks like as of the page does indeed get stuck.. And that it works for you ... I do not know firebug, but on 1st inspection it is the same issue with firefox. The page is not rendered over the loading screen, but the elements are already in place, but hidden. Being a n00b on current web techniques I cannot tell you what the precise issue is. But there is one there.
This indeed looks like a caching issue: the page served seems to be stale, refering to files which no longer exist. Please shut down SC, and remove /var/lib/squeezecenter/cache/FileCache/. Then restart (and don't forget to fully reload the page). Are you using some kind of proxy server?
I followed the actions proposed. There is no proxy being used for connecting to the server. I can also confirm the behaviour in Konqueror 4.0.4 which worked perfectly with the new default UI of 7.0.1 Caching is turned of in Konqueror Konqueror reports the same JS issue as JS does. Can I change a setting somewhere so I get one of the lesser fancy UI's as a workaround? Regards, Arjen
Please clear your server cache as described in my previous comment.
Please note the 1st sentence of my previous comment: "I followed the actions proposed." But just to show what I did precisely: srv01:/ # /etc/init.d/squeezecenter stop Stopping SqueezeCenter: done srv01:/ # rm -rf /var/lib/squeezecenter/cache/FileCache/ srv01:/ # /etc/init.d/squeezecenter start Starting SqueezeCenter: done srv01:/ # Please note that I did already do multiple clean installs with 2 nightly builds. After deinstalling each rpm I rm'd the whole /var/lib/squeezecenter Regards, Arjen
Could you please add "--debug network.http=info" to your SC's startup configuration (/etc/sysconfig or similar). Then restart, try to open the web UI, and upload server.log to this bug. Thanks!
Created attachment 3694 [details] server log when started with "--debug network.http=info"
Arjen - I'm sorry, I really don't see what might be wrong. I'm unassigning to get more eyes on this issue. QA - could you please try to reproduce this on a clean system? No SC/SS installed before, no server.log etc. Thanks!
I did a clean install myself too, on another machine. Of course it worked there.... which annoyed me considerable. So I tried to see if I really really cleaned out squeezecenter. Locate squeez gave me a lot of files which I could check for. None found. Then somewhere in a dark crevasse of the brain I recall having tried the slimserver a long time ago. # rpm -qa | grep slim slimserver-6.2.1-1 # rpm -e slimserver slimserver: unknown service error: %preun(slimserver-6.2.1-1.noarch) scriptlet failed, exit status 1 # rpm -e --noscript slimserver New install. all ok. Now I recall that I did saw this script error before, but since it all worked (then) I filed it under, "you get that some times, all linux systems not being the same and such" 7.0.1 Had no problem.. but well. 7.1 does. So the issue is a little pebkac, a less tech savvy user would have a bit of an issue here, and actually an issue with the rpm package for slimserver 6.2.1 It does not show in the RPM that squeezecenter is a replacement for slimserver and I do not find any reference to the slimserver in the installation scripts, I guess that maybe you test for it in the squeezecenter 1st run script??? In that case run rpm with the --noscript if the regular deinstall fails.. This is what it resolved for me. A rare case I guess... Michael, I thank you for your time and patience. It is appreciated. Regards, Arjen
Ok, ok, slowly... > In that case run rpm with the --noscript if the regular deinstall fails.. > > This is what it resolved for me. You mean some remains from an earlier 6.x installation made SC fail on that box?!? Wow, bordercase indeed... thanks for letting us know!
A couple of comments about the RPM: 1) The SC RPM uses "Obsoletes: slimserver, SliMP3" to avoid having SC and SS installed at the same time and yum handles this dependency automatically. On non-yum systems like SUSE, you have to upgrade from SS to SC with "rpm -Uvh" since "rpm -ivh" will leave them both installed. This is an unfortunate "feature" of rpm and is already documented at http://wiki.slimdevices.com/index.php/SqueezeCenterRPM. There's nothing we can do in the SC RPM to change this. 2) The "scriptlet failed" error is a bug in the 6.2.1 RPM. Again, there's nothing we can do to the SC RPM to fix this. If I get a chance, I'll try to figure out which part of the scriplet fails and document it in the wiki.
Reduce number of active targets for SC