[FR] Ability to override Frigate latest.jpg and snapshot.jpg

[jakowenko]

Continuing the discussion from #102 @hawkeye217 is looking for a way to override the latest.jpg and snapshot.jpg images rather than using the default ones from Frigate's API.

Here is my proposed solution.

frigate:
  url: https://frigate.com:5000
  
  # defaults applied to all cameras and events
  attempts:
    # number of times double take will request a frigate latest.jpg for facial recognition
    latest: 10
    # number of times double take will request a frigate snapshot.jpg for facial recognition
    snapshot: 0
    # process frigate images from frigate/+/person/snapshot topics
    mqtt: true
    # add a delay expressed in seconds between each detection loop
    delay: 0

  image:
    # height of frigate image passed for facial recognition
    height: 500

  # override global frigate attempts and images per camera
  events:
    office:
      attempts:
        latest: 0
        snapshot: 5
        mqtt: false
        delay: 0

      image:
        height: 600
        snapshot: http://snapshot-url.com/image.jpg
        latest: http://latest-url.com/image.jpg

With this configuration the office camera has new values applied to it. I've disabled the latest processing by setting the attempts.latest to 0. The MQTT snapshot is also disabled by setting attempts.mqtt to false. You can also override the snapshot.jpg or latest.jpg image instead of using the ones provided from Frigate's API.

You can also change the image.height per camera, but this will only apply to the standard latest.jpg and snapshot.jpg images from Frigate. In the above example because I have a custom value for latest and snapshot, then the height will be omitted.

---

@hawkeye217 I have all of these changes above ready locally. Just want to make sure the above makes sense before I release a new beta build with this. Let me know what you think!

[hawkeye217]

Looks like it will do what I need and more! Thanks!

[jakowenko]

Looks like it will do what I need and more! Thanks!

Awesome, thanks for the quick reply! I'll get this pushed up tonight and let you know when it's ready to test 🤞

[Sylvain-Laine]

It's awesome, it fits my needs to !

[jakowenko]

Hey @hawkeye217 and @Sylvain-Laine, this is ready for testing! The latest beta should include it docker pull jakowenko/double-take:beta.

Hopefully I didn't break anything haha! Let me know if it works and what you think.

I updated the README to include the new options.

[Sylvain-Laine]

So far it works !
Im going to let it run this morning and test a bit more !
Thanks

[hawkeye217]

Thanks for the fast turnaround! I'll install it and test it today.

[hawkeye217]

Tested the beta on my doorbell cam and another interior cam. It all seems to be working great for the doorbell cam, but the interior cam's snapshot url requires a username and password as follows:

http://username:[email protected]/snapshot.cgi

I'm guessing the way you've set up axios doesn't allow for that, as I'm getting a 401 (unauthorized) error:

error: Error: url validation error: Request failed with status code 401
    at createError (/double-take/api/node_modules/axios/lib/core/createError.js:16:15)
    at settle (/double-take/api/node_modules/axios/lib/core/settle.js:17:12)
    at IncomingMessage.handleStreamEnd (/double-take/api/node_modules/axios/lib/adapters/http.js:269:11)
    at IncomingMessage.emit (events.js:412:35)
    at endReadableNT (internal/streams/readable.js:1317:12)
    at processTicksAndRejections (internal/process/task_queues.js:82:21)

[jakowenko]

Hm...glad it's working at least for one of them. I haven't tried any URLs before that have username:password in them.

Does going to http://username:[email protected]/snapshot.cgi directly in your browser render the image OK?

[hawkeye217]

Yes it does. The browser does basic authentication based on the username and password in the url.

Axios requires a header object to do basic auth. There probably is an easy way to take the keys from the url, but I'm just not familiar with it.

[jakowenko]

Ah, I didn't know the browser did that in the background. Ya it should be pretty easier to take that out of the URL then split it based on the : value to get username and password. I'll try to sneak this fix in tonight.

await axios.get(url, {}, {
  auth: {
    username,
    password
  }
});

[jakowenko]

I tried to test this with http://foo:[email protected]/basic-auth/foo/bar as the URL. It works when I set my image to be the URL with the auth in the URL.

Did you try that as well?

The below worked and at least passed that URL check. When I remove foo:bar I get the 401 like you had.

  events:
    office:
      image:
        latest: http://foo:[email protected]/basic-auth/foo/bar

[Sylvain-Laine]

Just FYI,
Was working on the previous beta build and is still working for the new one :
Snapshot URL from a Reolink camera behind a Reolink NVR : http://[ip]/cgi-bin/api.cgi?cmd=Snap&channel=2&rs=[key]&user=[user]&password=[password]

[jakowenko]

Just FYI,
Was working on the previous beta build and is still working for the new one :
Snapshot URL from a Reolink camera behind a Reolink NVR : http://[ip]/cgi-bin/api.cgi?cmd=Snap&channel=2&rs=[key]&user=[user]&password=[password]

Glad to hear! @hawkeye217 can you confirm if you were passing the user:pass in your config.

[hawkeye217]

Glad to hear! @hawkeye217 can you confirm if you were passing the user:pass in your config.

I decided not to use that specific camera with Double Take, so I didn't look into it any further. But if it works for others, I'm sure it was just something specific to my setup. Thanks!

[jakowenko]

Glad to hear! @hawkeye217 can you confirm if you were passing the user:pass in your config.

I decided not to use that specific camera with Double Take, so I didn't look into it any further. But if it works for others, I'm sure it was just something specific to my setup. Thanks!

No problem. I'm going to close this since these changes got merged into the 1.1.0 release. Feel free to open a new issue if you run into problems.

[miguelangel-nubla]

I am also getting 401 errors with basic digest auth.

21-10-10 02:48:56 error: Error: url resolve error: timeout of 1000ms exceeded
    at createError (/double-take/api/node_modules/axios/lib/core/createError.js:16:15)
    at RedirectableRequest.handleRequestTimeout (/double-take/api/node_modules/axios/lib/adapters/http.js:303:16)
    at RedirectableRequest.emit (events.js:400:28)
    at Timeout.<anonymous> (/double-take/api/node_modules/follow-redirects/index.js:164:12)
    at listOnTimeout (internal/timers.js:557:17)
    at processTimers (internal/timers.js:500:7)
21-10-10 02:48:59 info: processing office: 1633834131.846095-5b9z17
21-10-10 02:48:59 error: Error: url validation error: Request failed with status code 401
    at createError (/double-take/api/node_modules/axios/lib/core/createError.js:16:15)
    at settle (/double-take/api/node_modules/axios/lib/core/settle.js:17:12)
    at IncomingMessage.handleStreamEnd (/double-take/api/node_modules/axios/lib/adapters/http.js:269:11)
    at IncomingMessage.emit (events.js:412:35)
    at endReadableNT (internal/streams/readable.js:1334:12)
    at processTicksAndRejections (internal/process/task_queues.js:82:21)
21-10-10 02:48:59 info: done processing office: 1633834131.846095-5b9z17 in 0.01 sec
21-10-10 02:48:59 info: {
  id: '1633834131.846095-5b9z17',
  duration: 0.01,
  timestamp: '2021-10-10T02:48:59.146Z',
  attempts: 0,
  camera: 'office',
  zones: [],
  matches: [],
  misses: [],
  token: '********'
}

The "resolve" error does not make sense to me as the url is a IP not a domain name. I also tried with a .local domain but same error.

The auth url is correct, working in a fresh incognito window.

[jakowenko]

@miguelangel-nubla, that error just means the URL/IP did not respond within 1 second, so the request times out. I have a hard timeout of 1 second currently to prevent these status checks from hanging too long.

Have you been able to verify the container can ping the IP?

[miguelangel-nubla]

Yes connectivity is right.

Upon further investigation the device asks for digest auth instead of basic auth.

I made it work as a workaround with a reverse proxy that strips the digest auth and that works as expected, so the issue is definitely in the auth logic.

[jakowenko]

Ah ok, good to know it's related to digest auth. If you want me to add in support for that, feel free to open a feature request. Glad you got it working with the reverse proxy for now.

[redwood996]

I have the similar config, but double take didn't get any picture after overriding the snapshot.

# frigate settings (default: shown below)
frigate:
  url: http://myFrigateURL:5000
  
  # defaults applied to all cameras and events
  attempts:
    # number of times double take will request a frigate latest.jpg for facial recognition
    latest: 10
    # number of times double take will request a frigate snapshot.jpg for facial recognition
    snapshot: 0
    # process frigate images from frigate/+/person/snapshot topics
    mqtt: true
    # add a delay expressed in seconds between each detection loop
    delay: 0

  image:
    # height of frigate image passed for facial recognition
    height: 600

  # override global frigate attempts and images per camera
  events:
    Front_Left:
      attempts:
        latest: 0
        snapshot: 5
        mqtt: false
        delay: 0

      image:
        height: 600
        snapshot: http://mycameraURL/snap.jpeg 

I test http://mycameraURL/snap.jpeg, and it works well in the browser. Here is the log

22-09-14 15:27:36 info: MQTT: subscribed to frigate/events, frigate/+/person/snapshot
22-09-14 15:27:59 info: processing front_left: a35077bc-6e32-41fa-aff3-ff6d2cb52bc8
22-09-14 15:27:59 info: processing Front_Left: 1663194479.261464-wni9pk
22-09-14 15:27:59 info: done processing front_left: a35077bc-6e32-41fa-aff3-ff6d2cb52bc8 in 0.09 sec
22-09-14 15:27:59 info: {
  id: 'a35077bc-6e32-41fa-aff3-ff6d2cb52bc8',
  duration: 0.09,
  timestamp: '2022-09-14T22:27:59.597Z',
  attempts: 1,
  camera: 'front_left',
  zones: [],
  matches: [],
  misses: []
}
22-09-14 15:28:01 info: done processing Front_Left: 1663194479.261464-wni9pk in 1.83 sec
22-09-14 15:28:01 info: {
  id: '1663194479.261464-wni9pk',
  duration: 1.83,
  timestamp: '2022-09-14T22:28:01.345Z',
  attempts: 5,
  camera: 'Front_Left',
  zones: [],
  matches: [],
  misses: []
}
22-09-14 15:28:04 info: processing Front_Left: 1663194479.261464-wni9pk
22-09-14 15:28:07 info: done processing Front_Left: 1663194479.261464-wni9pk in 2.55 sec
22-09-14 15:28:07 info: {
  id: '1663194479.261464-wni9pk',
  duration: 2.55,
  timestamp: '2022-09-14T22:28:07.122Z',
  attempts: 5,
  camera: 'Front_Left',
  zones: [],
  matches: [],
  misses: []
}
22-09-14 15:28:09 info: processing Front_Left: 1663194479.261464-wni9pk
22-09-14 15:28:12 info: processing front_left: d0f5a08a-f1a0-40dd-9867-f13d237f9fd4
22-09-14 15:28:12 info: done processing Front_Left: 1663194479.261464-wni9pk in 0 sec
22-09-14 15:28:12 info: {
  id: '1663194479.261464-wni9pk',
  duration: 0,
  timestamp: '2022-09-14T22:28:12.177Z',
  attempts: 5,
  camera: 'Front_Left',
  zones: [],
  matches: [],
  misses: []
}
22-09-14 15:28:12 info: done processing front_left: d0f5a08a-f1a0-40dd-9867-f13d237f9fd4 in 0.12 sec
22-09-14 15:28:12 info: {
  id: 'd0f5a08a-f1a0-40dd-9867-f13d237f9fd4',
  duration: 0.12,
  timestamp: '2022-09-14T22:28:12.296Z',
  attempts: 1,
  camera: 'front_left',
  zones: [],
  matches: [],
  misses: []
}