> or alternatively, don't do a complete >recheck until the size of the main folder has stabilised for a certain >duration ? (maybe that's what the setting does?)
No, the scan just checks for the modified time changing on the XML file. This seems like a really sensible suggestion as the user's iTunes activity is likely to come in bursts when adding tracks or modifying tags. I'd suggest opening this as an enhancement request... >Actually - I'm curious now - doesn't the perl script simply check the >iTunes cached file tables for changes, or is it plowing through all the >subfiles on the disk ? Can I make it do just the former if it's doing >the latter ? The scan checks the iTunes XML file. As I understand it, any new tracks are added to the database and the file scanned for tag info (the XML does not contain all the tags SlimServer requires - which ones are missing I wonder?) If a track is already in the database it is ignored unless the file modified time has changed. This is actually pretty quick if 99% of your library has not changed. What I find kills SlimServer performance is scanning of the playlists - I have a number of thousand+ track playlists and when they are scanned is when I lose connectivity. One enhancement already suggested is reading only selected playlists from the XML. >Another thought - on the mac platform, wouldn't it be possible to listen >for applescript notices/events or something to know when itunes is in >process of ripping or itunes-LAME is doing it's thing, and suspend any >synchronization until the end of the process ? The Slim developers like all the core functionality to be cross platform so I doubt that would be favoured. James -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. _______________________________________________ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
