View Full Version : Problems with rescan using 3/19 nightly

Steve Baumgarten
2005-03-22, 20:43
I mentioned a few days ago that it seemed like rescan wasn't working for
me, but I wanted to do some more testing. Now I'm seeing it again for
sure with the 3/19 nightly (running on Windows XP with Fishbone).

I just added several folders (each folder is an album containing well
tagged MP3 or FLAC files) to my library folder and clicked the "Rescan"
button on the "Server Settings" web page.

Watching the log, I can see it zipping through the library -- tons of
output that I'm looking at with tail. What I don't see is any mention of
any of the several new folders that were added! All the other folders,
the ones that have been there since I first installed the 3/19 nightly
and cranked it up for the first time, are all mentioned, but no mention
at all of the new ones.

Now I'm wondering if maybe it has something to do with my setup. I tell
Slimserver that my library path is:


That folder contains a single Windows shortcut called "New.lnk" which in
turn points to:


That's where all my albums are, each organized in a separate folder.

If I do a "wipe cache" or otherwise completely blow away the database,
all albums and tracks are correctly found. But otherwise a normal rescan
doesn't seem to pick up new ones.

Very odd. Very. I wish I could figure out how to proceed here.

Well, here's one thing. The rescan has definitely stopped. Nothing's
been written to the log file in a while; the UI doesn't show the "still
rescanning" message. I now do a "Browse Artists" in Fishbone and then
click on "S" (I added a "Swing Out Sister" album last night; that's one
of the ones that hasn't shown up in the log file). I got a blank
document back from the server (Firefox reports the error: "Document
contains no data") and this in the log file:

Modification of non-creatable array value attempted, subscript -75 at
/PerlApp/Slim/Web/Pages.pm line 2058.

That's something I've never seen or had happen before. Quite a
coincidence that it would happen just now after this unsuccessful
rescan, but I suppose it could just be a coincidence.

So I killed and restarted the Slimserver just now. Still doesn't pick up
the new folders/albums. And if I click on that "S", I get the same perl
error in the log file and a "Document contains no data" error.

OK, let's try "Wipe Cache".

And *now* I'm seeing signs of progress in the log file. Here's one
difference: when I just click "rescan" I see no evidence anywhere of the
Slimserver decoding the "New.lnk" shortcut, seeing that it's a
directory, then traversing the directory trying to find new folders.
Instead I see it hitting all the folders and files it already knows
about (sorry for the line wrapping, I can't figure out how to disable it):

2005-03-22 22:04:48.8104 pushing button mode: OFF.datetime
2005-03-22 22:04:48.8321 Got /F:/MP3/Squeezebox/Library from file url
2005-03-22 22:04:48.8492 extracted: F:\MP3\Squeezebox\Library from
2005-03-22 22:04:48.8706 Got /F:/MP3/Squeezebox/Library/New.lnk from
file url file:///F:/MP3/Squeezebox/Library/New.lnk
2005-03-22 22:04:48.8711 extracted: F:\MP3\Squeezebox\Library\New.lnk
from file:///F:/MP3/Squeezebox/Library/New.lnk
2005-03-22 22:04:48.8783 Got
/F:/MP3/New/'N%20Sync%20-%20Celebrity%20(2001) from file url
2005-03-22 22:04:48.8788 extracted: F:\MP3\New\'N Sync - Celebrity
(2001) from file:///F:/MP3/New/'N%20Sync%20-%20Celebrity%20(2001)

See how it goes right from New.lnk to hitting the first folder it
already knows about?

Now with the "Wipe Cache", I see this:

2005-03-22 22:07:48.4657 Scan::readList gonna read
2005-03-22 22:07:48.4681 Got /F:/MP3/Squeezebox/Library/New.lnk from
file url file:///F:/MP3/Squeezebox/Library/New.lnk
2005-03-22 22:07:48.4689 extracted: F:\MP3\Squeezebox\Library\New.lnk
from file:///F:/MP3/Squeezebox/Library/New.lnk
2005-03-22 22:07:48.4727 Got /F:/MP3/New from file url file:///F:/MP3/New
2005-03-22 22:07:48.4932 extracted: F:\MP3\New from file:///F:/MP3/New
2005-03-22 22:07:48.4941 pathFromWinShortcut: path file:///F:/MP3/New
from shortcut F:\MP3\Squeezebox\Library\New.lnk
2005-03-22 22:07:48.4968 Got /F:/MP3/Squeezebox/Library/New.lnk from
file url file:///F:/MP3/Squeezebox/Library/New.lnk
2005-03-22 22:07:48.4979 extracted: F:\MP3\Squeezebox\Library\New.lnk
from file:///F:/MP3/Squeezebox/Library/New.lnk
2005-03-22 22:07:48.6562 Gonna try to open playlist file:///F:/MP3/New
2005-03-22 22:07:48.6569 Got /F:/MP3/New from file url file:///F:/MP3/New
2005-03-22 22:07:48.6575 extracted: F:\MP3\New from file:///F:/MP3/New
2005-03-22 22:07:48.6633 *** didn't find file:///F:/MP3/New in playlist
cache ***
2005-03-22 22:07:48.6636 Treating directory like a playlist
2005-03-22 22:07:48.6640 reading directory: F:\MP3\New
2005-03-22 22:07:48.9615 directory: F:\MP3\New contains 712 items
2005-03-22 22:07:48.9681 directory
2005-03-22 22:07:48.9696 directory

Here you see it hitting New.lnk and then treating it like a directory
that needs to be descended into and searched.

Indeed, further down in the log file I see it picking up those new
albums. And I don't get any errors now when I click on the "S".

Hope this helps. One further step I could try: point Slimserver directly
at my library directory and not have it go through a Windows shortcut.
(Just guessing that this might work around the problem; unfortunately
it's getting too late in the evening for me to try this, but if no one
else is able to make progress on this bug, I'll give it a try in the
next day or so.)

I haven't opened a bug for this in Bugzilla, but I can if someone would
like me to.