arressen wrote: > > - is it possible that we could have settings control over how aggressive > the startup process is? The decision on whether we want to hit the > server hard or not is then our choice to trade off one versus the > other. > - alternatively, would it be possible to cache the player details and > refresh in the background, similar to the library media content? >
No, that's not how this works. The problem with the previous way of handling the startup was that the aggressive reconnect often re-requested everything even though the original menu was fine but just a little late, throwing away perfectly fine data and therefore actually making the startup process much longer for a lot of users. In a well-working setup the whole menu should load within 3-5s after start. Caching is risky, the concept is that the menu is only valid at the time it gets transmitted by the server so there is no indication whether it still is. All other Apps and the Squeezeboxes also re-request it every time it's opened, the Squeezeboxes, however, maintain a permanent connection to the server as long as they are powered on, something an App can only do while it's running. A previously cached menu could be wrong in many points and there would be no way to know about it. What we need to do is find out about what's going wrong in your case and why it's taking the server longer than the usual 2-3s to deliver a menu. What I see for my server is that usually the first time I request a menu after not having used it from a client for a longer time (12h or so) it takes longer for the menu to be delivered. I believe that is because the menu, too, gets _created_ on the server side only after it is requested and then it's cached for a while, I don't know how long but definitely hours. If the menu is cached, it can be delivered more or less instantaneously. In my setup, a "cold" start requiring after several hours of not using a client takes around 20s for the menu to show up, all consecutive requests will then be fast for several hours, even from other clients. This _might_ be because my library NAS goes to sleep and takes several seconds to wake up, maybe the server will check something on that disc before returning the menu, my server itself never sleeps. Your nightly rescans also might play a role. So a few more questions: - If it takes "long" for iPeng to get the menu, _how_ long exactly is that? 20s? A Minute? - Does it get better on consecutive starts? - Does your server and/or iThingy change it's IP address? - Do you do a "Clear&Rescan" overnight? This would add a lot of load on iPeng's initial start because after a clear&rescan iPeng will throw away it's cache and re-request everything (the cache would be worthless and invalid anyhow) creating a lot of load and delays. It's usually better to do an incremental rescan, especially with 7.8 which no longer has 7.7's limitations (e.g. changed artwork will now be found) - Is there anything in server.log after iPeng connects and takes long to get the menu? Could you send me a server.log? --- learn more about iPeng, the iPhone and iPad remote for the Squeezebox and Logitech UE Smart Radio as well as iPeng Party, the free Party-App, at penguinlovesmusic.com *New: iPeng 8, the Universal App for iOS 7 and iOS 8* ------------------------------------------------------------------------ pippin's Profile: http://forums.slimdevices.com/member.php?userid=13777 View this thread: http://forums.slimdevices.com/showthread.php?t=51929 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
