PDA

View Full Version : Rescanning never stops ?



mrmattis
2005-08-14, 12:04
I have installed 6.2b1 - 3957, and my computer has been rescanning my library for 12 hours. It seems to never stop ? My library consist of about 35000 songs, and before it has stopped rescanning after about 3 hours.

What could be wrong ?

Roy

kdf
2005-08-14, 12:15
On 14-Aug-05, at 12:04 PM, mrmattis wrote:

>
> I have installed 6.2b1 - 3957, and my computer has been rescanning my
> library for 12 hours. It seems to never stop ? My library consist of
> about 35000 songs, and before it has stopped rescanning after about 3
> hours.
>
> What could be wrong ?
>
Do you have any shortcuts that point back to other places in the
library?

Try turning on d_import in server settings->debugging and load
http://serverIP:9000/log.txt.

Reload one of the browse pages and it should tell you which of the
scanners is still active.

-kdf

Philip Meyer
2005-08-14, 12:41
>I have installed 6.2b1 - 3957, and my computer has been rescanning my
>library for 12 hours. It seems to never stop ? My library consist of
>about 35000 songs, and before it has stopped rescanning after about 3
>hours.
>
I had problems about a week ago with rescanning. There were some problems where slimserver would somehow start iterating through all files on every hard disk/partition. For me, this was due to badly formed .m3u or .cue files.

You could try turning on d_scan and/or d_files to get more debug information, and looking at the log. This should identify at what point scanning goes wrong, or you might see it repeating the scan over the same files if there's some form of circular link in the filesystem.

Phil

ert
2005-09-26, 08:14
I had problems about a week ago with rescanning. There were some problems where slimserver would somehow start iterating through all files on every hard disk/partition. For me, this was due to badly formed .m3u or .cue files.

You could try turning on d_scan and/or d_files to get more debug information, and looking at the log. This should identify at what point scanning goes wrong, or you might see it repeating the scan over the same files if there's some form of circular link in the filesystem.

Good call, that appears to be exactly what's going on for me (I'm actually still on 6.1.1). I'm not sure how the transition happens, though:

2005-09-26 10:30:37.1908 itempath: file:///#CURTRACK%2071 and file:///Users/ert/Music/Playlists/Mellow%201-22-04.m3u made file:///#CURTRACK%2071

2005-09-26 10:30:37.2035 isList(file:///#CURTRACK%2071) == dir

2005-09-26 10:30:37.5583 Scan::readList gonna read file:///#CURTRACK%2071
2005-09-26 10:30:37.5609 Gonna try to open playlist file:///#CURTRACK%2071
2005-09-26 10:30:37.5902 *** didn't find file:///#CURTRACK%2071 in playlist cache ***
2005-09-26 10:30:37.5924 Treating directory like a playlist
2005-09-26 10:30:37.6192 directory entry: file:///.Spotlight-V100
2005-09-26 10:30:37.6557 directory entry: file:///.vol
2005-09-26 10:30:37.6912 directory entry: file:///Applications
2005-09-26 10:30:37.7264 directory entry: file:///Developer

...etc. etc. It *looks* like it hit the "#CURTRACK 71" entry at the top of one of my playlists and decided it was a file, but I'm not sure.

- Ert

dean
2005-09-26, 08:33
It looks like you've got a bad entry in the playlist:

file:///Users/ert/Music/Playlists/Mellow%201-22-04.m3u

Look for #CURTRACK 71 in that file and see if there's something
strange about the lines there.


On Sep 26, 2005, at 8:14 AM, ert wrote:

>
> Philip Meyer Wrote:
>
>> I had problems about a week ago with rescanning. There were some
>> problems where slimserver would somehow start iterating through all
>> files on every hard disk/partition. For me, this was due to badly
>> formed .m3u or .cue files.
>>
>> You could try turning on d_scan and/or d_files to get more debug
>> information, and looking at the log. This should identify at what
>> point scanning goes wrong, or you might see it repeating the scan
>> over
>> the same files if there's some form of circular link in the
>> filesystem.
>>
>
> Good call, that appears to be exactly what's going on for me (I'm
> actually still on 6.1.1). I'm not sure how the transition happens,
> though:
>
> 2005-09-26 10:30:37.1908 itempath: file:///#CURTRACK%2071 and
> file:///Users/ert/Music/Playlists/Mellow%201-22-04.m3u made
> file:///#CURTRACK%2071
>
> 2005-09-26 10:30:37.2035 isList(file:///#CURTRACK%2071) == dir
>
> 2005-09-26 10:30:37.5583 Scan::readList gonna read
> file:///#CURTRACK%2071
> 2005-09-26 10:30:37.5609 Gonna try to open playlist
> file:///#CURTRACK%2071
> 2005-09-26 10:30:37.5902 *** didn't find file:///#CURTRACK%2071 in
> playlist cache ***
> 2005-09-26 10:30:37.5924 Treating directory like a playlist
> 2005-09-26 10:30:37.6192 directory entry: file:///.Spotlight-V100
> 2005-09-26 10:30:37.6557 directory entry: file:///.vol
> 2005-09-26 10:30:37.6912 directory entry: file:///Applications
> 2005-09-26 10:30:37.7264 directory entry: file:///Developer
>
> ...etc. etc. It *looks* like it hit the "#CURTRACK 71" entry at the
> top of one of my playlists and decided it was a file, but I'm not
> sure.
>
> - Ert
>
>
> --
> ert
>

ert
2005-09-26, 09:17
It looks like you've got a bad entry in the playlist:

file:///Users/ert/Music/Playlists/Mellow%201-22-04.m3u

Look for #CURTRACK 71 in that file and see if there's something
strange about the lines there.


I didn't see anything odd about it, it's the first line in the file like the rest of the .m3u files, no control characters, well formatted, and there's >71 items in the playlist that follows.

I've tried throwing away the first two lines of the playlist ("#CURTRACK 71" and
"#EXTM3U") and now it hits "#EXTINF:-1,Secret" as the first line of the file and again falls into a directory scan. This time, however, it scans from the root of my music library instead of the root of my hard drives, which it's obviously supposed to be doing, anyway. Hopefully it'll finish up in a reasonable amount of time.

- Ert