ring-mqtt: Bug: crash "loop" since updating to 5.1.0
Describe the Bug
Monitoring the log, I can see it keeps crashing every 20 seconds or so
Steps to Reproduce
Update to 5.1.0
Expected Behavior
Not crashing.
Log Output
Screenshots
Config File
root@xbmcdown:/mnt/user/appdata/ring-mqtt# cat config.json
{
"mqtt_url": "mqtt://192.168.1.200:1883",
"mqtt_options": "",
"livestream_user": "",
"livestream_pass": "",
"disarm_code": "",
"enable_cameras": true,
"enable_modes": false,
"enable_panic": false,
"hass_topic": "homeassistant/status",
"ring_topic": "ring",
"location_ids": [
""
]
}
Install Type
Docker via Unraid
Version
v5.1.0
Operating System
Unraid
Architecture
x86_64
Machine Details
12th Gen Intel® Core™ i7-12700 @ 2079 MHz
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 22 (10 by maintainers)
Most of that is because of WebRTC and go2rtc, not really anything I did. In the end the RTSP stream itself was always pretty fast at starting up, usually 2-3 seconds at most, but then HLS streaming in HA adds 3-5 seconds of buffering + whatever the interval between key frames (about 2 seconds for Ring cameras from what I can tell.
But I’m pretty happy with the current stream startup code, I don’t think I could reduce it much more. One of the big issues is that RTSP generally has to startup within 5 seconds or the client will time out the connection (this doesn’t include buffer time). With the old code I was seeing a number of cases from users where the stream startup time was taking 5-6 seconds, just longer than the 5 second timeout.
Now, at my home under near perfect conditions (wired camera connected to 1GbE fiber internet) the startup time is commonly 2 seconds and, a few weeks ago, I happened to be in Eastern Europe for a work trip and decided to test the live streams while I was there by running ring-mqtt on my laptop which was, using my 4G roaming phone connection as a hotspot, so ~160ms latency to Ring servers in the US, and only about 15Mpbs total where I was staying, yet the stream startup time was still consistently ~3.5-4 seconds and I never had a single stream fail to start due to missing the 5 second window.
go2rtc is baked in, and, but right now the baked in go2rtc is configured only as an on=demand rtsp servier, basically a drop in replacement for rtsp-simple-server which was used by prior version. In the future I might allow it to be configured for WebRTC so it could be used directly.
But indeed, without being an addon it does ramp up the complexity to configure it because you have to manually setup all the RTSP streams in go2rtc while the addon normally does this by gaining access to the HA /config directory which is an option for an HA addon. However, you can manually run go2rtc either on your HA host, or as a Docker container, it just requires more configuration.
The main reason I switch to go2rtc internally is it has some features that I hope to implement in a future version of ring-mqtt that I hope will make Ring cameras at least marginally useful with tools like Frigate, but that’s the future. For now, the goal was simply to replace rtsp-simple-server and make sure it was transparent.
Since this should be fixed and I’ve already pushed out v5.1.2 I’m going to go ahead and close this. Thanks for your help, especially for the thorough bug report and quick testing of fixes, it is greatly appreciated!
Thanks, if you could test the dev branch one more time please, that would be great. I’ve changed the code to attempt to detect the presence of a nightlight in the device data vs just relying on model. Hopefully I didn’t screw that up. If it works, I’ll push a 5.1.2 quickly so not too many people will get the broken builds. Fortunately, it would only impact the subset of people that have Chime Pro 1st generation, but as this addon has >5000 users now, that’s likely to still be a lot of people!
You can just downgrade to previous version, that’s by far the easiest thing to do. But I’ll have a fix in the dev branch in a few minutes now that I know the v1 Chime Pro didn’t have a nightlight. That’s the problem when you are trying to reverse engineer things but you don’t have access to every version of every device.
Ah, looking at the Ring documentation for the Chime Pro 1st generation it doesn’t appear to have a nighlight. I guess only the Chime Pro 2nd generation has a nightlight. So the code is currently trying to get a status for a nightlight that doesn’t exist.
Yep, that looks right. I’ve got everything staged to push 5.1.1 once you confirm the crash is gone. I can’t really test it because I don’t have a non-Pro version of the Chime, but the fix seemed obvious so hopefully that was it.
I believe this should be fixed in the dev branch if you don’t mind giving it a spin.