Bug 1441 - Option to disable automatic iTunes scanning
: Option to disable automatic iTunes scanning
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: iTunes
: 6.1.0
: All All
: P2 enhancement (vote)
: ---
Assigned To: KDF
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-26 06:32 UTC by James Craig
Modified: 2008-09-15 14:36 UTC (History)
0 users

See Also:
Category: ---


Attachments
bypass rescan if interval set to 0 (654 bytes, patch)
2005-04-26 10:12 UTC, KDF
Details | Diff
with strings change (2.78 KB, patch)
2005-04-26 11:51 UTC, KDF
Details | Diff
update patch, and fix date (930 bytes, patch)
2005-07-27 23:30 UTC, KDF
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description James Craig 2005-04-26 06:32:13 UTC
Please consider allowing the user to disable automated iTunes scanning.

The rescan is so disruptive right now that I would rather have it disabled and
use the rescan plugin to run it at a point when I'm unlikely to be listening to
music.

Setting the rescan interval to a 'very large' number is not very nice.
Comment 1 KDF 2005-04-26 09:55:06 UTC
I believe you suggested 0 as an option for 'no rescan'.  I can take care of
this, for 6.1 at least.
Comment 2 KDF 2005-04-26 10:12:25 UTC
Created attachment 460 [details]
bypass rescan if interval set to 0

this will still display debug messages (d_itunes) that the itunes library has
changed but will then bypass, showing debug info that the rescan is disabled.
Comment 3 KDF 2005-04-26 11:51:34 UTC
Created attachment 461 [details]
with strings change

just a slight change to strings to mention the zero value
Comment 4 KDF 2005-04-27 01:44:26 UTC
committed to 6.1 at change 3091.  repoen if there are any more issues with this.
Comment 5 James Craig 2005-07-25 12:59:10 UTC
Doesn't seem to work in 6.2?
Keeps rescanning iTunes library even though I have the interval set to 0.
Comment 6 KDF 2005-07-25 13:03:52 UTC
d_itunes logs please.
Comment 7 James Craig 2005-07-25 14:15:27 UTC
from starting the server I get this:

2005-07-25 22:13:35.3751 iTunes: attempting to locate iTunes Music Library.xml
2005-07-25 22:13:35.3775 iTunes: found My Music here: C:\Documents and
Settings\James\My Documents\My Music for C:\Docum
ents and Settings\James\My Documents\My Music\iTunes\iTunes Music Library.xml
2005-07-25 22:13:35.3787 iTunes: found path via Windows registry at:
C:\Documents and Settings\James\My Documents\My Mus
ic\iTunes\iTunes Music Library.xml
2005-07-25 22:13:35.3792 iTunes: attempting to locate iTunes library relative to
C:\Documents and Settings\James\My Docu
ments\My Music\iTunes\iTunes Music Library.xml.
2005-07-25 22:13:35.3803 iTunes: set iTunes library to itunes_library_music_path
value of: E:\iTunes
2005-07-25 22:13:45.3821 iTunes: music library has changed: Mon Jul 25 20:56:28 2005
2005-07-25 22:13:45.3826 iTunes: using itunes library: 1
2005-07-25 22:13:45.3828 iTunes: startScan on file: C:\Documents and
Settings\James\My Documents\My Music\iTunes\iTunes
Music Library.xml
2005-07-25 22:13:45.3838 iTunes: opening iTunes Library XML file.
2005-07-25 22:13:45.3847 iTunes: Resetting scan state.
2005-07-25 22:13:45.3854 iTunes: Attempting to get lock on iTunes Library XML file.
2005-07-25 22:13:45.3858 iTunes: Got file lock on iTunes Library
2005-07-25 22:13:45.3860 iTunes: Created a new Non-blocking XML parser.
2005-07-25 22:13:45.3996 iTunes: Parsing next bit of XML..
2005-07-25 22:13:45.4388 iTunes: found the music folder: file://localhost/E:/iTunes
2005-07-25 22:13:45.4395 iTunes: starting track parsing

in prefs file - 
itunesscaninterval: 0
Comment 8 KDF 2005-07-25 14:19:00 UTC
how about after one scan has been completed, instead of on a restart? Does it
rescan after every change then? 
Comment 9 KDF 2005-07-25 14:23:15 UTC
for get that last comment.  It looks like (for whatever reason) change 3091,
which did fix this problem, has been rmeoved from this revamped iTunes parser in
6.2.  Simple to fix, just apply the same diff in attachment 461 [details].  Line numbers
should be close enough to still fit in.
Comment 10 James Craig 2005-07-25 14:27:23 UTC
scan completes...

2005-07-25 22:19:06.7545 iTunes: got a playlist array of 3255 items
2005-07-25 22:19:06.7557 iTunes: got a playlist (itunesplaylist:Unrated) named
Unrated
2005-07-25 22:19:20.2656 iTunes: playlists now has 3255 items...
2005-07-25 22:19:20.2812 iTunes: Finished scanning iTunes XML
2005-07-25 22:19:20.2820 iTunes: done Scanning: unlocking and closing
2005-07-25 22:19:20.3393 iTunes: scan completed in 335 seconds.

nothing in the log now - didn't it use to print a message every 60 seconds
saying it was checking the xml date?
So now I go and change something in iTunes...a few seconds later...

2005-07-25 22:22:40.5326 iTunes: music library has changed: Mon Jul 25 20:57:31 2005
2005-07-25 22:22:40.5336 iTunes: using itunes library: 1
2005-07-25 22:22:40.5342 iTunes: startScan on file: C:\Documents and
Settings\James\My Documents\My Music\iTunes\iTunes
Music Library.xml
2005-07-25 22:22:40.5397 iTunes: opening iTunes Library XML file.
2005-07-25 22:22:40.5417 iTunes: Resetting scan state.
2005-07-25 22:22:40.5938 iTunes: Attempting to get lock on iTunes Library XML file.
2005-07-25 22:22:40.5945 iTunes: Got file lock on iTunes Library
2005-07-25 22:22:40.5950 iTunes: Created a new Non-blocking XML parser.
2005-07-25 22:22:40.5960 iTunes: Parsing next bit of XML..
2005-07-25 22:22:40.6405 iTunes: found the music folder: file://localhost/E:/iTunes
2005-07-25 22:22:40.6417 iTunes: starting track parsing


ah I see you found the problem. I notice the dates seem a bit random though -
Windows says the file was actually modified on:
25 July 2005, 22:22:40
Comment 11 KDF 2005-07-27 23:30:36 UTC
Created attachment 677 [details]
update patch, and fix date

apparently (stat $file)[9] gives a different result than (stat($file))[9]). 
The former was found in scanFunction, so I changed it and it seems to now
report the right date.	updated the old 0 interval patch to get exact line
numbers for location.
Comment 12 KDF 2005-07-28 21:33:22 UTC
committed to trunk at change 3815