Describe the bug
Moonfire NVR logs confusing and incorrect things after a RTSP socket timeout, eg:
Apr 30 06:38:37 nuc moonfire-nvr[191256]: s-driveway-main moonfire_base::clock] getting next packet took PT10.128102479S!
Apr 30 06:38:47 nuc moonfire-nvr[191256]: s-driveway-main moonfire_ffmpeg::rtsp] 0x7fd5c406bd00: RTP: PT=60: bad cseq d186 expected=c4f3
Apr 30 06:38:47 nuc moonfire-nvr[191256]: s-driveway-main moonfire_base::clock] getting next packet took PT10.655021428S!
Apr 30 06:38:47 nuc moonfire-nvr[191256]: s-driveway-main moonfire_nvr::streamer] driveway-main: sleeping for Duration { secs: 1, nanos: 0 } after error: packet with no pts
Apr 30 06:38:48 nuc moonfire-nvr[191256]: s-driveway-main moonfire_nvr::streamer] driveway-main: Opening input: rtsp://admin:redacted@192.168.5.111/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
Apr 30 06:38:49 nuc moonfire-nvr[191256]: s-driveway-main moonfire_base::clock] opening rtsp://admin:redacted@192.168.5.111/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif took PT1.075105258S!
I got a packet capture at the same time this happened (by leaving sudo tcpdump -Uw %Y%m%d%H%M%S-driveway.pcap -s 0 -G 300 -i surveil 'host 192.168.5.111' running). Select packets I found in Wireshark (looking with filter tcp.dstport eq 54150 and rtp.channel eq 0)
at 06:38:37 it hit the socket timeout but returned something and kept going. That's strange!
at 06:38:47 it said bad cseq d186 expected=c4f3 but it actually did receive seq c4f3. It must have skipped them.
when it finally gave up, the message packet with no pts is strange. RTP packets always have a timestamp.
To Reproduce
Steps to reproduce the behavior:
Monitor a Dahua camera. Maybe overload it with smart codec, smart motion detection, lots of IVS rules, etc.
Wait a while.
Expected behavior
If the socket timeout (currently hardcoded to 10 seconds) is exceeded, Moonfire NVR should log a clear message to that effect and retry.
Server (please complete the following information):
If using Docker: docker ps + docker images
If building from git: git describe --dirty + moonfire-nvr --version
Build from git: v0.6.3-23-ga1e78ea. ffmpeg version:
Describe the bug Moonfire NVR logs confusing and incorrect things after a RTSP socket timeout, eg:
I got a packet capture at the same time this happened (by leaving
sudo tcpdump -Uw %Y%m%d%H%M%S-driveway.pcap -s 0 -G 300 -i surveil 'host 192.168.5.111'
running). Select packets I found in Wireshark (looking with filtertcp.dstport eq 54150 and rtp.channel eq 0
)Strange things here:
bad cseq d186 expected=c4f3
but it actually did receive seqc4f3
. It must have skipped them.packet with no pts
is strange. RTP packets always have a timestamp.To Reproduce Steps to reproduce the behavior:
Expected behavior If the socket timeout (currently hardcoded to 10 seconds) is exceeded, Moonfire NVR should log a clear message to that effect and retry.
Server (please complete the following information):
docker ps
+docker images
git describe --dirty
+moonfire-nvr --version
Build from git:
v0.6.3-23-ga1e78ea
. ffmpeg version:RUST_BACKTRACE=1
environment variable set if possible.Camera (please complete the following information):
V2.800.15OG004.0.T, Build Date: 2020-11-23
Desktop (please complete the following information): n/a
Smartphone (please complete the following information): n/a
Additional context Add any other context about the problem here.