[Config Support]: MQTT End event sent before event is over #6662
Comments
|
The event is over, but the last video segment may be in the cache for up to 10 seconds before it's available. You just need to add a delay. |
|
Ah, ok. I'll try that. I have just added wait for two seconds so far. Is it possible to reduce that delay without degradation? One of the reasons I want to get the video out fast is in case someone cuts the power to the house, or finds the Raspberry Pi. I want the videos to be backup up to Telegram as quick as possible. No real big deal though, I doubt anything like that will ever happen. |
|
MP4 files require the end trailer to be written so the delay will be as long as the segment is. 10 seconds is the optimal duration of a segment and reducing that duration will lead to various issues and inefficiencies |
|
Ok, thank you. Ill add a delay to my code :) |
|
I've now rewritten my code and added a 20 second delay after the "end" event for video retrieval . I'm running this on a raspberry pi 4. Its doing nothing else though and does not seem maxxed out, but I'm guessing it simply can't go that fast? Is there an API call I can check to see if the event/video is written completely to disk? |
|
Are you watching the clip at the same time as you are pulling it? Because if it's available in the webUI we would expect the same to be shown in the downloaded clip. What are you using to pull the clip? |
|
No, it's happening later. I run out to trigger camera event, get the event on phone after a bit, and then load the UI in Frigate when I have run back to my PC :). |
|
Yes, there is an existing feature request for that |
|
Ah, Nice. Ill just add another 10 second delay then and wait for that. |
|
@NickM-27 I tried to find the feature request but failed. Just a suggestion on it, maybe you could send an event after "end" with "completed" or something similar which signals that all recording is also done and written. Then I could just listen to that instead of also having to poll an API. |
|
#2128 is the feature request. If the additional delay worked then I think this issue can be closed |
|
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. |
Describe the problem you are having
Hi!
This might just be me not understanding Frigate, but I have an issue where the videos sent to my Telegram group (based on "end" events) are sometimes cut short. To me this sounds like either the event is not truly over, or the video is only partially returned from the frigate API.
I wrote the Python code to send the videos myself and added wait-steps of a few seconds to give Frigate time to save the video but still the Video I get when I download from frigates API can sometimes be a lot shorter than the entire video that is available through the Frigate UI.
I can directly go into the Frigate UI after the video is uploaded to Telegram and get the whole video.
Version
0.12.0-da3e197
Frigate config file
Relevant log output
Frigate stats
No response
Operating system
HassOS
Install method
HassOS Addon
Coral version
USB
Any other information that may be helpful
The code that listens to the mqtt / gets the video files is run on a separate server.
The code for my "Frigate to Telegram Sender" can be found here. It is a WIP.
https://github.com/InfriaAB/FrigateSender/
The text was updated successfully, but these errors were encountered: