Josh HawkinsandGitHub e73a14db5d
CI / AMD64 Build (push) Waiting to run
CI / ARM Build (push) Waiting to run
CI / Jetson Jetpack 6 (push) Waiting to run
CI / AMD64 Extra Build (push) Blocked by required conditions
CI / ARM Extra Build (push) Blocked by required conditions
CI / Synaptics Build (push) Blocked by required conditions
CI / Assemble and push default build (push) Blocked by required conditions
Miscellaneous fixes (0.18 beta) (#23898)
* update homekit docs

* update dictionary

* preserve function names in production builds

adds only 162kb gzipped/450k unzipped to the bundle

* margin tweak

* fix maximum update depth exceeded when dragging the timeline handlebar

Dragging the handlebar, especially quickly or with fast direction changes, could exceed React's nested update limit and unmount the whole app, leaving a blank screen. Motion search was worst affected.

The drag loop committed a new time into React state on every animation frame. Edge auto-scrolling mutates scrollTop each iteration, so the value always differed and React's same-value bail-out never engaged, letting the update chain run to the limit of 50. Pace those commits to one per 100ms and flush the pending value on release, so the drop position is still exact. The handlebar position and label are written to the DOM directly and remain at frame rate.

useUserInteraction dispatched state on every scroll and touchmove event; only commit on the leading edge.

Motion search also passed fresh array literals for the timeline's events, motion events and unavailable ranges, giving the segment memo and the drag effect new dependencies on every render. Both views also passed an inline arrow for onHandlebarDraggingChange, which is an effect dependency that calls setState.

* Verify motion search jobs belong to the requested camera

* Apply persisted profile and runtime overrides before workers start

Worker processes are handed a copy of the config when they start and only learn about later changes from the config_updater broadcast, which is plain ZMQ PUB/SUB with no queue, ack, or retained value, so a message published before a subscriber has connected is dropped and never re-sent. The persisted profile and the runtime camera toggles were restored only by that broadcast, at the very end of startup, so a worker that lost the race kept its yaml values for the rest of the session: audio detection kept running on a camera whose audio had been toggled off, even though /api/config, the UI, and the runtime state file all showed it disabled. Split both restores into a config half and a publish half. ProfileManager.restore_persisted_profile_to_config() and Dispatcher.reapply_runtime_state_to_config() now run right after init_profile_manager(), before the first worker starts, so every worker is handed a config that already carries both layers. ProfileManager.restore_persisted_profile() and Dispatcher.restore_runtime_state() still run at the end of startup: the recording, review, and embeddings processes start before the dispatcher exists, so the broadcast remains their only channel, and MQTT needs the retained switch states. Both config passes have to stay after init_profile_manager(), which snapshots the config as the no-profile base that deactivation resets to.

* End timeline drags on touchcancel
2026-08-05 07:40:24 -05:00
2026-07-25 11:22:05 -06:00
2026-03-20 07:24:34 -06:00
2021-02-25 07:01:59 -06:00
2026-07-08 08:27:38 -05:00
2026-07-25 11:22:05 -06:00
2023-07-01 08:18:33 -05:00
2026-05-20 08:36:49 -06:00
2026-07-25 11:22:05 -06:00
2023-01-06 07:03:16 -06:00
2026-01-01 09:56:09 -06:00
2023-11-18 08:04:43 -06:00
2026-07-06 12:28:02 -05:00

logo

Frigate NVR™ - Realtime Object Detection for IP Cameras

License: MIT

Translation status

[English] | 简体中文

A complete and local NVR designed for Home Assistant with AI object detection. Uses OpenCV and Tensorflow to perform realtime object detection locally for IP cameras.

Use of a GPU or AI accelerator is highly recommended. AI accelerators will outperform even the best CPUs with very little overhead. See Frigate's supported object detectors.

  • Tight integration with Home Assistant via a custom component
  • Designed to minimize resource use and maximize performance by only looking for objects when and where it is necessary
  • Leverages multiprocessing heavily with an emphasis on realtime over processing every frame
  • Uses a very low overhead motion detection to determine where to run object detection
  • Object detection with TensorFlow runs in separate processes for maximum FPS
  • Communicates over MQTT for easy integration into other systems
  • Records video with retention settings based on detected objects
  • 24/7 recording
  • Re-streaming via RTSP to reduce the number of connections to your camera
  • WebRTC & MSE support for low-latency live view

Documentation

View the documentation at https://docs.frigate.video

Donations

If you would like to make a donation to support development, please use Github Sponsors.

License

This project is licensed under the MIT License.

  • Code: The source code, configuration files, and documentation in this repository are available under the MIT License. You are free to use, modify, and distribute the code as long as you include the original copyright notice.
  • Trademarks: The "Frigate" name, the "Frigate NVR" brand, and the Frigate logo are trademarks of Frigate, Inc. and are not covered by the MIT License.

Please see our Trademark Policy for details on acceptable use of our brand assets.

Screenshots

Live dashboard

Live dashboard

Streamlined review workflow

Streamlined review workflow

Multi-camera scrubbing

Multi-camera scrubbing

Built-in mask and zone editor

Built-in mask and zone editor

Translations

We use Weblate to support language translations. Contributions are always welcome.

Translation status

Copyright © 2026 Frigate, Inc.

Languages
TypeScript 52.7%
Python 45.9%
Shell 0.4%
CSS 0.4%
Dockerfile 0.2%
Other 0.2%