Bug 1507 - rescan not picking up new items in the music folder on Windows (itunes not involved)
: rescan not picking up new items in the music folder on Windows (itunes not in...
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Database
: 6.0.2
: PC All
: P2 major with 1 vote (vote)
: ---
Assigned To: Dan Sully
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-06 12:39 UTC by Kevin Pearsall
Modified: 2008-08-18 10:54 UTC (History)
0 users

See Also:
Category: ---


Attachments
Log file from MWG as mentioned, zipped (3.88 MB, text/plain)
2005-05-06 15:26 UTC, Michael W. Gilbert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Pearsall 2005-05-06 12:39:20 UTC
Customer reported, but I still have not been able to reproduce this, and have
not been able to figure out why...  This is with the 6.0.2 release version, on
Windows XP Pro.

Wipe cache does work, but rescan should be also...

Not sure what additional data may be necessary here.  I will ask MWG to zip up
the log

Note from MWG:
-------------------
OK, I followed the directions, and have a slimlog.txt file
(the new music of the day is D:\Black Noodle Project - And Life Goes On\)

Howevr, I have a large collection (>2600 albums, i.e. directories)
05/05/2005  11:43 PM        57,851,562 slimlog.txt
This makes for quite an un-email-able slimlog.txt.

A few things:

- A search through the slimlog.txt shows the absence of any reference to the new
dir or files within.
- Going through the web interface, "browse music folder" fails to turn up any
reference to the new dir or files within.
- If I do the wipe cache, the system happily finds the new dir and files within.
- Then going through the web interface, "browse music folder" now shows the new
dir and files within as well.
-------------------

Instructions were as such:
-------------------
If log.txt is only showing us the tail end of the scan, we will have to do this
a bit differently...  I think what you would want to do is:
- stop slimserver
- add a new album
- run the server from the command line with a log file specified**
- give the server a couple of minutes to cool down after it starts
- check to see if the album is still missing

** To start it from the command line you would want to:
- click start
- click run
- type in 'cmd' and hit enter
- key in the following commands:
cd \program files
cd slimserver
cd server
slim.exe -d_scan -d_files -logfile=slimlog.txt

- then check to see if the album is missing in the web interface
- if you verify that it's missing, go in to Server Settings and click Rescan
- wait until the rescan is done (you can go in to Browse Artists and keep
refreshing the page--once it has a count instead of the still scanning message,
you're good)
- then send me the slimlog.txt file?
-------------------
Comment 1 Michael W. Gilbert 2005-05-06 15:26:03 UTC
Created attachment 494 [details]
Log file from MWG as mentioned, zipped
Comment 2 Michael W. Gilbert 2005-05-11 17:38:59 UTC
This was from a very recent forum post:

"When I create new folders in my music library location (D:\) the slimserver 
or squeezebox does not find them."

"A funny twist... I put an MP3 file in an existing empty folder that's been 
there since day 1 and the file was found no problem."

Everytime I add music, I add an album, which is adding a new subfolder. The 
difference between rescan and wipe cache may be that rescan is looking for new 
files in an existing tree structure, but wipe cache recreates the structure.

Comment 3 shawn moore 2005-05-13 00:05:48 UTC
I had this problem also.  I believe this behavior occurs on large (very large?)
libraries that have a high number of folders in the root music library folder. 
My root library was d:\ and contained 753 folder.  My entire library contains
8175 folders and >15,000 files.  When I reorganized to make my music library
folder D:\My Music and created 27 subfolders (123, A,B,C...Z) I no longer have
this problem.  Now adding folders/files to the root library folder or subfolders
appear in slimserver and squeezebox immediately without even doing a rescan.

Also, when I had the problem I watched the slim.exe service CPU utilization and
noticed doing a rescan didn't kick in the service at all.
Comment 4 Blackketter Dean 2005-06-13 17:20:51 UTC
Kevin: can you try to reproduce this with the directory in question being at the root of a windows 
volume (either network or local?)
Comment 5 Dan Sully 2005-06-24 11:04:31 UTC
Please see if this is still an issue in the 6.1 branch - about to be release as a beta.

Thanks
Comment 6 Vidur Apparao 2005-06-30 15:11:57 UTC
Can someone confirm whether this was fixed in 6.1b1 with Dan's changes?
Comment 7 shawn moore 2005-07-01 05:00:30 UTC
OK.  So I installed 6.1b1 and bottom line is it seems to work.  I had 570 
folders off of D:\ and it would instantly pick up new folders/files without 
even doing a manual rescan.  
That said, having so many folders off the root is still promlematic.  It took 
25 minutes to scan my library.  During this time I could not operate the 
squeezebox or the slimserver web interface.  My squeezebox actually froze the 
clock and would not respond to the power button on the remote.  Once the scan 
had completed everything worked fine but it was really trying my patience.
For comparison, I put all my folders/music back in their A,B,C,etc.. folders 
and changed my server folder to D:\Music1 which has my 27 main folders.  I was 
able to play tracks even at the end of my list (letter Y) practically 
instantly.  
For what it's worth I'm happy with the alphabet setup, scrolling through 
hundreds of folders to get to a particular album is a drag anyway.
Comment 8 Dan Sully 2005-07-01 11:07:51 UTC
Ok - sounds good.

I'm going to close this bug  now - there's another bug regarding the blank screen already. (can't find it 
right now).
Comment 9 Chris Owens 2008-03-11 11:28:14 UTC
This bug was marked resolved in Slimserver 6.1, which is several versions ago.  If you're still seeing this bug, please re-open it.  Thanks!