Repository navigation
Getting timeouts in Live view #457
Description
Activity
Did some more testing.
I went back version by version to 0.32.0 and the problem finally disappared, but motion detection recording didn't work.
So, went back to latest. Even in 0.36.3 the timeouts occur.- added a commit that references this issue
on Jul 24, 2026 @jcasarini worth testing again the latest release -- connection timeouts are now runtime configurable.
Hey @matteius, I tried it as soon as it came out—same problem.
Pretty weird, actually. I restarted the container a few times and it stabilized itself on 0.36.3, but when I upgraded it to 0.36.4, the problem came back.
First I thought that the problem was a that the motion detection was being done with the main feed, as the problem had solved once I set it up to run on the substream, but no.Another weird problem I ran into was when I set up the substream for live view (I had already done that for motion detection). It worked for a while and then stopped working altogether, giving Error 500. I removed the substream config and it worked again.
The strangest thing is that all these problems appear after a while, not right away when I set up a new instance.
I decided to migrate it from the LXC to a full-fledged VM (always running Docker on top of them), thinking maybe that was the problem... The substream problem persists, but the WebRTC errors have subsided.
Maybe there's some kind of problem with the camera feeds—they are both wired cameras, and I pinged them for days with no lost packets.
Maybe there could be some kind of heartbeat or log in the Streams Health tab showing the state of all set-up streams: main, sub, and motion detection stream. Something like the "Connection Quality" bullet in the Live View Stream Labels.
I know all the setup URLs work; I've tried them in VLC and they do.
It's pretty stable now, but I'm worried about any reboots hahaha.
Thanks for all your work, its a great project, I've worked with NVRs (both free and paid options) for years, this is top notch.
Got some logs here, not sure but seems like go2rtc might be the problem:
@jcasarini ah that could be ... we do run the latest dev go2rtc branch changes, which I had synced around the time you reported this -- I see there are two more commits there, there is an rtsp fix but not sure if it will help -- i just synced that up to main branch.
Good, I'll pull the latest image once it gets published and let you know.
0.36.5 is building now. It includes the go2rtc dev sync with the RTSP fix I mentioned, on top of the runtime-configurable timeouts from 0.36.4.
One other change in this release may be relevant to you. When a WebRTC connection is up but no frames arrive, a tile now falls back to the camera's sub-stream instead of reconnecting to the main stream indefinitely. That came from #468 (fullscreen over a reverse proxy), but the underlying shape — ICE connected, high loss, no video, retries forever — matches the "works for a while, then stops" behaviour you're seeing, and your substream-then-Error-500 experiments point the same way.
On your Stream Health suggestion: showing main / sub / detection feeds separately with their connection state, like the Connection Quality indicator in Live View, is on the roadmap and your request is noted against it. That is exactly the visibility gap you hit — you shouldn't have had to bisect versions to find this.
If it still misbehaves on 0.36.5, please do attach fresh logs. The last set pointed straight at go2rtc and is what got the fix synced.
Tried the new version, got the errors.
Here are fresh logs, in them I got a few WebRTC connection errors and also logged while I tried to setup the substream in the Stream's config and the live view stopped working altogether (Error 500).Hi @matteius, I think this was solved in 0.36.7. It's been running smoothly since the upgrade.
Problably fixed by this:
- Resolved a feedback loop on multi-view dashboards where multiple live view cells would repeatedly trigger shared go2rtc source restarts, causing all viewers to be disrupted simultaneously; retry now only reconnects the local browser player without restarting the shared stream source
Thanks for all your work!
Joaquín
Hello, I'm running Lightnvr (latest version) in docker. A very small setup, only 2 cameras and 8 users.
I even enabled Demo mode so users can use the platform without the need to login.
I'm getting constant errors in the Live View:
WebRTC connection lost. Please retry.
Connection timeout. Check network/firewall settings.
CPU, and memory usage are very low, so doesn't seem to be a resources issue.
I read the troubleshooting guide: https://github.com/opensensor/lightNVR/blob/main/docs/TROUBLESHOOTING.md#live-stream-video-timeouts
But can't find those files inside de docker container, do I have to rebuild ir from source? Is there anyway to change those values using the stock latest image?
Thanks!
Joaquín