mherger wrote: > > But is the cleanup/wipe DB stage any faster now, with the smaller file? >
Definitely. Wiping the smaller artwork db is instant (<1sec). > > I'd still go with the max parameter. With 20k tracks it won't use > gigabytes of memory. I'm even using it on my poor little ReadyNAS Duo V2 > > with IIRC 512MB RAM :-). The more aggressive caching isn't limited to > the scanner, but to the server as well. > Yes, I'll keep it to the max. mherger wrote: > > BTW: your files as well as mr-b's confirmed what I was expecting. In > both files auto_vacuum wasn't enabled. This would lead to the database > not freeing disk space when data is deleted. It would require a manual > vacuum. Unfortunately you can't change the auto_vacuum flag in SQLite > without running that full vacuum - which I decided not to do in the > server, as it can block the database for quite a while. Therefore I > asked you to delete the file to make LMS set that flag on the newly > created file. They should no longer grow as big as they were before. > Makes sense. The delay of ~2mins for my old big artwork db was not really a problem. But if this phase is 10mins or more for bigger libs or as I've experienced it in older versions it's already a bit different. Thanks a lot. ------------------------------------------------------------------------ reinholdk's Profile: http://forums.slimdevices.com/member.php?userid=36070 View this thread: http://forums.slimdevices.com/showthread.php?t=106853 _______________________________________________ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
