Frigate detection playback time out of sync

[daltskin]

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

[wladkolc]

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.

[fullhack2]

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.

[dschuetz]

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.)

[cefoster0]

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?

[cefoster0]

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.

[wladkolc]

Hi, i had same issue before restream over frigate. It was same with direct rtsp stream from camera.

[daltskin]

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?

[wladkolc]

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.

[daltskin]

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'

[stale[bot]]

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.

[cefoster0]

anyone have any feedback on this? really limits the usefulness of this project.

[stale[bot]]

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.

[zerodayyy]

anyone?

[portboy]

Same issue here, complete restream over frigate ... it seams, that stream is to slow ... around 1 second per minute

[stale[bot]]

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.

[zerodayyy]

up

[bluelu]

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?)

[stale[bot]]

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.

[cefoster0]

any movement on this project? has a lot of potential.

[joshwillcock]

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.

[cefoster0]

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?

[joshwillcock]

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).

[stale[bot]]

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.

[Nayruden]

This is still an active issue

[mihalich1988]

I'm also having a similar issue. RTSP transport without frigate.

[stale[bot]]

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.

[ezeek]

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.

[GwnDaan]

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 :)

[cefoster0]

great job @GwnDaan ! I'll try and test this over the weekend.

[Nayruden]

I pulled your changes in to my homelab, @GwnDaan . Fingers crossed!

[tehacx]

@GwnDaan I'm getting the following error when using your image

We renamed asyncio-mqtt to aiomqtt and released a version 1.0.0 in the process. This is the last release under the asyncio-mqtt name. You can find the new repository at https://github.com/sbtinstruments/aiomqtt
2024-04-06 15:53:55 6e438a56c44e FrigateCam[1] INFO Spawning stream for snapshots: ffmpeg -nostdin -y -re -rtsp_transport tcp -i "rtsp://frigate:***@frigate:8554/kuche_test" -r 1 -update 1 /tmp/tmp0s2z665a/screen.jpg
2024-04-06 15:53:55 6e438a56c44e Core[1] INFO Creating ws connection to wss://192.168.30.1:7442/camera/1.0/ws?token=***
2024-04-06 15:53:55 6e438a56c44e FrigateCam[1] INFO Adopting with token [***] and mac [AA:BB:CC:00:11:22]
Exception ignored in: <function Client.__del__ at 0x7f55c1ef0940>
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/paho/mqtt/client.py", line 874, in __del__
    self._reset_sockets()
  File "/usr/local/lib/python3.9/site-packages/paho/mqtt/client.py", line 1133, in _reset_sockets
    self._sock_close()
  File "/usr/local/lib/python3.9/site-packages/paho/mqtt/client.py", line 1119, in _sock_close
    if not self._sock:
AttributeError: 'Client' object has no attribute '_sock'
2024-04-06 15:53:55 6e438a56c44e FrigateCam[1] INFO Cleaning up instance
Traceback (most recent call last):
  File "/usr/local/bin/unifi-cam-proxy", line 8, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.9/site-packages/unifi/main.py", line 172, in main
    loop.run_until_complete(run())
  File "/usr/local/lib/python3.9/asyncio/base_events.py", line 647, in run_until_complete
    return future.result()
  File "/usr/local/lib/python3.9/site-packages/unifi/main.py", line 167, in run
    await c.run()
  File "/usr/local/lib/python3.9/site-packages/unifi/core.py", line 81, in run
    await connect()
  File "/usr/local/lib/python3.9/site-packages/backoff/_async.py", line 76, in retry
    ret = await target(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/unifi/core.py", line 72, in connect
    await asyncio.gather(*tasks)
  File "/usr/local/lib/python3.9/site-packages/unifi/cams/frigate.py", line 88, in run
    await mqtt_connect()
  File "/usr/local/lib/python3.9/site-packages/backoff/_async.py", line 76, in retry
    ret = await target(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/unifi/cams/frigate.py", line 68, in mqtt_connect
    async with Client(
  File "/usr/local/lib/python3.9/site-packages/asyncio_mqtt/client.py", line 298, in __init__
    self._client: mqtt.Client = mqtt.Client(
TypeError: __init__() missing 1 required positional argument: 'callback_api_version'

[GwnDaan]

@tehacx, ahh nice, since the requirements file didn't include fixed versions of the packages used, the image broke because it pulled new versions. I didn't touch the part that caused the error hahah. Nevertheless I made some changes to combat that issue and pushed it again under the same tag :) Try pulling it again and see if that fixes it

[cefoster0]

For those following along at home with their own build, easiest way to fix the mqtt errors is to lock the asyncio-mqtt in requirements.txt to the older 1.16.1 version.

Once I did that, I was able to cleanly build and use the code in my own copy. I had an earlier comment in this thread but I realized I wasn't building my docker correctly from source. Once you make that update to requirement.txt, this change does seem to fix the timing issues with my Waze cameras. Amazing job @GwnDaan !

[tehacx]

@GwnDaan Thanks for looking into it! After repulling the image, I'm getting this error now

Traceback (most recent call last):
  File "/usr/local/bin/unifi-cam-proxy", line 8, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.9/site-packages/unifi/main.py", line 172, in main
    loop.run_until_complete(run())
  File "/usr/local/lib/python3.9/asyncio/base_events.py", line 647, in run_until_complete
    return future.result()
  File "/usr/local/lib/python3.9/site-packages/unifi/main.py", line 167, in run
    await c.run()
  File "/usr/local/lib/python3.9/site-packages/unifi/core.py", line 81, in run
    await connect()
  File "/usr/local/lib/python3.9/site-packages/backoff/_async.py", line 76, in retry
    ret = await target(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/unifi/core.py", line 72, in connect
    await asyncio.gather(*tasks)
  File "/usr/local/lib/python3.9/site-packages/unifi/cams/frigate.py", line 88, in run
    await mqtt_connect()
  File "/usr/local/lib/python3.9/site-packages/backoff/_async.py", line 76, in retry
    ret = await target(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/unifi/cams/frigate.py", line 83, in mqtt_connect
    await asyncio.gather(*tasks)
  File "/usr/local/lib/python3.9/site-packages/unifi/cams/frigate.py", line 91, in handle_detection_events
    async with client.filtered_messages(
AttributeError: 'Client' object has no attribute 'filtered_messages'

[GwnDaan]

@tehacx I applied the patch suggested by @cefoster0:

easiest way to fix the mqtt errors is to lock the asyncio-mqtt in requirements.txt to the older 1.16.1 version.

it should work if you pull the tag gwndaan/unifi-cam-proxy:timestamp-modifier again now

[tehacx]

@GwnDaan With the newest image version I'm back at the previous error:

Exception ignored in: <function Client.__del__ at 0x7f1a9d0ad8b0>
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/paho/mqtt/client.py", line 874, in __del__
    self._reset_sockets()
  File "/usr/local/lib/python3.9/site-packages/paho/mqtt/client.py", line 1133, in _reset_sockets
    self._sock_close()
  File "/usr/local/lib/python3.9/site-packages/paho/mqtt/client.py", line 1119, in _sock_close
    if not self._sock:
AttributeError: 'Client' object has no attribute '_sock'
2024-04-07 22:14:11 49a427c181eb FrigateCam[1] INFO Cleaning up instance
Traceback (most recent call last):
  File "/usr/local/bin/unifi-cam-proxy", line 8, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.9/site-packages/unifi/main.py", line 172, in main
    loop.run_until_complete(run())
  File "/usr/local/lib/python3.9/asyncio/base_events.py", line 647, in run_until_complete
    return future.result()
  File "/usr/local/lib/python3.9/site-packages/unifi/main.py", line 167, in run
    await c.run()
  File "/usr/local/lib/python3.9/site-packages/unifi/core.py", line 81, in run
    await connect()
  File "/usr/local/lib/python3.9/site-packages/backoff/_async.py", line 76, in retry
    ret = await target(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/unifi/core.py", line 72, in connect
    await asyncio.gather(*tasks)
  File "/usr/local/lib/python3.9/site-packages/unifi/cams/frigate.py", line 88, in run
    await mqtt_connect()
  File "/usr/local/lib/python3.9/site-packages/backoff/_async.py", line 76, in retry
    ret = await target(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/unifi/cams/frigate.py", line 68, in mqtt_connect
    async with Client(
  File "/usr/local/lib/python3.9/site-packages/asyncio_mqtt/client.py", line 292, in __init__
    self._client: mqtt.Client = mqtt.Client(
TypeError: __init__() missing 1 required positional argument: 'callback_api_version'

[GwnDaan]

Hmm it seems to be further down than only asyncio-mqtt. The callback_api_version is from paho-mqtt. @tehacx, any chance you have that also locked to a particular version in your build?

[tehacx]

@GwnDaan Nope, haven't changed anything, pulled your image gwndaan/unifi-cam-proxy:timestamp-modifier and run it as is. If I find some time I'll give it a try to build it myself

[GwnDaan]

Oops I meant @cefoster0

any chance you have paho-mqtt also locked to a particular version in your build?

[cefoster0]

Oops I meant @cefoster0

any chance you have paho-mqtt also locked to a particular version in your build?

I did not have paho-mqtt locked in my build. However, the snapshots being saved to Protect was inconsistent. I've since replaced my requirements with yours and now it's getting the same error as @tehacx . let me see If I can recreate my requirements.txt.

[cefoster0]

this works, no idea why. I'll monitor the snapshots in protect to see if they are better.

paho-mqtt<=1.6.1 asyncio-mqtt<=0.16.1

[GwnDaan]

I'll monitor the snapshots in protect to see if they are better.

Not sure what the exact issue is you're facing, for me scrolling through the timeline and playing back the camera's in the protect app can sometimes be a little quirky. Though that solves itself most of the times after a restart or two of the app, but it only happens on camera's that use the proxy of this project. So I think there's still something not quite right somewhere indeed, but it's something I can live with because in the end it's functional enough for me.

paho-mqtt<=1.6.1 asyncio-mqtt<=0.16.1

I've implemented these changes in my latest build and pushed it to the tag gwndaan/unifi-cam-proxy:timestamp-modifier again

[tehacx]

@GwnDaan Working now with the latest image version. Thanks a lot!

[portboy]

@GwnDaan your Docker image ist not working for me (unraid server 6.12.8) Logs: unifi_cam_proxy_gwndaan_timefix-proxy-15-1 | Traceback (most recent call last): unifi_cam_proxy_gwndaan_timefix-proxy-15-1 | File "/usr/local/bin/unifi-cam-proxy", line 8, in unifi_cam_proxy_gwndaan_timefix-proxy-15-1 | sys.exit(main()) unifi_cam_proxy_gwndaan_timefix-proxy-15-1 | File "/usr/local/lib/python3.9/site-packages/unifi/main.py", line 172, in main unifi_cam_proxy_gwndaan_timefix-proxy-15-1 | loop.run_until_complete(run()) unifi_cam_proxy_gwndaan_timefix-proxy-15-1 | File "/usr/local/lib/python3.9/asyncio/base_events.py", line 647, in run_until_complete unifi_cam_proxy_gwndaan_timefix-proxy-15-1 | return future.result() unifi_cam_proxy_gwndaan_timefix-proxy-15-1 | File "/usr/local/lib/python3.9/site-packages/unifi/main.py", line 165, in run unifi_cam_proxy_gwndaan_timefix-proxy-15-1 | cam = klass(args, logger) unifi_cam_proxy_gwndaan_timefix-proxy-15-1 | File "/usr/local/lib/python3.9/site-packages/unifi/cams/frigate.py", line 19, in init unifi_cam_proxy_gwndaan_timefix-proxy-15-1 | super().init(args, logger) unifi_cam_proxy_gwndaan_timefix-proxy-15-1 | File "/usr/local/lib/python3.9/site-packages/unifi/cams/rtsp.py", line 14, in init unifi_cam_proxy_gwndaan_timefix-proxy-15-1 | super().init(args, logger) unifi_cam_proxy_gwndaan_timefix-proxy-15-1 | File "/usr/local/lib/python3.9/site-packages/unifi/cams/base.py", line 49, in init unifi_cam_proxy_gwndaan_timefix-proxy-15-1 | self._ssl_context.load_cert_chain(args.cert, args.cert) unifi_cam_proxy_gwndaan_timefix-proxy-15-1 | IsADirectoryError: [Errno 21] Is a directory unifi_cam_proxy_gwndaan_timefix-proxy-15-1 exited with code 1

[mrmiles156]

Is anyone willing to share their config file as I keep getting the following error when starting the Docker Container. proxy: error: argument impl: invalid choice: ' frigate' (choose from 'amcrest', 'dahua', 'frigate', 'hikvision', 'lorex', 'reolink', 'reolink_nvr', 'rtsp')

Docker-compose.yml `version: "3.9" services: unifi-cam-proxy: restart: unless-stopped image: keshavdv/unifi-cam-proxy volumes:

• "./client.pem:/client.pem" command: unifi-cam-proxy --mac 'f2:00:00:41:bd:04' -H 192.168.11.1 -i 192.168.15.11 -c /client.pem -t r7PgexvZRlWibDqHziQ6d7mElOSL0r0J \ frigate \ -s rtsp://192.168.15.11:554/stream0 \ --mqtt-host 192.168.15.100 \ --frigate-camera Front_Drive`

Thank you in advance, this is such a cool idea

[mrmiles156]

[stale[bot]]

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.