search

QuantumEntangledAndy / neolink

An RTSP bridge to Reolink IP cameras
GNU Affero General Public License v3.0
246 stars 39 forks source link

Dailey 2 minutes in rtsp #209

Open Roei639 opened 5 months ago

Roei639 commented 5 months ago

Hello, After some time the broadcast time on rtsp is 2 minutes behind the reolink app

version: Neolink Release 0.6.3-rc.1 camera: reolink lumus

Thank you

lloydsmart commented 4 months ago

Same issue here. Using a Reolink E1 with the Docker version of the app.

It's a very long delay which makes matching up timestamps in Frigate almost impossible. How can we find the cause of this?

kyle170 commented 4 months ago

Chiming in, same issues, Large delay/latency (average 15-60 seconds) with using the (QuantumEntangledAndy/neolink:latest) docker image but when using the deprecated image (thirtythreeforty/neolink:latest) there is no delay....

Theres also a closed bug here (https://github.com/QuantumEntangledAndy/neolink/issues/132) but I dont think its actually resolved as I am still experiencing it even after adding buffer_size = 0 to my config

Dexdiman commented 4 months ago

I'm having the same issue with all of my E1's. Running the latest release in a docker and seeing the 1-2 min delay on the cameras. The doesn't appear to happen when running the exe on the Blue Iris server.

Edit: I was tired of the delay so I switched back to running the exe on Blue Iris but the 1-2 minute delay remains. I thought the delay didn't happen but I guess I missed it or didn't run it long enough. Either way, this fork and the original master are pretty much useless at this point.

Edit again: I downgraded the docker from 0.6.2 to 0.6.1 a couple days ago and the 1-2 minute delay is gone. It still feels like there is a delay beyond Blue Iris's delay but it's 10 ish seconds, so much more usable now.

JulesAU commented 2 months ago

Also saw 15-20s of latency until I downgraded to 0.6.1. Reolink Lumus v2.

QuantumEntangledAndy commented 2 months ago

I think I have this fixed now but need to finish testing it. The history buffer was growing infinitely if the camera was not sending correctly timestamped frames

Roei639 commented 1 month ago

I think I have this fixed now but need to finish testing it. The history buffer was growing infinitely if the camera was not sending correctly timestamped frames

Is the problem found?

QuantumEntangledAndy commented 1 month ago

Yeah should already been fixed in master.

DAM21 commented 1 month ago

I tried the current master and am still experiencing a long delay. It was over a minute and a half earlier today. Camera is a Lumus upgraded 2K. I downgraded to 0.6.1, as others mentioned, and I'm only seeing about 5 sec delay.

kyle170 commented 1 month ago

Chiming in also, current master has long delay, downgrading to v0.6.1 fixes issue. @QuantumEntangledAndy doesn't seem like this issue has been fixed.

gordnhoo commented 1 month ago

Having the same issue reverting to v0.6.1 also reduced the delay like @kyle170 Running a Lumus v2

QuantumEntangledAndy commented 1 month ago

I see well I'll have another look when I have the time but I am working on other projects and the day job for awhile.

cmcm711 commented 2 weeks ago

Appreciate all you do for this project! Wanted to chime in indicating I am also experiencing this issue with a Reolink Lumus camera. Using 0.6.3 starts out with a 20ish second delay, growing to multiple minutes after an hour or two. Using 0.6.1 fixes the issue, giving only a ~3 second delay (acceptable) that never grows.