Configurable delay between Frigate requests

[ronluna]

Checklist:

• [ x ] I updated to the latest version available
• [ x ] I cleared the cache of my browser

Release with the issue: 5.2.0 Last working release (if known):

Browser and Operating System: Chrome/macOS

I’ve noticed is when using the frigate-hass-card in timeline view . If the timeline is moved to a time interval where frigate has no events or recordings (example: before frigate started recording by events) or if the timeline is moved too frequent involving multiple cameras (causing to send multiple requests to the frigate server) frigate nginx server would return a 504 Gateway Time-out error. without showing any errors in the logs . This is a consistent when accessing the card in timeline mode with multiple cards.

I have been unable to capture any errors on the frigate logs. although frigate nginx does hangs and recovers itself. If multiple recording event request are being send to frigate too fast as:

http://frigate_server:port/api/camera_name/recordings?after=1697860800&before=1698063959

I've shared this behavior with on the frigate repo here they suggested that sending too many requests within 1 second is not recommended so I'm wondering if when using the frigate-hass-card timeline a queue could be put in place where requests can be send half or a quarter second apart in order to prevent this from happening ?

[dermotduffy]

I've shared this behavior with on the frigate repo https://github.com/blakeblackshear/frigate/issues/8284 they suggested that sending too many requests within 1 second is not recommended so I'm wondering if when using the frigate-hass-card timeline a queue could be put in place where requests can be send half or a quarter second apart in order to prevent this from happening ?

This is complexity that ideally the card would not need to implement vs the "server just working", or having an inbound request queue on its side as the card cannot know how much load the Frigate server can handle. For recordings, there's no batch interface currently, so if you have 13 cameras you'll get 13 requests -- I could imagine optimizations there to support multiple camera names together in 1 request, or even better to combine segments on the server side so the JS doesn't need to do it. A simple fix may simple be to turn off recording rendering on the timeline with that many cameras.

On the card side, perhaps there is some sort of configurable delay that could be implemented as a performance setting.

[ronluna]

Another idea could be:

• a toggle button to show/hide recordings? In that way the the card can send a request for recordings on demand and apart from the event's request.
• configurable option to set the event's limit (from the 50s default).
• configurable option to increase request's timeout (for slower setup)?
• a modal spinner while the card still waiting on request's responses to prevent sending repeated request while sliding or zooming the timeline .

[dermotduffy]

a toggle button to show/hide recordings? In that way the the card can send a request for recordings on demand and apart from the event's request.

Just to make sure you know, you can turn them off in the config. So I interpret this suggestion as to add a button to toggle? Seems a bit overly specific to me honestly, i.e. will anyone want this? :-)

configurable option to set the event's limit (from the 50s default).

This exists already, media_chunk_size.

configurable option to increase request's timeout (for slower setup)?

The timeout is actually in the integration, not in the card. It is set to 10s which is a very long time in my opinion! I think to implement this we'd want to allow the card to pass arbitrary timeouts, but I'm not sure it's worth it.

a modal spinner while the card still waiting on request's responses to prevent sending repeated request while sliding or zooming the timeline .

Yes, I think there is some sort of request queue that could be used specifically for the timeline, where it only makes one request of each kind at a time -- this may introduce delays in loading the timeline content, but could help.

[ronluna]

It's very helpful to show the recordings in the timeline along with the events. it give the ability to click on a recording or the events from within the same view (very helpful). although current's frigate api does not seems to be capable of processing large amount of requests too frequently so I'm suggesting a way for the timeline view to not auto load the recordings (or event the events) as soon as the timeline is moved or zoomed... perhaps it could be event better approach could be to not automatically load the events nor the recording during movement but maybe allow the user to go to specific time frame and at that moment press a button to load the events and another one for recordings ? It is not the most ideal scenario but at least it would help a lot in offloading the amount of request being sent to frigate.

Currently I have 13 cameras and the frigate server has plenty of resources but even though frigate is unable to handle the amount of request being sent by the timeline view....so it is likely that other user could have many more cameras with limited server resources so it seems like this could turn in a very common problem for many user in the near future...

[dermotduffy]

Currently I have 13 cameras and the frigate server has plenty of resources but even though frigate is unable to handle the amount of request being sent by the timeline view....so it is likely that other user could have many more cameras with limited server resources so it seems like this could turn in a very common problem for many user in the near future...

FWIW: It's very uncommon to have that many cameras, at least I rarely see it in user support requests.

Just to be sure, if you configure recordings to be off, I take it your performance problems are mostly solved? My issue with all the other ideas in this issue is that they are hacking around the fact that this should "just work out of the box". I'd rather spend time performance analyzing this, or implementing a new API to make it just work, etc.

[ronluna]

I have not been able to get the "504 gateway time-out" error while having the recordings options turned off on this particular server that has plenty of cpu cores and ram with a dual tpu coral, I do have another server with very limited resources and I even had to reduce media_chunk_size to 5 and I'm still getting similar error (but that's different story/ I'm going to add more ram and a larger/faster hdd and share my findings afterwards).

I completely understand and support your approach, Hopefully the frigate team can consider improving api to request recordings globally and not just per camera...

Thank you for taking the time in analyzing this.