Firstly thanks for taking the time to produce this plugin and support it via the forums. It’s a mammoth feat of coding!
I noticed performance on my Vera Lite was not good, after installing the plugin. The CPU was hovering at around 50% and memory was at 196%. I put in a few debugging log commands and tracked down the following code:
If this is removed then my CPU goes back down to around zero and memory down to 184%. Everything seems to work ok (!).
I started thinking about this… I guess you want to get the queue so that you can populate the drop down list in the Vera GUI. It seems that as the Queue can be very large indeed, that getting it regularly will not scale.
Can you tell me a bit more about the reasons for getting the Queue, and what you think about and have experienced with respect to the performance?
If you have installed the UPnP event proxy, the queue content will be requested not very often, only when there is a change (and in few other cases like when you reload lua).
If you have not installed the proxy, it will be done every 15s.
Regarding the performance, this call could lead to large pattern matching if you have a very big queue.
I have already fixed some performance issues relative to pattern matching but not in this function. I will check that.
And yes, the idea is to have in the plugin the current state (content) of the Sonos queue.
Is there any limit on the amount of data you can insert into a device variable? I think playing all songs on shuffle is a common use case, and can easily result in 10,000 items in the queue.
I would try to keep data in device variables to a minimum as this will make your user_data file very large and could cause performance issues with 3rd party apps and even vera.
I think at the moment (correct me if I’m wrong), that the full queue is grabbed from Sonos and stored into a device variable, though I disabled that feature locally in the code to solve performance problems on my Vera Lite.
[quote=“garrettwp, post:4, topic:178334”]I would try to keep data in device variables to a minimum as this will make your user_data file very large and could cause performance issues with 3rd party apps and even vera.
Garrett[/quote]
Yes, of course, that’s a good principle.
But using variable is the only solution provided by MCV to exchange data between the Vera UI and the lua.
Or is there another solution I don’t know ?
If I suppress this variable, I could no more display the queue content in the UI.
One time again, it should not be a performance issue for your Vera if you have installed the UPnP proxy, because this code will be run only when your queue is updated, that means not really often.
How many entries have you in your queue ?
I will check how much time it takes to browse such a queue, and try to optimize it if possible.
It sounds like there are 2 possible performance problems:
When updating the queue in Vera (due to length of data to parse)
Issues in other processes, caused by the size of the user data
I agree that (1) is reduced when adding the event proxy. Issue (2) is more worrying as it is less easily traceable and predictable. I know nothing about the potential issues here so have to revert to someone with more in-depth knowledge of vera.
I have done minor changes in browseContent, I am not sure it will really change performance significantly. You can try with the current version in trunk: trunk – Sonos Wireless HiFi Music Systems
How many items have you in your Sonos queue ?
I could add an advanced option to let the user define a maximum number of items to retireve.
What would be a reasonable number ?
More generally, what would be the maximum size to apply for a variable ?
I use another variable for favorite radios that could be big too if the user has defined in Sonos a very long list of favorite stations. Same thing for Sonos playlists.
I get the possibility to reduce the size of data in variables that stores information relative to Sonos playlists, favorite radios and queue. Of course, it will not improove performance as I will have to parse the big XML data, but will reduce size of stored data.
I have committed the change relative to the value for the 3 variables SavedQueues, FavoritesRadios and Queue.
For example, the size of the string value for the queue content is divided by around 50 ! I am now only storing the title of each queue item.
Thanks for the change I had some problem with my app; it has to load all this data and on long playlists it started to run into network timeouts. The new version loads a lot quicker!
I have tried the new code. I added my full library of 14,000 tracks to the queue on shuffle. This caused my Vera Lite to go to 100% CPU and >200% memory usage. I had to kill /usr/bin/LuaUPnP to recover.
Even with the requesting of the queue disabled, by commenting the following 2 lines out, Vera cannot survive the full library being added to the queue. It reboots after a couple of mins.
[quote=“chrisbirkinshaw, post:14, topic:178334”]Even with the requesting of the queue disabled, by commenting the following 2 lines out, Vera cannot survive the full library being added to the queue. It reboots after a couple of mins.
What other functions can return a large amount of data when the queue is big?[/quote]
The big value was probably set in the Queue variable of your device before you commented the two lines.
Set this variable to “” with a luup code and your problem should be fixed. Alternative: delete your device and create it again.
I have committed changes (in the trunk only).
In addition to better performance for browsing server content, I defined a kind of timeout for the browse action. That means if you try to fetch a very big amount of data, you could reach the timeout and finally retrieved only a part of the data. I cannot test it (no enough data in my library) but I think the limit is now probably around 5000 items in the queue.
The timeout is set to 30s when UPnP event proxy is installed and used.
The timeout is set to 5s when UPnP event proxy is not used. The reason is that in this case I have to take care about the refresh data run every 15s. So the refresh cycle has to be fast. With this timeout, the limit is around 900 items in the queue.
Note that the timeout is not exactly 30s. It will be something between 30s and maybe 35s.
Enabling debug logs, you can see a trace each time the function is called with run time, number of fectched elements and size of the result string.
Best Home Automation shopping experience. Shop at Ezlo!
I had some problem with my app; it has to load all this data and on long playlists it started to run into network timeouts. The new version loads a lot quicker!