Replies: 25 comments 129 replies
Would it be possible to detect if YAML changes required a reboot and have one save button that dynamically displayed if the changes need a reboot or could be done live? Sometimes doing a find and replace is just faster than using a GUI but the reboot isn't so fast. |
|
Frigate doesn't continuously watch the YAML file and changes to the YAML file don't trigger any of the dynamic update mechanisms. That is only available through the UI. A restart is fast and easy if you make YAML changes directly. |
|
I was thinking more do a delta from the running and saved config and if a section was changed that COULD be live process it. but if the functionality is bound to the UI changes that is fine. |
|
Motion Search
I had no idea where this was, or what a kebab menu was. (actually didn't know that was the name for the vertical ... menus) I would highly suggest changing the icon to something that looks like search or motion or a magnify class.. Also with the current bottom right placement it doesn't consistently appear due to massive differences in aspect ratios. 
and of note if it IS over lapping and there happens to be something white it is invisible. 
|
|
Do you mean Motion Review or Motion Search? I think Motion Review should stay in Review. Perhaps Motion Search could be added to the Actions menu. |
Both appear to be single camera scope features I think they both make more sense under the action menu. |
Well not in all cases 
|
|
I've improved the visibility of the kebab menu and added Motion Search to the Actions menu for a future dev build. |
|
Fixed in #23358 |
|
Not sure if this is the place, but for the last few commit versions I've noticed that publishing to these topics is sometimes ignored.
There could be more, but these are the two I've had going Additionally I encountered an occasion where the Profile on the settings menu showed my Away profile was active, but the coloured dot at the bottom of the main window that represents this did not show and the Away profile was not active until i set it again with the menu. |
|
The Frigate logs should show when these values are changed via MQTT. What do your logs show? And have you looked at your MQTT broker's logs? |
|
I found a small bug that might be affecting the active profile, but I don't see anything in recent code changes that might be affecting the review alerts topic. The profile bug is fixed in this PR: #23358 |
Thx hawkeye, love your work!, |
|
Great! Glad to hear. Let us know if anything else comes up. Thanks for testing! |
|
When the motion search settings popup opens and the window size is too small or if I resize the browser while the search settings popup is up it starts zooming in uncontrollably till closed. |
|
Thanks, this will be fixed in a future dev build. |
|
Fixed in #23358 |
|
Small thought:
I was playing with creating a way to load up ONVIF presets, and queue them in a way similar to timeline editor in an AV editing program. It would be great if Frigate could natively handle something like this (ONVIF trigger for preset in a given order, with a unique hold time for each entry in the playlist/timeline; applying autotracking configurations in a per-playlist entry might be asking for too much.) I haven't seen anything like that just yet outside of certain camera's webUI. |
|
Good feedback. Will see what we can do to improve this. |
|
Motion Search Core i7-7700T (noting as I think I need to upgrade at this point it may not be enough for this feature)
Maybe some detection of frame rate from the recorded video would help bound the frame skip feature? I will tinker with it later but at the moment it is slower than me scrubbing through the video. |
|
8073174 is many times faster, it completed the default 24hrs in a reasonable interactive time window. This makes searching 1-2 days very practical to sit and wait for interactively. I am not so sure about search a whole week but I can give that a try. 
|
|
Great, thanks for testing. |
|
Not exactly specific to this search but being able to detect the hue shift / flash when cameras switch between color and IR night vision would be nice to filter out of a search like this.. Predictably on a multi day search there are two motion events when the camera goes from day to night and night to day. I wonder if simply sampling the average RGB values for the whole frame would give you a strong indicator if it was color or BW and that those frames could be skipped for various reasons optionally for motion. |
it hit the pre configured 25 event limit at may 28, however each day had two color / IR shifts so that eats into the count.. |
|
Thanks, this is about what I would expect from the optimizations. |
|
Motion Preview Unlike Motion search this feature seems very fast. I am guessing the filter box size is determined by the resolution / camera settings and can't be set? IN some cases I would like to have smaller boxes. AS far as usefulness it mostly shows me bugs and lighting shifts but that could be useful for tuning the cameras motion sensitivity with a replay. |
|
Yes, the goal of the feature is to quickly see any areas of motion that don't have detected objects associated with it. It serves as a companion to the existing scrubbable Motion review to quickly visualize rather than scrubbing. |
|
Hmm I wonder if instead of a full screen review launched from the multi camera view if it would work as part of the Timeline/Events/Details tabs but dynamically adding the extra settings buttons |
|
The goal is quick review, so motion previews will continue to live in the same flow as alerts/detections/motion, not in History. |
|
In "Audio detection", unlike "Motion detection" or "Recording" sections, there is no slider to "Enable audio". |
You don't see this? |
|
It seems that on mobile devices, when creating a state classification, the camera list cannot be scrolled to show the cameras below. |
|
Fixed in #23367 |
|
Installed |
|
It didn't work because you're already on 0.18, it only migrates when moving from 0.17 |
|
OK, I mentioned a problem yesterday where Frigate and MQTT seem to get out of sync. In Frigate - set the Review_Alerts toggle for a camera to Off (MQTT at this point says it is off} At this point, the Review Alerts toggle is set to ON, MQTT Explorer says it is OFF and in Home Assistant the related switch also appears off. Its been doing my head in for a few days, and it doesn't seem like intended behaviour. |
|
I see a bug in the code here. Frigate correctly changes the backend config but does not currently re-publish retained MQTT topics (like the one used for I'll push a fix for the next dev build. |
|
Fixed in #23373 |
|
Regression: |
|
Thanks, this is fixed in #23373 |
|
When a camera is disabled (global configuration/Camera management) it's still showing up in |
|
This is working as expected, just because a camera is disabled right now does not mean it was always disabled, and its previous recordings / previews generally still need to be available. |
|
Indeed. Maybe making the |
|
I'm not sure if this is new in 0.18, but I don't remember it happening before... In the History view, if I click the magnifying glass to zoom in on the timeline, it can take 5-6 seconds to load it. Looking in the nginx logs, I can see a request to 
From nginx: Brief excerpt of the JSON itself below. There are thousands of empty camera entries which looks...suspicious. I queried the recordings table in sqlite and there were no rows where camera was null (to be expected given the column is not null) or empty. FWIW, below is Claude's diagnosis... Claude code analysis of reporting bugThe bug motion gets 0.0 from .fillna(0.0) — so the bucket survives as a row The join keeps every motion bucket, pairing those gap buckets with camera: "". |
|
Now effectively instant! |
|
Great! Thanks for testing. I'll push this change for the next dev build. |
|
Changes are in this PR: #23383 |
|
Thank you! Completely changes the "feel" of that page for me now it's effectively instant - it's a speed up on the initial load as well, not just when you zoom the timeline. Hopefully people notice, I would have thought it would affect everyone, particularly anyone running on lower-powered machines. |
|
Absolutely. Thanks again for the help! |
|
Can you raise the +5000ms to +10000ms? 0.18.0-47a06c8 |
Is this the same as not defining What i figured out: Now, some hours later, i've re-enabled audio (uncommented go2rtc audio line in Frigate config) and its working properly again (as if nothing ever happened). I guess i will let it run for now to see if its coming back or if it was a one-time bogus. I've checked some broken 10sec clips with ffprobe. There are no timestamp delays or errors shown. The files look completely fine. AAC/audio tracks are included (not missing) but are silent. Just for reference: Thanks so far. If it comes back i will keep you updated. |
|
Thanks for following up. We've actually just released a new build that ships with ffmpeg 8 (due to some audio handling bugs in ffmpeg 7.1 that we weren't sure if they affected you directly or not). I'd be curious how that works for you. |
|
I'm on a08e2d7 now. All fine so far. |
|
It's the default unless you're running some distribution that caches env vars like portainer |
|
Oh, it's env var. Then I can explain. :-) |
|
Hi guys! Please disregard if this is outside of the scope of feedback you're looking for at this stage.
The most obvious metric is my Driveway camera which uses the hi-res stream for detection. It jumped from before on after on |
|
difficult to know what this could be related to, potentially more advanced features in the newer Intel driver or firmware, not much we can do if that is the case. We are about to push an upgraded build with newer ffmpeg for general testing, would be curious to see how this might change things |
|
You're probably right that it could be the new Intel drivers, I just tested switching to I see the new build images are being deployed now so I'll test that shortly. |
|
Unfortunately no change when running the latest image a08e2d7. I'll try reverting back to |
|
The log message here is indicating that the output audio codec for recordings needs to be set to AAC on the camera or transcoded to AAC with |
|
Log entry with unknown type and tag: 
|
|
This message comes from a deeper sub module that bypasses frigate's logger. It should be suppressed, though. Are you seeing it on startup or at another time? What enrichments do you have enabled? |
|
Changing to version a08e2d7 (new ffmpeg 8?) is crashing on a sub-stream. With version 3f0ebb3 it works without any error. fenster_sub: ffmpeg:rtsp://10.1.0.2:8557/fenster/stream_sub#hardware#video=h264#width=640 results in: error | 2026-06-04 10:10:49 | watchdog.fenster | The following ffmpeg logs include the last 100 lines prior to exit. |
|
You'll want to look at the go2rtc logs for this one. |
|
The ffmpeg 8.0 upgrade broke hard for me. About 2/3rds of my cameras show constant errors in go2rtc logs: Seems to have already been noted on go2rtc: AlexxIT/go2rtc#1984 (comment) as a bug in ffmpeg (or less friendly behaviour). This fixed it for me: Using iGPU on Intel i7-10700-t |
|
Some of my config: |
|
It's working for me however I got off qsv to pure vaapi and switched from i965 to iHD awhile ago on my 7th gen intel a few frigate versions ago |
|
Just wanted to follow up of running more days without restart that I am seeing slightly higher amounts of encoding errors with ffmpeg 8 vs 7.. I could run a weeks without errors on 7 but I noticed a few encoding errors about every 4-5 hours on 8. |
|
What are the errors you're seeing? |
|
I am down scaling the 4k primary stream on some reolink cameras so keep in mind it is reolink + a 7th gen intel iGPU, however i was not seeing any errors on the ffmpeg 7 builds for days.. I get these about every 5hrs plus wiht the ffmpeg 8 builds.. Mostly this one camera, so it is most likely this camera or the older intel hardware acceleration just not being very stable. |
|
Regarding the ffmpeg 8.0 upgrade in recent versions: I've been running ffmpeg version n8.1.1-20260509 using the custom-ffmpeg settings for a couple of weeks now. Its been solid, and I haven't had any stream/decode issues outside of the ordinary for wifi cameras. I did notice less memory leaks/crashes of ffmpeg, which is why i switched. |
|
Just a though, when using motion search false motion events from color to IR mode and from encoding errors "green flash" are more apparent. IR changes happen twice a day and encoding errors are a bit more prevalent in wifi cameras where connections may interrupt. I am wondering as part of motion search or in motion detection general if there could be an option to filter or ignore these events? Apparently the green flash is ffmpeg filling in 0s for Y,U,V color space. I wonder if the that could be clearly detected and ignored? As for color to black IR mode the signal / stream is still color but I would expect a IR / BW image would have a very specific color value set and be devoid of some values.. A switch between them over 2-3 frames should be detectable? |
|
The tricky part is that motion detection (and motion search) only ever looks at the luminance/grayscale channel. Color is discarded before any of it runs, so we can't detect by the green hue or by "color vs. BW,". Both artifacts really just show up as a near-whole-frame brightness change. Additionally, every camera behaves differently. IR transitions vary a lot between models (as I have seen on my own cameras), and the encoding "green flash" is really a flaky-connection symptom that some cameras show and others never do (I never see that on my own cameras). So there's no consistent signature to key off of. And motion search only analyzes the ROI you draw, not the full image, so a real object can easily fill that whole region (someone walking up to a doorbell cam, a car pulling into a small driveway zone, etc.). That means a 100% change in the ROI is exactly what a legitimate close-up event looks like too, and we'd have no reliable way to tell it apart from an IR switch or a flash. We'd risk dropping real motion to suppress a couple of extra entries in the search results. So this isn't something I'd be looking to try to implement. |
|
Is there a way to separate the startup lag from the enrichment statistics, or at least retest when the system has stabilised? For example, I have a car in view of one of my cameras with a licence plate. Plate recognition takes anywhere up to 22000ms after Frigate starts and stays at that figure until another car and plate is detected or the original car moves. This may take hours. Other enrichment stats may also take a while to decrease to their accurate post-startup timings which makes the enrichment stats look bad (red) for a long time. Perhaps a manual refresh button to trigger a reevaluation would help (not just a screen refresh)? |
Yes - Intel UHD 630 with i5-8400 on this Dev system - and small model as default in a new install. I took a look at the referenced site (https://onnxruntime.ai/docs/execution-providers) which says that CPU is the default. So does Frigate try to run this on GPU if available? |
|
No, Frigate will use CPU by default if you don't specify a But as @NickM-27 indicated, the LPR models are dynamic-shape models, and OpenVINO doesn't do well on cold starts with dynamic shape models. CUDA and ROCm are quite different in that respect. In my own testing and from reports of other users, LPR doesn't generally benefit from being run on an iGPU - after the warm up, inference time is pretty equal to the CPU. |
|
I hadn't specified a |
|
Reading the docs, I see that the |
|
Actually, that's my mistake - Frigate doesn't set a value for the frigate/frigate/config/classification.py Line 401 in ad968ef |
|
There are currently too many audio types supported in Audio Detection, while only a handful are commonly used. I don’t think it’s a good experience to expect users to search for the audio types they want on their own. As I suggested before, it would be better to manually curate and place the commonly used audio types at the front. Having users look through options sorted strictly by name is not reasonable when dealing with such a large number of choices. |
I find the alarm sounds quite useful as it starts recording rooms with smoke detectors going off and makes it very easy to see if anything actually set them off or if it was a false positive as otherwise there would be no motion I also have crash / thud and a few others on my doorbell to capture events that might happen outside my current motion zones but worth investigating. I wouldn't presume which ones are worth while to everyone and search allows for the addition of more in the future. |
I am not asking to remove those labels. I’m not suggesting we strip flexibility from the project, nor do I think the search function is unnecessary. However, having over 500 audio types makes finding the commonly used ones a real burden for average users. That said, while everyone’s needs differ, we can establish a baseline: for home users, what are the most common requirements? We only need to list around ten frequently used options upfront. The rest should be collapsed by default, with the UI indicating how many additional labels are supported. Importantly, this collapse would not affect the search functionality. |
That is also an incorrect baseline... Based on various threads, frigate is used by farmers, and small businesses.. All of which have different needs. As an alternative maybe it could be possible to group the sounds in some way? making it easier to find common ones? |
|
I added a section to the docs: https://misc-fixes.frigate.pages.dev/configuration/audio_detectors#common-audio-labels |
Categorization is one approach, but it comes with relatively high maintenance costs. As noted in the current documentation, most audio types aren’t practical, and only a few are recommended. https://docs.frigate.video/configuration/audio_detectors/#configuring-audio-events
Moreover, this only affects the default display and doesn’t prevent users from viewing all options later. Everyone has their own specific needs, but honestly—even if the default options don’t fully meet my requirements—I still don’t want to face over 500 labels every time I open the settings. |
|
Does restarting the detection process also restart the classification process? I’m currently encountering an issue where, after the watchdog detects that the detection process is frozen and restarts it to restore normal operation, the classification process stops working properly and fails to recognize new content. |
|
They are completely different processes that operate independently of each other. If the embeddings maintainer crashes, Frigate will restart it and you will see a message in the logs. |
|
Yes, I understand that, but the current issue is that after the detection process restarts, the classification process is still running, yet it no longer performs any work. I suspect something in the pipeline may have been interrupted. |
|
The "classification process" is the embeddings maintainer, which is responsible for all of Frigate's enrichments, not just classification. Are all enrichments no longer functioning? |
Nope. But I noticed that in debug mode, the camera feed appears completely frozen, and the resolution is extremely low—nothing like the usual debug mode resolution. At the same time, the State Classification detector runs normally and produces new recognition results, but both Object Classification and facial recognition are stuck. I believe this is still related to the camera detector process freezing, as there are indeed plenty of relevant warning logs pointing to that. |
|
It seems like the detection hardware failure is causing a cascading issue on your system. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Frigate 0.18 includes many new features, some of which require additional feedback to ensure a smooth user experience. Frigate 0.18 is still under active development and is not recommended for use in production systems (there may be large / breaking bugs).
As we get closer to a beta cycle we are looking to get additional feedback from users in some specific areas so that we may get a better understanding of how things are working and fix any bugs.
We are currently looking for feedback on the following features, all other feedback will be ignored for the time being. If you test any of the following, please leave a note even if it just says that things are working well.
If you experience any bugs with config migration, or bugs with existing 0.17 functionality then please give that feedback as well.
When providing feedback please do so in this discussion, if a new discussion must be created then use the
Beta Supportcategory notBugThe docs are: https://docs-dev.frigate.video/
Note that docs links in the UI in
devbuilds point to the stable docs hostname and may lead to an outdated page or 404s. You can manually add-devto the hostname for the correct link. For example:https://docs.frigate.video/configuration/genai/configbecomeshttps://docs-dev.frigate.video/configuration/genai/configProfiles
Profiles let you define named overrides on top of your base camera configuration and switch between them on the fly — without restarting Frigate. Profiles can override a camera's detection, motion, recording, snapshots, review, zones, notifications, objects (including masks and filters), enrichments (face recognition, LPR), audio, and birdseye settings, as well as the camera's enabled state.
frigate/profile/setMQTT topic.See the documentation.
Motion Review and Motion Search
Frigate 0.18 introduces a redesigned Motion Review experience along with a new Motion Search feature.
See the documentation.
Exports
Frigate 0.18 brings substantial improvements to exports.
Case Management
Exports can now be organized into named cases, making it much easier to manage exports related to a single incident or investigation.
Custom Exports
Frigate 0.18 provides a dedicated exports API that accepts arbitrary ffmpeg arguments, allowing for fully custom export pipelines (custom filters, encoders, output formats, and so on). A CPU fallback path is automatically used if hardware-accelerated encoding fails. For security, custom ffmpeg arguments are restricted for non-admin users and a number of dangerous flags (such as
-filter_complex,-vf, and-attach) are blocklisted to prevent arbitrary file reads via filter sources.In addition, exports now use Frigate's
Jobinfrastructure end-to-end, providing more reliable progress reporting and better cleanup of interrupted jobs. Per-camerarecord.export.hwaccel_argssettings cascade up through camera and global configuration, allowing per-camera tuning of export hardware acceleration. See the recording documentation for export configuration details.Config UI
Frigate 0.18 introduces complete UI-based configuration management. The new Settings experience provides:
Please provide any feedback on the above aspects of the Settings UI. One suggested testing method would be to set up a fresh instance of
devto match your existing stable instance's configuration by exclusively using the Settings UI.All reactions