Erland, Thanks for your help. Having dug around a bit, and tried a few things, it seems clear that the issue is getting sufficient indices and data into cache. Whilst my menus could be tidied up, they aren't the main cause of the delay on 1st use after boot.
I've seen suggestions of trying to change cache size at startup using server power control, but they don't seem to help. I also tried adding an index or two to persist.db tables, to no great benefit. The one thing that worked was dropping and recreating an index in your dbindex.sql (I don't think it matters much which one - I chose module_attr_valuesort_cstrackidx since a value is needed on all rows, and the sort version is used for sorting as well) . However, this adds around 7 minutes to the startup time. I have therefore re-evaluated how I manage the power saving on my Vortexbox. I will 'suspend' the box after an hour of idle, rather than 'hibernate' (which gave me odd sound problems after a few restarts) or shutdown. Suspend seems to keep the cache, at least for a while. I'll just have to start the box 1st thing in the morning when I'm not using it immediately. I don't know how quickly the cache will 'drain', but will try this for a few days and see how it goes. LMS 7.8 on VortexBox Midi, FLACs 16->24 bit, 44.1->192kbps. Touch with EDO on Ethernet, coax out to a Musical Fidelity M1 CLiC. Wireless Xubuntu laptop controls server using Chromium. Meridian Explorer USB DAC to listen to LMS 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
