Bugzilla – Bug 945
can't use web interface while scanning at startup in 6.0a2
Last modified: 2008-09-15 14:37:04 UTC
Usually right after I start slimserver I'm able to go to the web interface and at least browse by directory to get some music playing, but now the web interface hangs, I'm assuming until scanning is done. I left it scanning for about 15 minutes and it still wasn't finished, and the web interface still hung. I confirmed that it wasn't a browser issue, telnetting to port 80 and doing a GET also timed out. about 25k songs, mix of flac and mp3, debian stable.
port 80? if you have forced slimserver to port 80, might there be a conflict? try with --d_server --d_info debugging on startup. you haven't specified OS, but if you can telnet, I'll assume you can run the server command line as well :) I haven't seen this myself with 6.0a2, or any of the nightlies. There was on exception last night where a loss of internet (apparenltly NOT just my area) caused rssnews plugin to lock the server out while it tried in vain to reach the news sites.
Er, sorry, meant telnetting to port 9000 :) I've been running with --d_info going to a file for a while now, ever since I had a few crashes with the first 6.0 alpha (which didn't have this problem for me). I've tried with --d_server --d_info and don't see anything weird, but there's quite a bit out output. Is there anything I can grep for? Moses
Couple more data points: Immediately after starting (like, telnetting to port 9000 repeatedly until it was no longer connection refused) lets me get the page once. Then it's the long (infinite?) wait for a page. After about half an hour I was able to get the page again (fairly speedily), but the web interface said that it was still scanning, and slimserver.pl was definitely still using CPU.
I suggested d_server becuase it tells you where it is in that startup process, just to be sure you get a complete startup. --d_info is a good one to use simply because it is chatty as all get out. I wouldn't worry about looking for anything specific for grep. More, just look for places where it stalls. Windows shortcuts that looped back on the music folder were notorious for taking down the server in 5.4. --d_scan might even be better, or --d_http if you want to look directly at the http get and response (I tend to find d_http just too chatty, and I never know what to look for in it) -kdf
(this is all under linux btw) It wasn't a lockup FWIW, I left one of the telnets going and after about an hour it finally gave me the page. After that the page loads were always fast. Very reproducible here, seems to happen whenever I start 6.0a2. And it seems I'm wrong, it does happen with 6.0a1 (SlimServer_v2005-02-23) now that I've reverted to that. The squeezebox also cannot connect to slimserver. Both via strace and the --d_info output it appears that slimserver is merrily going on its way finding all the files, and when it is done, everything behaves normally, it's just like the indexing thread is the only given any cpu time (athlon 2800, slimserver is using about 50-60% cpu during this time).
Ugh, sorry for multiple confusing posts. 6.0a1 definitely does not do this. There was a filehandle still open under my old symlink, so I thought I was running 6.0a1 but was actually running a2, and since I can't get to the web interface I couldn't verify. Now that I've killed everything off and restarted, a1 gives me a web page after the startup, and a2 does not. Thanks, Moses
Moses - is it possible for you to check out the latest subversion tree and see if the same behavior occurs? Thanks.
Seems to be fixed in the svn version, however now it dies after a while: Use of uninitialized value in hash element at /home/marmoset/trunk/server/Slim/Formats/Parse.pm line 284. Use of uninitialized value in hash element at /home/marmoset/trunk/server/Slim/Formats/Parse.pm line 284. 2005-03-03 16:53:40.1090 No URL specified for updateOrCreate Use of uninitialized value in concatenation (.) or string at /home/marmoset/trunk/server/Slim/Utils/Misc.pm line 820. 2005-03-03 16:53:40.1094 2005-03-03 16:53:40.1096 Backtrace: frame 0: Slim::DataStores::DBI::DBIStore::updateOrCreate (/home/marmoset/trunk/server/Slim/Formats/Parse.pm line 289) frame 1: Slim::Formats::Parse::parseCUE (/home/marmoset/trunk/server/Slim/Formats/Parse.pm line 430) frame 2: Slim::Formats::Parse::readCUE (/home/marmoset/trunk/server/Slim/Formats/Parse.pm line 52) frame 3: Slim::Formats::Parse::parseList (/home/marmoset/trunk/server/Slim/Utils/Scan.pm line 583) frame 4: Slim::Utils::Scan::readList (/home/marmoset/trunk/server/Slim/Utils/Scan.pm line 204) frame 5: Slim::Utils::Scan::addToList_run (/home/marmoset/trunk/server/Slim/Utils/Scheduler.pm line 95) frame 6: Slim::Utils::Scheduler::run_tasks (./slimserver.pl line 553) frame 7: main::idle (./slimserver.pl line 512) frame 8: main::main (./slimserver.pl line 1051) Can't call method "secs" on an undefined value at /home/marmoset/trunk/server/Slim/Formats/Parse.pm line 295. Also, FWIW, a2 takes a little over twice as long (4900s vs 1900s) as a1 to scan my collection. Moses
Michael - looks like we may need to do additional error checking here. Moses, any idea what cue file this might have crashed on? Also, I'm going to be out of town for the next few days, but will be online periodically.
this is where --d_info can be handy, or d_parse I'll try to pick up any slack while Dan's away if I can. as to scan time, 6.0a1 was missing a great deal of information that we need from readTags. This slows things down if you are using any of the importers. I think this also includes CUE files.
Ah, just checked the cue file in question, it is a null file.
revision 2312 should catch empty cuesheets and avoid this crash
Works now, thanks! Rescan time is back to a1 levels as well (around 1900s) so there was something in a2 that made it take longer that's been resolved. Moses
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.