* fix regex for cookie_name to be general snake case
* Update frigate/config/auth.py
Co-authored-by: Blake Blackshear <blake.blackshear@gmail.com>
---------
Co-authored-by: Blake Blackshear <blake.blackshear@gmail.com>
* Don't track shared memory in frame tracker
* Don't track any instance
* Don't assign sub label to objects when multiple cars are overlapping
* Formatting
* Fix assignment
* Use custom body for the export recordings endpoint
* Fixed usage of ExportRecordingsBody
* Updated docs to reflect changes to export endpoint
* Fix friendly name and source
* Updated openAPI spec
* Updated documentation for the review endpoint
* Updated documentation for the review/summary endpoint
* Updated documentation for the review/summary endpoint
* Documentation for the review activity audio and motion endpoints
* Added responses for more review.py endpoints
* Added responses for more review.py endpoints
* Fixed review.py responses and proper path parameter names
* Added body model for /reviews/viewed and /reviews/delete
* Updated OpenAPI specification for the review controller endpoints
* Run ruff format frigate
* Drop significant_motion
* Updated frigate-api.yaml
* Deleted total_motion
* Combine 2 models into generic
* Add reindex progress to mobile bottom bar status alert
* move menu to new component
* actions component in search footer thumbnail
* context menu for explore summary thumbnail images
* readd top_score to search query for old events
* Add service manager infrastructure
The changes are (This will be a bit long):
- A ServiceManager class that spawns a background thread and deals with
service lifecycle management. The idea is that service lifecycle code
will run in async functions, so a single thread is enough to manage
any (reasonable) amount of services.
- A Service class, that offers start(), stop() and restart() methods
that simply notify the service manager to... well. Start, stop or
restart a service.
(!) Warning: Note that this differs from mp.Process.start/stop in that
the service commands are sent asynchronously and will complete
"eventually". This is good because it means that business logic is
fast when booting up and shutting down, but we need to make sure
that code does not rely on start() and stop() being instant
(Mainly pid assignments).
Subclasses of the Service class should use the on_start and on_stop
methods to monitor for service events. These will be run by the
service manager thread, so we need to be careful not to block
execution here. Standard async stuff.
(!) Note on service names: Service names should be unique within a
ServiceManager. Make sure that you pass the name you want to
super().__init__(name="...") if you plan to spawn multiple instances
of a service.
- A ServiceProcess class: A Service that wraps a multiprocessing.Process
into a Service. It offers a run() method subclasses can override and
can support in-place restarting using the service manager.
And finally, I lied a bit about this whole thing using a single thread.
I can't find any way to run python multiprocessing in async, so there is
a MultiprocessingWaiter thread that waits for multiprocessing events and
notifies any pending futures. This was uhhh... fun? No, not really.
But it works. Using this part of the code just involves calling the
provided wait method. See the implementation of ServiceProcess for more
details.
Mirror util.Process hooks onto service process
Remove Service.__name attribute
Do not serialize process object on ServiceProcess start.
asd
* Update frigate dictionary
* Convert AudioProcessor to service process
* only save a fixed number of thumbnails if genai is enabled
* disable cpu_mem_arena to save on memory until its actually needed
* fix search settings pane so it actually saves to the config
