Having moved from one version of linux to another I thought my slow custom browse/scan menus were now sorted. I was too quick to judgement.
I have a menu (of several, but this is the worst) that takes around 4 minutes to appear the first time it is run when LMS is started. I have spent a great deal of time tweaking the sql to little effect. On the previous platform I had added a 'drop index' to one of the customscan_track_attributes tables in the dbindex.sql file of customscan. This seemed to work but added ~7 minutes to startup. When I started on the new platform all seemed well. However, it soon slowed down again. What was going on? I have done some experiments and think I have narrowed down a problem area, and got a solution for myself. 1. In all cases I have all custom_scan options for refreshing and rescanning set to 'yes'. I am on the latest LMS 7.8 and latest plugins. 2. I start with a system that is responding quickly. 3. I do a complete clean LMS rescan (including custom scan) 4. The system still seems quick. 5. I reboot. The menus are now slow again 1st time. 6. I try the refresh/optimize button on the custom scan settings screen. The menus are still quick (but I have run some already so that's no surprise). 7. I reboot. The menus are now slow again 1st time. 8. I stop LMS. I use the firefox SQLite Manager to open the persist.db and analyze it, which takes a few minutes (I did have to change the access control on the cache directory and the persist.db file to be able to work on it). 9. I reboot. The menus are now slow again 1st time. 10. I stop LMS. I use the firefox SQLite Manager to open the persist.db (which is currently 537,406,464 bytes long, 524,811 pages) and compact it. This takes a few minutes. The database is now 516,518,912 bytes long (504,413 Pages) 11. I reboot. The menus are now quick, 1-3 seconds for the most complex ones. So it looks as if: A. When a new persist.db is created from scratch (initial installation) it works fine. B. After a complete clean LMS rescan (including customs scan but which which does not seem to delete and recreate persist.db) the system is slow. C. Compacting persist.db solves the problem. Why this solves the problem I do not know, but if I compact the database after a rescan it seems fine. I'll look to creating a command file to do it for me. LMS 7.8 on VortexBox Midi running Xubuntu 13.10, FLACs 16->24 bit, 44.1->192kbps. Wired Touch + EDO, coax to Musical Fidelity M1 CLiC. Wireless Xubuntu 12.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=49483 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
