With regard to persist.db, my impression is that the problem is one of disorganisation, possibly of the index records, rather than on of sheer size.
On a complete re-installation with no persist.db, and scanning for the 1st time, the custom browse/scan menus run fine. After the 1st rescan they are slow the 1st time they are run after a restart. I've several different menus, and each one based on different custom or mixed tags (eg Works by Composer) is slow until run the 1st time. My impression is that reading the indices into memory was itself taking time, and that once done, and presumably some of the related data, all was well. I experimented with deleting and recreating one index on persist.db (using a script kicked off via server power control). This worked well except LMS took several extra minutes to start. When I discovered the vacuum command, I ran this once after each rescan and had no menu delay problems. Apologies for not having precise measurements. All I can say is that with auto-vacuum on all databases, 100MB, and deleting the unused library.db indices, LMS 7.9 is running very well indeed, with almost instant responses to all actions. :) LMS 7.9 on VortexBox Midi running Xubuntu 14.04, FLACs 16->24 bit, 44.1->192kbps. Wired Touch + EDO, coax to Musical Fidelity M1 CLiC. Wireless Xubuntu 14.04 laptop controls LMS via Chromium. Meridian Explorer USB DAC to listen via Squeezelite on Vortexbox & other PCs as required. Spare Touch in loft. ------------------------------------------------------------------------ PasTim's Profile: http://forums.slimdevices.com/member.php?userid=41642 View this thread: http://forums.slimdevices.com/showthread.php?t=101469 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
