unifi-cam-proxy
unifi-cam-proxy copied to clipboard
keshavdv
Frigate detection playback time out of sync
Camera
Frigate
Firmware version of the camera
No response
Description
RTSP camera feed configured with Frigate.
Detections are working within Protect and displaying the correct thumbnails against date & time within the portal.
However, when clicking on a thumbnail the playback clip doesn't start at the time that the detection was made.
See in this picture, timestamp on Unifi detection is 17:39:37 (also the correct time on actual the video feed). However, when viewing the clip it starts at 17:15:01 (~25 mins too early).
When viewing the camera feed within Protect Playback feature, live time on camera feed matches the Timeline bar within the right panel. However, if you scrub back in time from live, it jumps ~25 mins into the past.
Will leave running for a while and see if times get further out of sync.
How to reproduce
No response
Expected behaviour
No response
Screenshots
No response
Aditional information
No response
Hi, same issue here. I have tried to change timezones on console or host where my proxy runs. But it is still same. Sometimes after rebooting devices it is difference 5minutes, sometimes it is 1hour. Never has exact time. I have tried to set another ntp server on both devices, but it is without any change.
I'm also having a similar issue with the detection times. I'm sitting around 15 minutes or so out of sync. If I go into the timeline view for a camera, it's showing the timeline as in the future but the camera time on the image is the correct time.
I'm seeing the same thing. I have three Amcrest cameras, all fed through Frigate but using direct RTSP connections for the feeds. I tried looking at the .flv output but couldn't find any timestamp packets (in the few seconds I collected). Should I be able to see them in a dump of the file? (basically, I ran the ffmpeg process through "python -m unifi.clock_sync --write-timestamps" and copied the result off the container.)
I do see three copies of the stream process running inside the container -- is that normal? (ffmpeg | clock sync | nc -- three of those pipelines, all seem to be identical.)
Having the same problem since running everything through frigate. the stills are correct but the timeline / jump to timeline is off. Can somehow both direct RTSP and frigate be enabled?
Upgraded to latest Unifi protect and still have this issue. Is this out of sync unique to Frigate? wonder if the latest update of go2rtp is part of the problem.
Hi, i had same issue before restream over frigate. It was same with direct rtsp stream from camera.
Hi, i had same issue before restream over frigate. It was same with direct rtsp stream from camera.
I setup restreams on all my rtsp cameras in frigate, then referenced these in the unifi-cam-proxy arguments - but hasn't made any difference to the time sync issue. @wladkolc did you make any other changes?
Hi i have tried some changes but i dont noted them. Now i have this configuration:
unifi-cam-proxy -H nvrIP -i camIP --mac 'camMAC' -c /client.pem -t token --model "UVC G3 Pro" frigate -s 'rtsp://frigateIP:8554/garden' --frigate-camera garden --mqtt-host mqttIP --mqtt-port 1883 --mqtt-prefix frigate --ffmpeg-args='-c:a copy -c:v copy' i have tried some tick configurations, but without any success. I don't think it will ever work as genuine cams.
Hi i have tried some changes but i dont noted them. Now i have this configuration:
unifi-cam-proxy -H nvrIP -i camIP --mac 'camMAC' -c /client.pem -t token --model "UVC G3 Pro" frigate -s 'rtsp://frigateIP:8554/garden' --frigate-camera garden --mqtt-host mqttIP --mqtt-port 1883 --mqtt-prefix frigate --ffmpeg-args='-c:a copy -c:v copy'i have tried some tick configurations, but without any success. I don't think it will ever work as genuine cams.
My setup looks similar, have also tried the following --ffmpeg-args as per other issue discussion:
--ffmpeg-args='-c:v copy -an -ss 0:01'
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
anyone have any feedback on this? really limits the usefulness of this project.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Same issue here, complete restream over frigate ... it seams, that stream is to slow ... around 1 second per minute
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I plan on using frigate too, and might encouter the same issue. Did someone try changing the frame rates? Maybe it's related to that if it adds up 1 second every minute (Could also be a frigate bug?)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I corrected the FPS and such and it worked when I restarted the container, but it appears to go out of sync... I'm wondering if the clock_sync script is the issue. Unfortunately I don't exactly understand how it works. It's a shame this is essentially abandoned without much help.
I corrected the FPS and such and it worked when I restarted the container, but it appears to go out of sync... I'm wondering if the clock_sync script is the issue. Unfortunately I don't exactly understand how it works. It's a shame this is essentially abandoned without much help.
How did you correct he FPS?
I corrected the FPS and such and it worked when I restarted the container, but it appears to go out of sync... I'm wondering if the clock_sync script is the issue. Unfortunately I don't exactly understand how it works. It's a shame this is essentially abandoned without much help.
How did you correct he FPS?
The G3 Bullet's FPS is 30, so I set the Camera to 30fps output, the stream is 30 fps. I hoped that if they all matched they would work, but they seem to be out of sync. I suspect it's an issue with the clock_sync script playing up, but I have no evidence for that (or the skills to debug that script).
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
commenting to keep this open- same issue as others, the "clock" creep makes protect think it's 1 hour on the future after around 8 hours of recording. on the DEV image (to get past the clock_sync pipe exception) testing 3 different models of reolink cameras via rtsp but I'll try others now that this is consistent. notable that they are all the same exact amount ahead after my 8 hour test.
I'll adjust some of the values in clock_sync and report back.
For those still running into this problem, have a look at #366. There I proposed to change some factor that was used on timestamps reported to unifi protect console. For testing use the image gwndaan/unifi-cam-proxy:timestamp-modifier. If needed, the factor can be changed with the --timestamp-modifier <insert number here> command parameter, default is 90 (before it was set to 100). Let me know how it goes :)
