Bugzilla – Bug 17478
Zero artists reported in library statistics after a scan
Last modified: 2011-08-31 08:07:51 UTC
Some people encountered a bug with 7.6.1 RC releases where after a scan, the web UI will display zero artists in the library at the home page and information tab. See for example: http://forums.slimdevices.com/showthread.php?p=651152#post651152 http://forums.slimdevices.com/showthread.php?p=651376#post651376 Refreshing the browser won't help. Navigating to the Artists menus lists shows there are artists in the database. A server restart solves the problem.
Yep this was the case when the mandatory scan of the 7.6 33110 RC finished Seph has linked our comments but i will attach scanner and server logs to " Total Tracks: 31,712 Total Albums: 2,652 Total Artists: 0 Total Genres: 221 Total Playing Time: 2445:12:24 Home menu reports 1 song 1 album 0 artist However going in to the artist menu gives 1205 artist, which seems about right ? " Scan for new and changed does not seems to bring this issue.
Created attachment 7405 [details] server.log
Created attachment 7406 [details] scanner.log
Created attachment 7407 [details] screenshot
I see very similar, repeatably. Except I get "0 albums with 0 songs by 0 artists" in the home page. The big clue is the "Artists: 0" in library statistics, both in the web GUI and on an attached Touch.
Reported here too: http://forums.slimdevices.com/showpost.php?p=650126&postcount=2
You're all running some unix/linux flavour? Can't confirm... Are you using any importer plugins (eg. Erlands, iTunes, MIP)?
Using FreeBSD. No plugins other than those shipped out-of-the-box. rm *.db done before the wipe scan. I've not restarted SBS on my FitPC2 since seeing this on Friday (I just wanted to see how long the poor little thing would take to scan). http://virgin.xenopsyche.net:9000
Could you please verify this still happens with r33136? I've fixed bug 17479 which might have been the cause for this failure too.
r33138 seems to have fixed this for a subset (19k files) of my collection. Ta! I had to restart the browser (Opera/XP) to see the numbers displayed in the home page. Library Statistics was fine. Is this fix not being included in 7.6.1-RELEASE? That's the impression I get from reading the changelog.
Windows here.
No mip no itunes, some of erlands plugins but not custom scan or custombrowse trackstat ? Linux yes, I will upgrade and do a clear and rescan everything, scan for new or playlist did not show these problems.
Ok tried a rescan without upgrading, it worked just fine ? This bug may only be provoked when SBS does it forced rescan after install for your schema change. But that means that a lot of users installing RC3 is going to see this and assume that the scan is broken, not every one will be thinking " thats it's only a visual glitch" lets restart sbs and see if it goes away :-/ Can something be done after that one off initial scan You are planning to release 33110 RC3 as 7.6.1 without the improvements you done the last day ?
I upgraded to RC3 from 7.5.6 this morning and experienced this. After restarting the server, all the displayed totals were fine. Windows 7 box, BTW.
Full scan completed successfully (r33139). Browser displays correct counts after a refresh (not restart) with Opera/FreeBSD. I'm eagerly anticipating the release announcement. "We bust a gut squishing bugs over the last few days, please use the version without these fixes". :)
http://forums.slimdevices.com/showpost.php?p=653112&postcount=15 an example of user still having this issue, so it's not solved
Sigh. Updated my prod SBS to r33223 and got this again. What I did: stop SBS, rm cache/*.db, reinstall, restart. After full scan completes, browsing Albums, Genres, Years and New Music works, but browsing Artists puts SBS into a loop consuming most of one core. I guess it then times out the request.
Created attachment 7430 [details] home page screensnip
Created attachment 7431 [details] info page screensnip
Created attachment 7432 [details] scanner.log
Created attachment 7433 [details] server.log
I've been thinking about what Mikael wrote in comment 13. My prod server was upgraded from 7.6.1 r33094. Each of the others have been upgraded from something much more recent, and have been fine. What's different between a forced wipe scan and one triggered from the GUI? The prod server was running fine after a restart. This morning I looked to see how the scheduled new/changed scan had gone. Attachment br1.jpg. Note the (5785 of 2) at the bottom. And the Information page, attachment br2.jpg. Bug 17452? I tried, but failed, to get anything useful from debug logging. A second wipe scan seems to have cured the problem, a new/changed scan now runs OK. Very strange.
Created attachment 7435 [details] br1.jpg
Created attachment 7436 [details] br2.jpg
== Auto-comment from SVN commit #33234 to the slim repo by mherger == == http://svn.slimdevices.com/slim?view=revision&revision=33234 == Fixed Bug: 17478 Description: as long as counts are zero or undefined, don't cache values, but re-evaluate. If they're zero indeed, this shouldn't hurt.
Probable duplicate of bug 14465 and bug 14817?
bug 9037 bug 9704
Bah. This all came about by accident, it's not "systematic testing". One of the boxes I was using to test scanner performance a few weeks ago had two identical copies of OS+SBS r33094 on two drives. I'd been testing using a slow drive, I wanted to test a faster one. I booted the fast drive, stopped SBS, installed r33242, and restarted. Several hours later the wipe scan completed showing exactly what was expected. Even the cats were happy; justifiable pride at Herger Mansions, even made the scary backtrace vanish! Why, I'll never know, but I booted the slow drive, stopped SBS, installed r33242, rm *.db and restarted. Went to bed. You guessed. Screenshots attached. Same numbers when I looked from a Touch.
Created attachment 7441 [details] osx screenshot
Created attachment 7442 [details] same again
possibly this? bug 16112
== Auto-comment from SVN commit #33262 to the slim repo by mherger == == http://svn.slimdevices.com/slim?view=revision&revision=33262 == Bug: 17478 Description: wipe _all_ caches on a "rescan done" event
Ian - hard to tell what happened to your tests, unless you could provide us your scanner.log. But I found a case where I ended up with the results of the previous scan in the cache. This involved a crash of the scanner though. The changes I've applied now are to improve handling of the caches in case the scanner fails.
Created attachment 7443 [details] latest scanner.log
Created attachment 7444 [details] latest server.log
I haven't restarted it yet, been messing with FreeNAS. :) I doubt if they'll tell you anything -- they look just like the successful scans -- but server and scanner.log attached.