Windows > Third Party Plug-ins, Programs, and Skins
Home Assistant integration for jriver
hoyt:
--- Quote from: mattkhan on February 12, 2024, 05:02:59 pm ---The error just says the call to MCWS timed out, ie MC doesn't respond. The timeout is 5s which is a pretty long time so I guess it suggests either a network issue or a problem in MC. Anything in MC logs?
I could add some tolerance to this, like give it a few retries before falling or make the timeout longer though that may have other side effects.
--- End quote ---
Hmm, I'll do some more testing, but this morning, I used the core_ssh addon and did a wget loop to pull the MCWS/Alive. Then I watched the Media Player entity. At one point the media_player went to Not Available, but the wget loop was still getting responses back from MC within 0.1 s.
The only thing I see in the JRiver logs is potentially this, though that IP address is the IP of the client that was playing, not the MC or HA instance:
--- Code: ---0055644: 4152: General: CDLNADeviceServiceCaller::CallServiceFunction: DLNA function call failed or timeout! url = http://192.168.6.227:52101/AVTransport/control function = GetPositionInfo execution time = 6036.03 ms of 6000 ms.
--- End code ---
mattkhan:
FWIW HA uses https://docs.aiohttp.org/en/stable/ as the basis for http comms with an asyncio event loop underneath. I'm not familiar with the internals of exactly how asyncio is implemented but it does open up the possibility that contention with something else going on in HA causes the timeout (NB: given the size of the connection pool used in HA, this seems fairly unlikely tbh). It's also worth noting that I have to hit MC with multiple requests to gather all the info required (Alive, UserInterface/Info, Playback/Zones and 1 Playback/Info per zone) so it's also possible that this causes some contention somewhere (in HA or in MC is hard to tell). At least these are reasons why a single hit in a loop with a separate process each time is not exactly equivalent to how HA behaves though it might suggest the problem is in HA somewhere.
It's not obviously something I can influence at my end though given it's a timeout, not sure what else I can add to debug it either.
hoyt:
--- Quote from: mattkhan on February 13, 2024, 11:47:01 am ---
It's not obviously something I can influence at my end though given it's a timeout, not sure what else I can add to debug it either.
--- End quote ---
I think you were right before when you indicated that it's probably something not in the HA integration, but within MC/ my server. I just happened to be interacting with the client, or my interaction with the client made it happen. I went to change the volume on the client (MC, not the HA integration), the client hung for a second and I got the Mac pinwheel. At that moment, the integration went to not-available. I had just cleared the logs, so I'm looking through now to see if I can figure out what's going on. Appreciate the help!
mattkhan:
it would be interesting to know exactly how the webserver in MC operates and whether that operates in a non blocking mode, aka I have no clue how MC is threaded. For example, is MCWS serving the view of state available to the current thread or is it actively acquiring (via 1 or more locks) that state on demand?
eve:
I've seen JRiver (30 I believe) lock up because of HTTP requests sent to it. When I was having my client devices poll JRiver directly I'd every once in a while end up with an actual playback hiccup. I decided to log when every client polled, and sure enough, when a couple client's interval synced up *really* close, it had a chance of the 'hang' / interruption. Strangest thing. It convinced me to essentially make a single service for polling that the client devices could talk to.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version