OK, interesting. This is one that when you look at it the problem goes away!
I turned it on and off from the device screen, and the amp also turned on and off. Now it works with the remote. not sure what magic you have, but it has worked for now.
Thank you for your support and suggestion. hopefully thats sorted !?!?
Weird. Some people have suggested that the polling method I'm using for the Squeezebox can lead to hub slowdowns which is why I made the refresh period configurable. If you see similar behaviour again try increasing the interval between Squeezebox refresh calls. Hope it works for you!
Ah, failed again! When I turned on the SB it had a funny playlist with ....temp... in it. I navigated to a proper playlist, and then it worked again. seems fine again, I will see what happens in the morning and make a proper note of it. I have seen it before, but only recently.
Slowdown is real, and best I can tell it is related to this code. I've had to disable the app/drivers entirely because it chowders the hub. Initially I edited the code and set the polling period to like 5000sec and that slowed down the rate of dementia advancement but it still made the hub totally unresponsive after a few days.
Might want to try disabling the sqeeze app/devices and see if the amp will behave more reliable directly from hubitat.
I'm considering noodling around the code when I have time and adding a 'disable polling' option for myself. A full integrated music player interface within hubitat updating song info etc isn't what I need anyway, just play, pause, on/off. everything else I suit up and dive into a squeeze specific app.
Are you running the latest version of the code? I ask because I have already added a "Disabled" option in the drop down for "Player Status Refresh Interval". Try that one.
It's strange that you are having that reaction from the app. I'm using it with a setup with 5 players and don't see any hub slowdown from it.
@bikesquid Do you ever see the following message in your logs?:
"Overlapping getServerStatus() requests, check network connectivity between HE Hub and LMS Server or consider increasing refresh interval."
Hi @bikesquid @rupert.bowling1
I have spent a bit of time investigating this (benefit of home isolation I guess). Ideally I'd like to switch the status updating to use the LMS cometd interface (where the server pushes updates over a websocket). That's a bit of a major rewrite though so for now I've switched the player command requests to use the async HTTP method (instead of synchronous) and stopped the app from sending more refresh requests when it's still waiting for a response for a previous one.
It's working for me... but that doesn't guarantee its going to work better for you guys. If you have time to test/play with it and let me know if it looks better that'd be helpful 
Cheers
@xap - not running the latest as I already made some edits to the code to suit myself....
A suggestion - as there aren't any notices when code is updated that I'm aware of other than the associated thread, a suggestion - maybe post update info as a headsup for those subscribed to the thread?
Maybe I'll have time to give it a go with your new code, busy, busy at the moment.
As I have it disabled, nothing in the logs at present, but yes, I think I was seeing that before I disabled the app/devs.
I have paired back my install to 10 players presently... I was using 15 before I started a massive home remodel that has put a few in the TBD pile of tech...so double your environment now and triple at the best/worst of times. Might have something to do with it! 
If had more time I'd work my own version of the code to suit my specific needs, but as I'm drowning in work at the moment I'll throw out my thoughts, no worries if it's not in your plan, understand fully. -
- I'd rather be able to set polling on a per player basis rather than for ALL players. I use one player as the 'master' and rest are sync'd to that, so only use vol and power for those others. if volume is relative, I don't need polling to adjust volume, just to tell me what it's at, I can live without that.
If power is absolute rather than a toggle, and can force send regardless of the state HE thinks it's in, then I'm golden... I can use buttons to up/dn volume, button to push a on command, or another button for an off command.... no polling involved, and HE can guess the state from what I do in HE, if I'm dilligent about where I make changes from should be close enough (not a programmer term, I know!)
Just posted something, then your post came through @xap, I'll give the newest version a go if it'll help, but it'll take a few days for me to work it into 'life'... cheers.
1 Like
Home Isolation! Yes. I am way behind you guys as to understanding what is going on here.
I have uploaded the new code, and will watch it closely. I had thought that I had found the cause. The Temp playlist meant that it did not play, therefore it did not turn on the amp switch. Turns out it now turns on the amp even when it throws uo a temp play list.
For the record the playlist is 
tempplaylist_ (0004202384d5
It was on a main playlist when I last looked. Could it have rebooted ? and lost its place?
I will see if it happens with the new code still.
xap... awesome work!
@bikesquid @rupert.bowling1 One thing to bear in mind, if debug logging is enabled in the Connect app it will produce a lot of debug messaging. This will definitely have an impact on the hub. So only switch this on when you are trying to debug a specific problem (other than slowdown, I know, pita).
I have pushed another update to Github. This one is specifically for you @bikesquid 
There is a new preference on each player that allows you to exclude it from the server polling.
The players already automatically updated their state following the issue of a command, sometimes a race condition would mean the update didn't reflect the result of the command. I have added a 500ms delay between issuing the command and refreshing the player state which is looking much happier.
Let me know if there any issues with this... I think it's in a better place now.
1 Like
Thx @xap for that effort! I've updated using the code, restarted HE and we'll see.... I've left all players polling, cause if it's more gooder, then it's more gooder and won't be a problem (that's faith talkin'). I'll post back in a few days.
cheers.
1 Like
I have pushed a small update to the server polling and busy status handling so that the app doesn't wait forever in the case of a lost response to a status refresh request.
2 Likes
@xap - still experiencing heavy slowdown of HE... the only errors/warning in logs is this:
app:212020-05-26 01:04:03.002 am warnSkipping request to refresh server status as still waiting on previous request. Hub network IO could be busy. If this occurs often then check network connectivity between HE Hub and LMS Server or consider increasing player refresh interval.
That's disappointing. I'm not seeing any slow down, although I only have five players so not as many as you. Have you tried switching off polling for the players you don't need it for?
How soon do you see the slowdown happening after hub reboot?
BTW, I see the same skipping request message around 2am here. I think it's when the hub is doing self-maintenance and possibly tying up resources. It's always around the same time.
The app should reset its busy flag after ten failed attempts - if it then stops logging the message that indicates that what has actually happened is that the first request never received a response. Again, my guess is that is due to the hub maintenance process.
Well, here's the fun part... I've got all the devices 'disabled' in the device list. So by my reckoning they shouldn't be doin' jack. Each squeeze device was created, left alone as far as switching off polling, but disabled on the device page. So I don't understand the error. The error doesn't just happen around maintenance times, it's anywhere from 5pm to 7am in the two days of logs I've got.
I'm also seeing 'Received error response [408] : Connect to 192.168.xx.xx:9000 [/192.168.xx.xx] failed: connect timed out.' Total mystery, that one.
I've now disabled the app too till I understand the problem better, but given all the devices were disabled seems like maybe the app is the issue? As for how long it takes, I notice a slowly progressing slowdown for a day or two... maybe three before inputs take 5-15seconds to happen. That's usually when I loose my mind and power cycle the unit.
With both the app and devices disabled I'll reboot and see if the problem is maybe not connected at all to squeeze.... unless you can think of something I can do to help narrow it down?
By "disabled on the device page" do you mean you've set "Exclude from server polling" to true on each player device page?
The "...failed: connect timed out" message indicates that the HE hub got no response at all from the squeezebox server. Is the server going to sleep maybe? How often/when do you see that.
Also, what is the refresh interval you have set for the players?
I'll tackle the first question...
On the devices page check the "X" @ the upper right arrow. That shows the 'Disable' column... check dem der tings that you want disabled and, as I understand it, they ain't gonna be involved in nothin no mo.
server doesn't go to sleep and I don't see many of that error in any case, so maybe a fluke. The last question I think answered with 'disabled' above, no?
That's really interesting. I didn't know about that disable function. The way that the app polls is to query the server for the list of players. For each one that is powered on and not excluded from the poll (via the device preference on each player) it asks the server for full details for that player. It looks up the device and then passes that detail to the player device code. I suspect that disabling the player device via the devices page won't stop that process. With the current version of my code I think you need to exclude the players via their preference setting. However, I'll have a look and see if I can detect if a device is disabled and if it is then I'll treat it as excluded from the polling. Watch this space for an update...
