go2rtc does not recover connection to camera unless I restart go2rtc #762
Comments
|
I have some update to provide. Preloading the stream indeed fixes the issue for me, however, there is a catch, you must not have any other source in the stream you are preloading. For example: streams:
rua_h265:
- rtsp://192.168.1.21/user=tema_password=admin_channel=0_stream=1&onvif=0.sdp?real_stream
- ffmpeg:rua_h265#audio=aacPreloading this stream makes no difference as to make the stream available or not. That's probably because go2rtc detects that there is already a stream working (the ffmpeg stream) and won't retry the first stream in case it breaks. This is why it had stopped working for me, because I had added such However, preloading this: streams:
rua_h265:
- rtsp://192.168.1.21/user=tema_password=admin_channel=0_stream=1&onvif=0.sdp?real_streamIndeed helps. The stream never breaks or is retried automatically without having to restart go2rtc itself. |
|
im also having trouble cant reconnect to camera if the camera is restarted. previously on my custom app with ffmpeg i stopped the ffmpeg process itself when no frame/data is received but in case of go2rtc it wont and keeps hanging forever. |
|
@felipecrs i am trying your automation script but i am having trouble in finding |
|
It's provided by the Frigate integration, you may need to enable it. But I have to say that I'm not longer using such automation. It didn't work as good as the other method I mentioned today. |
|
unfortunately i cant have stream preloading since i need the |
|
also my camera state never goes to |
|
Ops, I forgot to mention that I'm running Frigate 0.13 :P |
|
@felipecrs are you using the master branch of the hass integration? i am already on 0.13 beta |
|
No, I'm just using the latest beta integration. |
|
|
|
thanks @felipecrs the problem was i was using the master branch for the integration. swithced to dev branch adds the unavailable status for the camera. |
|
the problem with this approach is sometimes (like 50% of the time) frigate just hangs. i hope there will be an api to restart the go2rtc only. |
|
(?) My automation restarts go2rtc only. |
|
oh the port 1984 is only for gortc? i am using frigate docker |
|
@felipecrs are you sure about your go2rtc config? I can see in the go2rtc logs: I think it's your exec command for Dahua doorbell. |
|
I am pretty sure it is the correct config. This one is from my brother's house, and he does not have a Dahua doorbell. About the curl, I believe it came from the go2rtc_healthcheck from Frigate: It prints the logs to the same channel as go2rtc itself, that's why. |
|
Are you sure this is start of error? |
|
Actually no... However I see that the log repeats, you can see that Please let me know if you want me to capture full logs. |
|
This is info about all blocked routines. But we don't know the reason. |
|
Got it. I got full logs now. I opened a separate issue to talk about the panic because I am not sure it is directly related to this sympthom: |
I have a chinese ICSee/dvrip camera, which works great, including 2-way audio.
However, there is a problem: sometimes go2rtc loses the connection to it and it does not recover automatically, unless I manually restart go2rtc.
Camera is connected through Wi-Fi.
I am using go2rtc 1.8.3.
I have even built a Home Assistant automation to help me circumvent this problem:
My go2rtc config is:
And I see these errors in my go2rtc logs:
If I scroll up for a while, I can also see:
And if I scroll up a lot I can find this:
Click here to show
But this one even made go2rtc crash and get stuck, which caused the go2rtc watchdog from Frigate to restart it. I am not sure if it is directly related with the problem that I am reporting itself.
Another note is that, previously, preloading the stream in Home Assistant was apparently enough to solve this problem, but it no longer is. go2rtc loses the connection and does not recover even if Frigate is consuming the stream 100% of the time.
The text was updated successfully, but these errors were encountered: