Streams go offline at least once a day

[DennisGarvey]

I have two cameras that will just go offline, both have a strong connection and are connected on LAN mode. A restart fixes the issue but having to restart the container is a pain. The log is flooded with RTSP no one is publishing to path errors so its hard to find whats wrong.

[mrlt8]

Is it the same two that go down every time and does it happen after the same number of hours?

You can filter out the rtsp logs with - RTSP_LOGLEVEL=warn

It is strange that they come back after a restart.

[DennisGarvey]

The same two cameras go down each time, not sure about the time though.

[lucashend]

I actually have the same thing. The same 3 of my 8 Cams go offline quite often. One is a Wyze v2, and two are Wyzr v3's. Restarting the docker container seems to resolve... for a bit at least.

[mrlt8]

Could you see if all or any of these setting help:

- RTSP_PROTOCOLS=tcp
- RTSP_READTIMEOUT=30s
- RTSP_READBUFFERCOUNT=8192

[DennisGarvey]

I caught it in the act

wyze-bridge    | Traceback (most recent call last):
wyze-bridge    |   File "/usr/local/lib/python3.9/threading.py", line 973, in _bootstrap_inner
wyze-bridge    |     self.run()
wyze-bridge    |   File "/usr/local/lib/python3.9/site-packages/wyzecam/tutk/tutk_ioctl_mux.py", line 300, in run
wyze-bridge    |     raise tutk.TutkError(actual_len)
wyze-bridge    | wyzecam.tutk.tutk.TutkError: AV_ER_REMOTE_TIMEOUT_DISCONNECT
wyze-bridge    | 2021/08/08 02:58:01 I [2/2] [RTSP] [conn 192.168.1.3:51906] opened
wyze-bridge    | 2021/08/08 02:58:01 I [2/2] [RTSP] [conn 192.168.1.3:51906] ERR: no one is publishing to path 'cam'
wyze-bridge    | 2021/08/08 02:58:01 I [2/2] [RTSP] [conn 192.168.1.3:51906] closed
wyze-bridge    | 2021/08/08 02:58:31 I [2/2] [RTSP] [conn 192.168.1.3:51908] opened
wyze-bridge    | 2021/08/08 02:58:31 I [2/2] [RTSP] [conn 192.168.1.3:51908] ERR: no one is publishing to path 'cam'
wyze-bridge    | 2021/08/08 02:58:31 I [2/2] [RTSP] [conn 192.168.1.3:51908] closed
wyze-bridge    | 2021/08/08 02:59:01 I [2/2] [RTSP] [conn 192.168.1.3:51916] opened
wyze-bridge    | 2021/08/08 02:59:01 I [2/2] [RTSP] [conn 192.168.1.3:51916] ERR: no one is publishing to path 'cam'
wyze-bridge    | 2021/08/08 02:59:01 I [2/2] [RTSP] [conn 192.168.1.3:51916] closed```

[mrlt8]

We might be able to bump up the timeout, but I wonder if it's some other network related issue causing the camera to lose connection and timeout..?

AV_ER_REMOTE_TIMEOUT_DISCONNECT -20016:

This IOTC session is disconnected because remote site has no any response after a specified timeout expires.

[DennisGarvey]

I added the extra flags and it seems to be running fine so far.

[SunnyM-ha]

I used to have the same/similar issue (never managed to catch the actual error - log file scrolled way past it by the time I checked) with having to restart the docker images 2-3 times a day as I'd get the ERR: no one is publishing to path

Added the 3 RTSP flags above and confirmed its been running for well over a day now - -thanks!

P.S. I still get disconnects but it automatically reconnects, so its stable :)
2021/08/11 10:35:24 I [2/2] [RTSP] [conn [::1]:44934] closed
2021/08/11 10:35:24 I [2/1] [RTSP] [session 111024709] closed
2021/08/11 10:35:24 I [2/1] [RTSP] [conn [::1]:48238] opened
2021/08/11 10:35:24 I [2/1] [RTSP] [session 651665672] opened by [::1]:48238
2021/08/11 10:35:24 I [2/2] [RTSP] [session 651665672] is reading from path 'front', 1 track with TCP

[SunnyM-ha]

Just wanted to leave an update here - with the newest version (defaults the protocol to TCP) I've been able to remove the 3 RTSP flags and the docker image with out of the box settings works fine now, been connected for well over a day.
Before it used to say:
I [1/0] [RTSP] [session 574691071] is publishing to path 'driveway', 1 track with UDP
I [1/1] [RTSP] [session 946935589] is reading from path 'driveway', 1 track with TCP
I [2/1] [RTSP] [session 327122938] is publishing to path 'front', 1 track with UDP
I [2/2] [RTSP] [session 813929439] is reading from path 'front', 1 track with TCP

and now it says :
I [1/0] [RTSP] [session 574691071] is publishing to path 'driveway', 1 track with TCP
I [1/1] [RTSP] [session 946935589] is reading from path 'driveway', 1 track with TCP
I [2/1] [RTSP] [session 327122938] is publishing to path 'front', 1 track with TCP
I [2/2] [RTSP] [session 813929439] is reading from path 'front', 1 track with TCP
and is stable.

[SunnyM-ha]

It still disconnects sometimes, but reconnects automatically:

2021/08/18 20:49:17 I [1/1] [RTSP] [conn [::1]:53670] ERR: no one is publishing to path 'driveway'
2021/08/18 20:49:17 I [1/1] [RTSP] [conn [::1]:53670] closed
2021/08/18 20:49:17 I [1/1] [RTSP] [conn [::1]:53672] opened
2021/08/18 20:49:17 I [1/1] [RTSP] [conn [::1]:53672] ERR: no one is publishing to path 'driveway'
2021/08/18 20:49:17 I [1/1] [RTSP] [conn [::1]:53672] closed
2021/08/18 20:49:17 I [1/1] [RTSP] [conn [::1]:53674] opened
2021/08/18 20:49:17 I [1/1] [RTSP] [conn [::1]:53674] ERR: no one is publishing to path 'driveway'
2021/08/18 20:49:17 I [1/1] [RTSP] [conn [::1]:53674] closed
2021/08/18 20:49:17 I [1/1] [RTSP] [conn [::1]:53676] opened
2021/08/18 20:49:17 I [1/1] [RTSP] [conn [::1]:53676] ERR: no one is publishing to path 'driveway'
2021/08/18 20:49:17 I [1/1] [RTSP] [conn [::1]:53676] closed
2021/08/18 20:49:19 [Driveway] Closing FFMPEG...
2021/08/18 20:49:19 [Driveway] [FFMPEG] FFMPEG closed
2021/08/18 20:49:21 [Driveway] Starting 1080p 120kb/s Stream for WyzeCam V3 (WYZE_CAKP2JFUS) in "LAN mode" FW: 4.36.2.5 IP: 10.0.0.32 WiFi: 54%
2021/08/18 20:49:25 I [1/1] [RTSP] [conn 127.0.0.1:56012] opened
2021/08/18 20:49:25 I [1/1] [RTSP] [session 547728474] opened by 127.0.0.1:56012
2021/08/18 20:49:25 I [2/1] [RTSP] [session 547728474] is publishing to path 'driveway', 1 track with TCP
2021/08/18 20:49:27 I [2/1] [RTSP] [conn [::1]:53726] opened
2021/08/18 20:49:27 I [2/1] [RTSP] [session 641988176] opened by [::1]:53726
2021/08/18 20:49:27 I [2/2] [RTSP] [session 641988176] is reading from path 'driveway', 1 track with TCP

[mrlt8]

Potential fix for streams that refuse to come back online in v0.6.2.

Please let me know if this fixes the issue.