MQTT message for when the m3u8 clips are done being generated

[darkalfx]

Describe what you are trying to accomplish and why in non technical terms
I want to be able to integrate with Frigate with my automations, however right now if I listen on the type == end of Frigate's MQTT messages, the clips (I'm talking about the m3u8 clips) are absolutely not ready to be downloaded, they are incomplete.

However after waiting ~10 seconds or so, they seem to finish generating and then show the whole event.

Describe the solution you'd like
I think either delaying the MQTT messages's type == end to when the clips are done generating or having a new message after they are generated would be ideal.

Describe alternatives you've considered
What I'm doing right now is basically polling the m3u8 file until the duration stops changing, that's how I know that it has completed, however this does introduce delay and was kind of annoying to make.

Additional context
Right now there is a discrepancy that makes the Download Clip button take far longer than the m3u8 file to become completely available for viewing/downloading, it would be very nice if the Download Clip button would be available as fast as the m3u8 version.

[ozett]

yeah, i also observed a delay between mqtt, type==end and the readyness for download via api-call.
but my current use is not time critial, i wait 1-2 minutes before download. (ver.9.3 actual)

[blakeblackshear]

The process tracking events and the process tracking recordings are not aware of each other. If you have the default segment size of 10s, you should at most have to wait 10s to ensure that final segment is included. An upcoming release will handle in progress events better and the download clip button will work by including all the video that is available at the time.

[ozett]

and luckily the mqtt-event has a flag, that there is a clip. (did not test this timecritically)

[darkalfx]

The process tracking events and the process tracking recordings are not aware of each other. If you have the default segment size of 10s, you should at most have to wait 10s to ensure that final segment is included. An upcoming release will handle in progress events better and the download clip button will work by including all the video that is available at the time.

I am using the default segment size of 10s, however according to my logs, its not rare for it to take closer to 12 seconds on my hardware to finish.

Having a way to know exactly when the recording job has finished for a specific event would be very very helpful for automations

[ozett]

@darkalfx "has_clip" == true
i would think, that the clip is ready (== finished recording?) when the flag is set.
or not?

[darkalfx]

@darkalfx "has_clip" == true i would think, that the clip is ready (== finished recording?) when the flag is set. or not?

Unfortunately not.

From what I have seen, has_clip is only set to true on the MQTT messages with the type == end, not on any prior messages, which makes sense since this marks the end of the detection.

However, this only tells you whether or not a clip is present and not if the clip actually finished recording.

On my setup using the default segment size of 10 seconds, it often takes around 12 seconds for the clip to be fully recorded after receiving the MQTT message with type == end and has_clip == true.

[ryanm101]

In my HA automations I have the snapshot sent to telegram immediately and a delay that sends the clip 45sec later, I wouldnt want the 'end' to wait longer as for my use case that is too long.

E.g. I want to see who is at my front door before i answer it, i don't need a clip to see who is at the door, the clip is good to see they left the package (or nicked it)