>>it's far easier to demad change than to implement it (less accountability in the former).<<
I agree with that. But one should consider the user experience. If a scan is described as "playlist-only" when it is actually "NOT tracks, then playlists, then every other housekeeping task we usually do", it is not well described. Consider further the user preparing for a Christmas party, who is simply trying to get a playlist into SlimServer, and finds himself waiting ten minutes every time he tweaks the playlist and wants to try it again, and you might begin to understand the frustration that this problem engenders. >>I think it would be useful to know why the OP's case seems to take noticeably longer than other posted results, especially given the rather small playlist content.<< That is a good question, and I don't know the answer. The other posted result, where the scan phases all took in the tens of seconds, was significantly quicker than mine. Sidhue didn't mention how many tracks he is scanning, though . . . I have something like 31,000, which I take to be a large number. I also have a decently fast machine but by no means a barnburner, and running Win XP, which I believe is probably slower than Unix/Linux for the purpose. I will mention that upping the database cache size from 10,000 to 100,000 seems to have resulted in the time for the subsequent scans being cut to about four minutes from eight, which is nice . . . but it's still a long time to turn around adding a playlist to the system. In addition, one has to be a bytehead to figure out how to increase the cache size. The system ought to prompt the user about resizing its own cache, or do it dynamically, or SOMETHING that isn't "require the user to find the proper configuration file and edit it." I still don't completely understand why any further scanning is necessary for a playlist. As a list of tracks, any metadata searches or whatever of the playlists (are there such?) should just look through to the database tracks. I don't know what else you were alluding to when you said: "Every check through playlists involves gathering new data (even if the data is already in the database), which then needs post-scan processing to sort out where it fits into the database. . . . It isn't always about NEW data, but doing as good a job as possible to match the playlist information with all that has been done to organise the metadata for the tracks referenced." What is this new data? If the tracks are already in the database, there isn't any new data . . . if they are not, then by all means add them . . . It sounds like the working assumption at design time was that playlists might contain tracks not already in the database, so the scanner had better handle that on the fly by adding them. IF that's correct, I guess it's nice that it does that, but not so nice if it does it to the cost of all the users like myself, who put together playlists in text files based on what's already on the server, and just want to add them to the Slim database. -- smr888 ------------------------------------------------------------------------ smr888's Profile: http://forums.slimdevices.com/member.php?userid=2658 View this thread: http://forums.slimdevices.com/showthread.php?t=42540 _______________________________________________ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
