v0.23.0 drops with Reolink RLC-520A

[blu006]

Which version are you using?

v0.23.0

Which operating system are you using?

• [x] Linux amd64 standard
• [ ] Linux amd64 Docker
• [ ] Linux arm64 standard
• [ ] Linux arm64 Docker
• [ ] Linux arm7 standard
• [ ] Linux arm7 Docker
• [ ] Linux arm6 standard
• [ ] Linux arm6 Docker
• [ ] Windows amd64 standard
• [ ] Windows amd64 Docker (WSL backend)
• [ ] macOS amd64 standard
• [ ] macOS amd64 Docker
• [ ] Other (please describe)

Describe the issue

v0.23.0 drops connection with the camera with the message [rtsp source] ERR: TCP timeout.

The previous version, v0.22.2 works as expected.

Describe how to replicate the issue

1. start the server
2. read the camera with RTSP

Did you attach the server logs?

no

Did you attach a network dump?

no

Future Server Log and Network Dumps

I can provide a side-by-side comparison complete with configuration files, logs, and network dumps in the near future

[blu006]

Screenshot of information from the camera in question

[Tokolosh]

exactly the same is happening with a hanwha techwin xnf-8010rv on rtsp

[0ip]

With v0.23.0, streaming from my RLC-520A (RTSP) via WebRTC/WHEP stops as well after about a minute. I'm receiving the same error message as @blu006. Another camera I own, a TP-Link Tapo C200, suffers the same fate, but occasionally there is an error message like ERR: EOF, or none at all.

[aler9]

Until now no one provided any useful data that allows to replicate the issue, and without that it's impossible to identify the bug.

Please provide a network dump of communication exclusively between the server and the camera and a server log with log level set to debug.

[Tokolosh]

This is a debug log i was able to do on a testing machine with a local network camera - IP and Ports obfuscated with IP:PORT. with v22.2 everything is working fine mediamtx-v23-error.txt

[aler9]

@Tokolosh there are no issues in the log you posted, with the exception of the warning "N RTP packets lost" that was added in v0.23.0 to warn about insufficient bandwidth but doesn't cause a stream to get dropped.

[Tokolosh]

@aler9 V22.2 works flawlessly and there are no bandwidth issues (during test only the test pc and a single ptz camera were on a seperate gigabit switch - camera feed is 16mbit) V23 always disconnects with the mentioned error (RTP packets lost) but V22.2 does not drop at all on the exact same setup. so something must have changed between versions

[aler9]

@Tokolosh my aim is to find the error exactly as you, i just wanted to say that the error "RTP packets lost" is not an error but is a warning message that doesn't cause a stream to be dropped. It was added to to detect insufficient bandwidth. Errors that cause the stream to be dropped are the mentioned ERR: TCP timeout or ERR: EOF

[aler9]

I checked the log of the underlying RTSP library (gortsplib) and the only major difference i could found between v0.23.0 and v0.22.2 is the one introduced with https://github.com/bluenviron/gortsplib/pull/265 . I reverted the change and compiled a nightly release, that is attached here. Please test it and let me know whether it solves the issue.

[link removed]

[blu006]

Thanks for the nightly build! I tried with the nightly build that @aler9 made, and it still has the same issue with the same ERR: TCP timeout. Weird.

Anyway, I know I still need to provide a debug log along with a wireshark dump.

[Tokolosh]

Thanks for the nightly build! I tried with the nightly build that @aler9 made, and it still has the same issue with the same ERR: TCP timeout. Weird.

Anyway, I know I still need to provide a debug log along with a wireshark dump.

i'm getting the same as well. However i am also checking up on my connecting clients (restreamer/vlc/etc) to see if the problem could be on that end. I'll be back once i have more details.

[Tokolosh]

V23.1 seems stable with VLC (tested for 1 hour with no drops) - latest datarhei restreamer however is having issues (still testing things though)

[mrgard]

Fault seems to be that keep-alive to IP-camera is not being sent (e.g. missing GET_PARAMETER sent to IP-camera), and then after timeout the IP-camera will close the connection.

Compared old and new code in client.go in gortsplib, seems to be a new calculation method for timeout. Reinserted old calc method, recompiled, then it works fine!

//New calc method in v0.23 - fails:
//c.keepalivePeriod = time.Duration(((*sx.Timeout)*10)/8) * time.Second

//Old method used earlier - works:
c.keepalivePeriod = time.Duration(float64(*sx.Timeout)*0.8) * time.Second

Thanx @aler9 for a very good toolkit, keep up the good work!

[aler9]

@mrgard thanks for debugging the issue, the point of that code was avoiding float64 computations after a user reported wrong results on ARM32 architectures, but I inverted numerator and denominator. I'll release a new version ASAP.

[aler9]

fixed in v0.23.2.

[0ip]

Thank you @mrgard and @aler9

[github-actions[bot]]

This issue is being locked automatically because it has been closed for more than 6 months. Please open a new issue in case you encounter a similar problem.