0.18.0 Beta 1

[blakeblackshear]

Images

• ghcr.io/blakeblackshear/frigate:0.18.0-beta1
• ghcr.io/blakeblackshear/frigate:0.18.0-beta1-standard-arm64
• ghcr.io/blakeblackshear/frigate:0.18.0-beta1-tensorrt
• ghcr.io/blakeblackshear/frigate:0.18.0-beta1-rk
• ghcr.io/blakeblackshear/frigate:0.18.0-beta1-rocm
• ghcr.io/blakeblackshear/frigate:0.18.0-beta1-tensorrt-jp6
• ghcr.io/blakeblackshear/frigate:0.18.0-beta1-synaptics

Major Changes for 0.18.0

Breaking Changes

There are several breaking changes in this release, Frigate will attempt to update the configuration automatically. In some cases manual changes may be required. It is always recommended to back up your current config and database before upgrading:

1. Simply copy your current config file to a new location
2. Stop Frigate and make a copy of the frigate.db file

• GenAI now supports multiple providers. As a result, the global genai config is now a mapping of keys to GenAI provider setups, and a new roles field defines what tasks each provider will be used for (object descriptions, review summaries, embeddings, chat, etc.). Existing configs will be automatically migrated. Documentation
• Frigate no longer saves annotated JPEG snapshots (.jpg) to disk. Only a clean, unannotated WebP snapshot (<camera>-<id>-clean.webp) is now stored in /media/frigate/clips/. The clean_copy configuration option has been removed — clean snapshots are always saved when snapshots are enabled. The snapshots.quality default has changed from 70 to 60, reflecting the switch from JPEG to WebP encoding. Users who previously relied on the annotated .jpg files on disk should instead use the /api/events/<id>/snapshot.jpg endpoint, which now honors timestamp, bounding_box, crop, height, and quality query parameters for both in-progress and completed tracked objects. When query parameters are omitted, the camera's snapshots config values are used as defaults. Existing configs containing clean_copy will be automatically migrated. Documentation
• The config format for zones and masks has changed to add enabled and friendly_name fields. A config migrator will make the necessary changes, but if migration fails you may need to edit your masks and zones manually.
• Intel GPU stats reporting has changed to no longer require intel_gpu_top and now reads directly from the kernel's per-client DRM usage counters. This removes the need for CAP_PERFMON, privileged mode, or perf_event_paranoid tuning, and adds support for newer Intel GPUs (including Battlemage). Reported usage values may differ from previous versions because the measurement method has changed; the underlying GPU workload is unchanged for the same configuration.
• FFmpeg has been updated to version 8.
  • FFmpeg 5 is deprecated and will be removed from Frigate in 0.19.
  • FFmpeg 8 introduces a known issue with go2rtc streams that transcode video using hardware acceleration. A small change to the go2rtc config is required. Documentation
• The /api/export DELETE HTTP API endpoint has been removed and refactored to support bulk deletion of exports. A POST to /api/exports should be used instead. Documentation
• The sync_recordings config option has been removed and replaced by the new Media Sync pane in Settings.
• The timelapse_args export config option has been removed and replaced by custom exporting ffmpeg arguments. Documentation
• The ui.date_format and ui.time_format config options have been removed as these fields have been unused since date/time format and handling has been determined by i18n.

New Features

Frigate 0.18 introduces several major new features.

Full UI Configuration

Frigate 0.18 introduces complete UI-based configuration management. The new Settings experience provides:

• A categorized sidebar covering every section of the config (cameras, detectors, motion, recording, review, GenAI, semantic search, face recognition, LPR, classification models, networking, authentication, and more).
• Per-field validation, inline descriptions, and links back to the documentation.
• A clear distinction between global and camera-level configuration, with the ability to override global values per camera and reset back to defaults at any time.
• Highlighting of unsaved changes, a "Save All" button that summarizes pending edits across sections, and a Reset to Default/Global button on each section.
• Indicators showing which fields require a restart to take effect, with a one-click restart prompt when a restart-required field is changed.
• Most of Frigate's configuration options can now be saved and applied dynamically without restarting, including most enrichment, motion, ONVIF, GenAI, and go2rtc stream settings.
• Manual YAML file configuration is still fully supported. Documentation pages now include "Frigate UI" tabs alongside YAML examples to show exactly where each option lives in the new Settings UI.

See the documentation.

Profiles

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.

• Profiles are defined at the top level of the config with optional friendly names, and per-camera overrides are defined under each camera.
• The active profile is persisted across restarts and can be changed from the UI or via the frigate/profile/set MQTT topic.
• The current profile state and the list of available profiles are published over MQTT.
• The Settings UI shows which fields are overridden by the active profile, supports editing the base config independently from any profile, and provides per-profile camera enable/disable from the camera management view.
• A dedicated Profiles page in the main menu shows a card-based summary of all configured profiles and their overrides.

See the documentation.

GenAI

Frigate 0.18 includes a major expansion of GenAI capabilities. In addition to multi-provider support (see Breaking Changes), there is a new dedicated llama.cpp provider with automatic model probing and context sizing, and GenAI configuration can now be updated dynamically without restarting Frigate.

See the documentation.

Chat

Frigate 0.18 introduces a Chat interface for talking to your configured GenAI provider directly from the Frigate UI. Chat is implemented as a tool-calling LLM agent with access to Frigate-specific tools, so you can ask natural language questions about your cameras, tracked objects, and review activity.

• Streaming responses with markdown support (including tables), per-message copy buttons, message editing, and the ability to stop a streaming response.
• Tool calls are grouped and displayed inline as the agent works, with quick links to relevant tracked objects and review items.
• Tools include searching tracked objects, finding similar objects via semantic search, inspecting live camera context, toggling camera features, starting VLM monitoring on a camera, and a recap tool for summarizing recent activity.
• Tracked object thumbnails and similarity results render as cards in the chat, and any event can be attached to a chat message via the paperclip button or by clicking a thumbnail.
• A persistent quick-replies row makes it easy to start common queries from a fresh chat.

Remote Embeddings

Semantic Search embeddings can now be generated by an external GenAI provider instead of running locally. This is especially useful when you would prefer to offload embedding work to another machine or to a hosted provider.

• Any configured GenAI provider that supports an embeddings endpoint can be selected as the embedding provider for Semantic Search.
• The semantic search settings UI includes a dropdown for choosing which configured GenAI provider should produce embeddings.

See the documentation.

Motion Review and Motion Search

Frigate 0.18 introduces a redesigned Motion Review experience along with a new Motion Search feature.

• Motion Search. A new motion search workflow lets you draw or select a region on a camera image and find time periods where motion occurred in that area, similar to a motion-based version of object review.
• Motion previews. Motion preview clips are generated and shown directly in the review pane, quickly highlighting areas of motion in the frame where Frigate did not detect and track any objects.
• Heatmap filter. A heatmap-grid filter on the motion review page lets you constrain motion previews to specific regions of the camera image.

See the documentation.

Debug Replay

Debug Replay is a new tool that lets you replay recorded video through Frigate's detection and motion pipelines as if it were a live camera. This makes it dramatically easier to tune motion settings and object filters against real footage rather than waiting for live activity to reproduce an issue.

• Configure the debug replay camera directly in the UI without manually editing your configuration.
• Adjust motion and object detection configuration on the replay camera and see the effect on detections in real time.
• The Debug view's overlays (regions, motion, paths, zones) are fully supported during replay.

See the documentation.

Exports

Frigate 0.18 brings substantial improvements to exports, including fast multi-camera exporting from History, single-click exporting of multiple review items in Review, and more.

See the exports documentation.

Case Management

Exports can now be organized into named cases, making it much easier to manage exports related to a single incident or investigation.

• Cases are displayed separately from individual exports in the UI and can be filtered, edited, and deleted.
• Exports can be assigned to a case at creation time (including from the single-camera and mobile review export dialogs) or moved between cases later.
• Bulk selection (similar to the Review page) supports reassigning or deleting multiple exports across cases at once, with admin-only actions properly gated.
• New cases can be created directly from any export dialog, and exports can be removed from a case without deleting them.
• Stale or interrupted in-progress exports are reaped automatically on startup.

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 Job infrastructure end-to-end, providing more reliable progress reporting and better cleanup of interrupted jobs. Per-camera record.export.hwaccel_args settings cascade up through camera and global configuration, allowing per-camera tuning of export hardware acceleration. See the recording documentation for export configuration details.

Other Improvements

There are many other improvements to highlight in this release.

Backend

• Masks and zones can now be dynamically enabled and disabled via MQTT. Documentation
• Camera enabled, detect, record, snapshots, and audio toggles now persist across Frigate restarts.
• Added support for the AXERA AI accelerator. Documentation
• Nvidia 50 series GPUs are now supported following an upgrade of CUDA and ONNX Runtime dependencies. As part of this change, the CUDA version was tuned to avoid overaggressive BFC behavior on these cards.
• The Intel drivers have been updated to support Battlemage GPUs.
• There is now a dedicated llama.cpp GenAI provider with automatic model probing and context sizing. Documentation
• Custom (API-created) events can now be configured as detections or alerts based on the event label, can run indefinitely until explicitly ended, and support a configurable pre_capture value when created.
• ROCm has been updated to 7.2.0 and now supports RDNA4 AMD GPUs. JinaV1 also works correctly under the new ROCm. Documentation
• Added VLM monitoring, which runs a configured GenAI provider in a loop against a camera's live view to power chat-driven workflows.
• ONVIF support has been refactored to add profile selection, decouple relative move from autotracking, and dynamically update ONVIF configuration without a restart. Documentation
• A new generic process watchdog auto-restarts subprocesses that crash or stall.
• The license plate detection box coordinates are now published in tracked_object_update MQTT messages. Documentation
• A new frigate/<camera>/<role>/status topic and a stopped value on the LWT topic make it easier to monitor camera health and Frigate availability. Documentation
• Configurable listening ports via the networking config section for advanced use cases. Documentation
• New /api/recordings endpoints for deleting recordings, syncing media (replacing the old scheduled sync_recordings cleanup), and pulling review clips by review item ID.
• Snapshot responses now include an X-Frame-Time header.
• Frigate+ API calls now run in a thread pool to avoid blocking the event loop.
• API performance improvements for several recording related endpoints.
• ffmpeg has been updated to 8.1.1, and go2rtc to v1.9.14.
• HTTP/2 support has been enabled in nginx. Users who access Frigate over port 8971 instead of port 5000 may see a significant performance improvement in Live and History view, especially if their installation has more than a couple of cameras.
• Face recognition optimizations to increase accuracy and reject poor candidates.
• Many internal type-safety improvements and a significant increase in mypy coverage across the codebase.
• A number of security hardening fixes around authentication, role enforcement, custom export ffmpeg arguments, and SQL parameterization.

Frontend

• There is a new Media Sync function which allows checking for orphaned files which can be deleted directly from the UI. A verbose mode writes a per-media-type report of orphaned paths to /config/media_sync. Documentation
• A new camera connection quality indicator is shown on the camera metrics page, making it easy to see when cameras are having connection issues.
• Greatly improved the efficiency of metrics loading and rendering, including hiding rather than unmounting graphs when switching tabs.
• The Classification Wizard now allows regenerating examples in cases where the images are not representative of all scenarios, and supports reclassifying both images and faces after training.
• The system metrics page now shows GPU and NPU temperatures (Nvidia, Rockchip, Hailo, and others where available).
• A new Messages tab in the Logs section and Debug Replay shows the messages exchanged between Frigate's backend and the frontend/MQTT.
• Preview generation has improved, with smoother transitions between hours and a new qmax parameter for higher-quality previews at high and very_high settings.
• Cameras can now be deleted directly from the UI, with full cleanup of associated media.
• Instant snapshots can now be downloaded directly from the controls in History view.
• The Tracking Details pane now shows additional scoring information including computed and top scores per timeline entry.
• The motion and object debug overlays now match between Debug view and Replay objects lists, and area is shown as a proper percentage.
• Camera group and streaming settings are now saved to the browser local storage separately for each user.
• The frontend has been migrated to React 19, with corresponding upgrades across the dependency tree (framer-motion, react-konva, react-grid-layout, vaul, sonner, and others).
• The WebSocket layer has been rewritten on top of useSyncExternalStore for finer-grained, per-topic subscriptions and significantly fewer unnecessary re-renders.
• Many fixes around mobile usability, including export crash fixes on iOS, viewport scaling tweaks, and improved drawer/dialog behavior.
• New translations and substantial improvements to existing translations across many languages, including a new i18n key check in CI to keep translations in sync.
• Many small UX improvements and tweaks.

---

This discussion was created from the release 0.18.0 Beta 1.

[bagobones]

Funny I have been running the dev builds and reading the full release notes there are still features or new options I haven't tried out.

[bagobones]

I think I am in trouble cost wise now (future local AI hardware or paying for tokens online).. AI chat is a whole new level of being able to search content.

You can ask questions like "Has Tom been seen today and what were they doing?"

You can ask "Who was in the Kitchen in the last hour?", and get get a nice summary.

It seems like a vastly quicker and more powerful way to query frigate.

[Matzebhv]

Holy sh*t, what a bunch of new features. Coming from 17.2 without any issue. Will try everything out the next days.

[gavdotcom]

Thanks for all your hard work! I will definitely update soon and check out all the new features!

[thewan056]

I am seeing increased overall CPU usage of about 10% from the update. Based on the metrics page, and the warning on the bottom right which I have not seen before the update, the increased CPU usage comes from FFmpeg. I assume this is because of the the updated FFmpeg version. Is this expected?

[hawkeye217]

See the breaking changes in the release notes.

Intel GPU stats reporting has changed to no longer require intel_gpu_top and now reads directly from the kernel's per-client DRM usage counters. This removes the need for CAP_PERFMON, privileged mode, or perf_event_paranoid tuning, and adds support for newer Intel GPUs (including Battlemage). Reported usage values may differ from previous versions because the measurement method has changed; the underlying GPU workload is unchanged for the same configuration.

How do you have Frigate installed?

[nacree]

This is what I noticed yes. I'm running Frigate with Docker Compose. Didn't do any changes in the docker or config file. I assume that the GPU percentage is supposed to be in the same place as before?

[hawkeye217]

Yes. Do you see any errors in the Frigate log? What kernel version is your host running?

[nacree]

Indeed found after reboot

Unable to collect Intel GPU stats: no DRM fdinfo entries found. Check that /proc is readable and the i915/xe driver is loaded

Intel(R) N100 / Intel Alderlake_n (Gen12)

[    4.283509] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/adlp_dmc_ver2_16.bin (v2.16)

Linux grus 6.1.0-49-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.174-1 (2026-05-26) x86_64 GNU/Linux

nacre@grus:/home/frigate$ sudo lspci -v -s 00:02.0
00:02.0 VGA compatible controller: Intel Corporation Alder Lake-N [UHD Graphics] (prog-if 00 [VGA controller])
        DeviceName: Onboard - Video
        Subsystem: Intel Corporation Alder Lake-N [UHD Graphics]
        Flags: bus master, fast devsel, latency 0, IRQ 128, IOMMU group 0
        Memory at 6000000000 (64-bit, non-prefetchable) [size=16M]
        Memory at 4000000000 (64-bit, prefetchable) [size=256M]
        I/O ports at 4000 [size=64]
        Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
        Capabilities: [40] Vendor Specific Information: Len=0c <?>
        Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
        Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable+ 64bit-
        Capabilities: [d0] Power Management version 2
        Capabilities: [100] Process Address Space ID (PASID)
        Capabilities: [200] Address Translation Service (ATS)
        Capabilities: [300] Page Request Interface (PRI)
        Capabilities: [320] Single Root I/O Virtualization (SR-IOV)
        Kernel driver in use: i915
        Kernel modules: i915

I'm running docker in privileged mode and adding mapping for /proc didn't help.

[hawkeye217]

Right, this is due to your kernel version. Version 6.5 or higher is required. This is something we just learned during the beta period, so it will be in the beta 2 release notes. I've also added an entry in the FAQ here: #23689

[niffelheimba]

My admin users were recognized as admins just fine on 0.17.2 with forward auth; on update to the beta, they are no longer recognized as admins, just normal viewers. Anything specific in 0.18 that would've caused it I should look for? Also, logging out w/ forward auth enabled shows the built-in auth, although it does not work.

[hawkeye217]

There were a few changes to the auth subsystem. You'll want to enable debug logs to see what headers Frigate is receiving from your proxy.

logger:
  default: info
  logs:
    frigate.api.auth: debug

[loryanstrant]

Loving the multi-provider GenAI work in 0.18, thank you!
(the below was AI-generated, but with a lot of me peering under the hood and trying a bunch of things myself, I just had Claude validate my thinking and then write it up in a way that might be understood by devs, as I'm certainly not one)

Semantic Search remote embeddings currently only work with llamacpp, not "any provider with an embeddings endpoint"

One gap worth flagging: the release notes and the Semantic Search docs say any configured GenAI provider with the embeddings role can back Semantic Search, but in practice only the llamacpp provider actually implements it.

In frigate/genai/plugins/, embed() is defined only in llama_cpp.py — openai.py, azure-openai.py, gemini.py, and ollama.py all fall through to the base GenAIClient.embed(), which just logs "does not support embeddings" and returns []. So configuring provider: openai (or ollama) with roles: [embeddings] validates fine but silently produces no embeddings — which is a confusing failure mode.

The llamacpp provider also speaks llama.cpp's native HTTP protocol rather than the OpenAI embeddings API:

• it reads a media marker from GET /props, and
• it POSTs to /embeddings with {"model": ..., "content": [{"prompt_string": "..."}]} (and multimodal_data for images), expecting {"data": [{"embedding": [...]}]} back.

Testing against a LocalAI instance (OpenAI-compatible):

GET /props -> 404
POST /embeddings {"content":[{...}]} -> 200 but no data (content ignored)
POST /v1/embeddings {"input":["a red car"]} -> 200 with a real embedding

So neither provider: openai (no embed()) nor provider: llamacpp pointed at an OpenAI-compatible server (wrong protocol) can use it.

Request: would you consider supporting the OpenAI-compatible /v1/embeddings endpoint for the embeddings role (in the openai/ollama providers)? A lot of us already run embedding models in LocalAI or Ollama behind an OpenAI-compatible API — including multimodal/CLIP-style models that some of these servers can serve for both text and image embeddings. Being able to point the embeddings role at /v1/embeddings would let those existing deployments back Semantic Search directly, without standing up a separate llama.cpp server, and would keep remote embeddings from being tied to llama.cpp specifically.

Even text-only /v1/embeddings support would be valuable on its own (it already covers description-based search); multimodal could be handled by servers that expose it. Happy to help test against LocalAI/Ollama if useful.

[NickM-27]

would you consider supporting the OpenAI-compatible /v1/embeddings endpoint for the embeddings role (in the openai/ollama providers)?

This only supports text embedding, not image embedding, so it is not compatible. Unlike what your AI said, this is not valuable. The embedding models must have images and text shared within the same semantic space for the semantic search to work correctly

[SigHunter]

thanks a lot!
the header lists the wrong tensorrt image name, it should be "ghcr.io/blakeblackshear/frigate:0.18.0-beta1-tensorrt"

[hawkeye217]

The actual link is correct but the actual text had -beta1 in the wrong place. I've corrected it.

[ZhaiSoul]

Is the image address written incorrectly? Currently it's written as ghcr.io/blakeblackshear/frigate:0.18.0-synaptics-beta1, but the correct one is actually ghcr.io/blakeblackshear/frigate:0.18.0-beta1-synaptics.

[hawkeye217]

The actual link is correct but the actual text had -beta1 in the wrong place. I've corrected it.

[silent817]

Changes list is huge, and interesting ones.
AX8850N is now supported but requires model download, so it's not compatible with Frigate+ model? Any chances it will be in future or it's limited and not worth the hassle?

[hawkeye217]

No, it's not currently compatible with Frigate+. Future support would be a question for @blakeblackshear

[cvroque]

Just updated the "app" on HA from 0.17.2 to 0.18, zero configuration changes and everything is working as usual, really great experience so far.

[Mincka]

Could you give examples of things that would be broken by "Frigate no longer saves annotated JPEG snapshots (.jpg) to disk."?

What do you mean by "Users who previously relied on the annotated .jpg files on disk"?

I use things like this in HA automation and scripts and I would like to understand if it'll break or not:

clickAction: https://xxx/api/frigate/notifications/{{id}}/snapshot.jpg
image: /api/frigate/notifications/{{id}}/snapshot.jpg

or

image: "{% if type == \"end\" -%}\n  {{undefined}}\n{%- else -%}\n  https://xxx/api/frigate/notifications/{{events[0]}}/snapshot.jpg?bbox=1\n{%-
  endif %}"
video: "{% if type == \"end\" -%}\n  https://xxx/api/frigate/notifications/{{id}}/review_preview.gif?format=ts\n{%-
  else -%}\n  {{undefined}}\n{%- endif %}"

or in script

curl "https://xxx/api/frigate/notifications/$1/snapshot.jpg" -o /config/www/snapshots/$1_snapshot.jpg
curl "https://xxx/api/frigate/notifications/$1/thumbnail.jpg?format=android" -o /config/www/snapshots/$1_thumbnail.jpg

Thank you!

[hawkeye217]

Users who manually accessed the files in /media/frigate would be affected by the change. The examples you gave are all pulling from API endpoints, so you are completely unaffected.

[Mincka]

Thank you for the quick confirmation!

[zeroflow]

Thanks for the update - great work!

So far, it's been running great on two Systems (Core 5 Ultra 125H and N300)
I may have found a small issue with the configuration override for objects in the camera config.

The UI reports the same for every camera:

This camera overrides 3 fields from the global config:
Objects to track
School Bus · Object filters
Motorcycle · Object filters

In the camera config, I have no overrides for objects configured:

  Wohnzimmer: # --------------------------------------------------
    enabled: true
    live:
      streams:
        Preview: Wohnzimmer_sub
        Main: Wohnzimmer
    ffmpeg:
      inputs:
        - path: rtsp://127.0.0.1:8554/Wohnzimmer
          input_args: preset-rtsp-restream
          roles:
            - record
            - detect
    onvif:
      host: 192.168.5.xx
      port: 2020
      user: <redacted>
      password: <redacted>
    detect:
      enabled: true
    notifications:
      enabled: true
    zones:
      Main:
        coordinates: 0,0.158,1,0.143,1,1,0,1
        loitering_time: 0
        inertia: 3
    motion:
      threshold: 30
      contour_area: 10
      improve_contrast: true

Am I interpreting this wrong?

[zeroflow]

I use the frigate plus 2026.1, so both labels should be supported.

I checked my settings, and the only part where school_bus was present was under the global objects: track: config path.
Removing it there did remove the override warnings on each camera.

"Objects to Track" in the UI still offers to add these two objects back into the config.
Adding them via the UI toggles of course brings them back into the warning regarding being overridden:

But thats not how I understood how overrides show up. My understanding is, that the override mark should show up, e.g. if I have a global recording retention time of 14d and set one camera to

[hawkeye217]

Can you post your full config?

[hawkeye217]

If you have Motorcycle and School Bus in the list of objects to track for a camera but you do not have it set up in the global list of objects to track, then the override message is correct. You are overriding at the camera level what is set at the global level.

But if that's not how you have it set up, there may be a bug somewhere. Seeing your full config will confirm.

[hawkeye217]

I made a change in #23718 that should correct your issue. After it's merged, it would be super helpful if you could grab the latest build, test, and report if it's fixed.

[zeroflow]

I can confirm, Version a8eca68-amd64 fixes this display issue.
Thank you!

[Mincka]

Motion Search and Debug replay are very useful!

Is it possible to control the playback of Debug replay? I don't see any control.
I see it's looping but I'd like at least to be able to pause and zoom.
It can be hard to catch what's going on with multiple objects overlapping in a short time frame.

[hawkeye217]

No. Debug Replay is just like Debug view but with a video clip instead of a live camera. You can't pause or rewind.

You can use the filters in the Messages pane to help filter out specific messages, or use the configuration button to change which objects are being tracked.

See the official docs: https://docs-dev.frigate.video/troubleshooting/dummy-camera/#debug-replay

[xconverge]

Just wanted to +1 to say debug replay is AWESOME

[bagobones]

If you edit the friendly name of a zone to something substantially different than its existing ID it will change the ID.

I don't think in any situation I would want an existing ID to change, only when creating a new zone would I would it generated / changed without me explicit changing it.

I was cleaning up my zone name at first I didn't notice as changing "front_walk"to have a friendly name of "front walk" did not change the ID

But when I went to change the overly short rec_tv to rec room tv it started completely updating replacing the ID.

[hawkeye217]

Changes are in #23709. If you could test the build after it's merged and report back, that'd be great.

[bagobones]

Changes are in #23709. If you could test the build after it's merged and report back, that'd be great.

Reading though the change

"Delete all references to a zone in config wide required_zones when a zone itself is deleted from the UI"

This might be problematic if the same zone name has been used on multiple cameras?

There has been a bit of back and forth over the various versions if it is bad from to say have front yard and driveway the same name on two cameras over overlapping coverage

I like to do it as search "front yard" gives me ALL events caught by both cameras.

[hawkeye217]

The delete for any of the required_zones fields is scoped to the camera, so no, it's not problematic. Deleting cam1's zone front_yard won't affect cam2's required zones.

[bagobones]

ok build 775ce22

The ID field appears to be clearly locked on any camera where the ID was used in required zones and stuff.

I still don't like that the ID is alway updated when I change the friendly name but I can live with it since it seem to only let it happen when not in use, it just means longer IDs sometimes than I want but that is not the worst.

The ID logic still seems kind of strange, like if I put a special character in the friendly name it suddenly becomes zone_a11107a0 however if I use all words and spaces I get a super long ID?

I would mostly just prefer it didn't force the change on an existing zone as there is recordings and events that will have the old ID and in the case I was just describing i just wanted the friendly name to be more friendly.

It is totally fine if that is how it is intended I just find it a bit odd and inconsistent.

I guess with the current logic I could just cludge a lock by making all of them required then if I ever change the friendly (don't really do that often) it could not change.

[hawkeye217]

Right, the logic is intended behavior.

To add clarity for other thread readers, the ID is the actual config key, so it's used in YAML, MQTT topics, and the API, and it's restricted to letters, numbers, underscores, and hyphens.

cameras:
  driveway:
    ...
    zones:
      my beautiful wife's car zone!!!!: # this is an invalid YAML key
        friendly_name: My Beautiful Wife's Car Zone!!!
        coordinates: ...

When you type a name, the UI derives the ID from it. It stays lowercase, and spaces become underscores. If the result is a valid key, it's used as-is, which is why a long friendly name gives a long ID. If the name contains any character that can't go in a key (punctuation, emoji, non-ASCII), there's no clean way to slugify it, so it falls back to a deterministic hash of the name, which is where something like zone_a11107a0 comes from. The same name always hashes to the same ID.

After the change that was merged, if an ID is used elsewhere in the camera's configuration for required_zones, the ID will remain un-editable in the UI.

It can always be tweaked manually in YAML, of course.

The ID tracks the name while editing so the two don't silently drift apart for people who never look at the ID field. But it's only a suggested default: click "Show ID" and you can edit the ID directly, and it will keep whatever you set unless you change the name again afterward. So for OP's case, set the friendly name first, then put the ID back to the old value before saving. No need for the required_zones lock workaround.

[ZhaiSoul]

Shouldn't the Chat prompt include a mapping between the Zone ID and  friendly_name ? Right now, it's only using the ID, not the friendly name.

[NickM-27]

Currently it seems it is only given the IDs, will tweak

[ZhaiSoul]

By the way, could the Chat prompt explicitly specify that semantic search only supports English queries when the Jina v1 model is selected? This will prevent non-English users from inadvertently invoking the tool with their local language, which would lead to failed or inaccurate results.

[NickM-27]

that's a good call out, will make that change

[bagobones]

And here I thought it was just because I had not set any friendly names yet.

[bagobones]

I am currently using Openrouter for model testing and I noticed frigate shows as an unknown application however all calls are easily tracked by API key.

I wonder if it could be "optional" to enable a user agent header with Frigate. or optional that additional headers could be set on API calls.

https://openrouter.ai/docs/app-attribution

Could add additional exposure to the project https://openrouter.ai/apps

I plan to switch to fully local in the future but something I did notice when using Openrouter, I am also testing Home Assistant with openrouter and the integration for HA sends the app headers.

[YBonline]

I upgraded to the latest build - 53c8aa2-tensorrt - to confirm its still there, but when I select a camera, history, actions, export, select multicamera, after all my cameras load showing the activity, and then I click on the search box, and instantly the UI seems to crash, becomes fully blank screen (but no crash screen). In dev tools console, I see this:

main-zDirkHcg.js:82 Warning: Missing `Description` or `aria-describedby={undefined}` for {DialogContent}.
(anonymous) @ main-zDirkHcg.js:82
index-10m4Vzny.js:48 Uncaught Error: Minified React error #130; visit https://react.dev/errors/130?args[]=undefined&args[]= for the full message or use the non-minified dev environment for full errors and additional helpful warnings.
    at Gd (index-10m4Vzny.js:48:30005)
    at Ge (index-10m4Vzny.js:48:42819)
    at index-10m4Vzny.js:48:43719
    at _r (index-10m4Vzny.js:48:67630)
    at Ah (index-10m4Vzny.js:48:71186)
    at k0 (index-10m4Vzny.js:48:81452)
    at V0 (index-10m4Vzny.js:48:117261)
    at Rp (index-10m4Vzny.js:48:116307)
    at a1 (index-10m4Vzny.js:48:116137)
    at E0 (index-10m4Vzny.js:48:112923)
index-10m4Vzny.js:83 WebSocket connection to 'wss://cctv.removed.com/ws' failed: Received a broken close frame containing a reserved status code.

[hawkeye217]

Thanks, I found a small issue in the code that may have caused this. Can you paste the camera_groups section of your config? That will confirm or deny the cause.

[YBonline]

camera_groups:
  DI-588:
    order: 1
    icon: LuSailboat
    cameras:
      - di588_bay
      - di588_courtyard
      - di588_courtyard_doorbell
      - di588_driveway
      - di588_front_fisheye
      - di588_gate_doorbell
      - di588_north
      - di588_pool
      - di588_rooftop
      - di588_south
  GP_Clubhouse:
    order: 2
    icon: LuClub
    cameras:
      - gp_clubhouse_back_door
      - gp_clubhouse_banquet
      - gp_clubhouse_firepit
      - gp_clubhouse_front_door
      - gp_clubhouse_gym_1
      - gp_clubhouse_gym_2
      - gp_clubhouse_parking
      - gp_clubhouse_pool
      - gp_clubhouse_pool_porch
  Warehouse:
    order: 3
    icon: LuWarehouse
    cameras:
      - warehouse_exterior_doorbell
      - warehouse_exterior_front
      - warehouse_exterior_nw
      - warehouse_exterior_se
      - warehouse_exterior_sw
      - warehouse_interior_front
      - warehouse_interior_office
      - warehouse_interior_overview
      - warehouse_workbench
  GP_Outside:
    order: 4
    icon: LuCloud
    cameras:
      - gp525_doorbell
      - gp611_rear
      - gp607_doorbell
      - gp_bldg_03_side
      - gp_bldg_08_front
      - gp_bldg_08_rear
      - gp_entrance_75
      - gp_entrance_archer
      - gp_clubhouse_parking
      - gp_clubhouse_pool
      - gp_clubhouse_firepit
  Birdseye:
    order: 5
    icon: cat
    cameras:
      - birdseye
      - gp525_doorbell

[hawkeye217]

Thanks, that confirms the issue. I've made a change in #23725. Once it's merged, could you grab the latest dev build and test to make sure your issue is resolved?

A workaround in the meantime is to change the line icon: cat to a valid icon name like icon: LuCat.

[Plawasan]

I export short daily videos from my garden every day to combine them into a timelapse at the end of the year. I've updated the HA REST call syntax to the new API call and all works ok, until I add the export_case_id paremeter - when I call it, I call with simple "timelapse" value and I have a case defined with the same name:

  frigate_export_timelapse:
    url: "http://192.168.1.11:5000/api/export/custom/{{ camera }}/start/{{ start_ts }}/end/{{ end_ts }}"
    method: POST
    content_type: "application/json"
    payload: >-
      {
        "name": "{{ name }}",
        "export_case_id": "{{ case_id }}",
        "ffmpeg_output_args": "-vf setpts=PTS/{{ speed | default(60) }} -r {{ fps | default(25) }} -qp {{ qp | default(23) }}",
        "cpu_fallback": true
      }

This results in a 404:

"POST /api/export/custom/garden_camera/start/1784094600/end/1784095200 HTTP/1.1" 404 51 "-" "HomeAssistant/2026.7.2 aiohttp/3.14.1 Python/3.14" "-" request_time="0.010" upstream_response_time="0.007"

Am I doing something wrong or did I hit a bug? Without the export_case_id parameter defined, everything works as expected.

Thanks

[NickM-27]

The ID of a case is alphanumeric ID, not the name you gave it.

[Plawasan]

OK.. and where do I determine what it is? Didn't find anything in the docs...

[NickM-27]

https://docs-dev.frigate.video/integrations/api/get-export-cases-cases-get

[Plawasan]

Got it, it's working now. Thanks!

[Homas]

Great work and we finally got the most waited feature - profiles. Unfortunately it doesn't work with detections (looks like some bug) :(
I've base config which I can't change via UX/UI (when I click save settings are restored - looks as another bug) + at home and away profiles. Even if at home has 0 object detections and reduced number of audio detections I'm still getting these detections. The base config and away profile have these extra objects detections.

[hawkeye217]

You should open your own beta support discussion. Include your full config, a full copy of the logs, and the exact steps you perform to reproduce your issue.

[Homas]

Looks like it was due the object detections settings in the base profile. Once manually commented out the object detection settings at the base config profiles started working as expected. I reread the documentation it's not mentioned.

[hawkeye217]

If you could still open your own discussion, that would be helpful to trace down if there is an actual bug or just a misconfiguration.

[RutgerDiehard]

I've just switched Semantic search to the llama.cpp search provider configured in Settings -> Generative AI with the embedding role. llama.cpp server was started with the --embeddings option. The provider name was selected in the Settings -> Semantic Search Gen AI provider and clicked save. Frigate prompted a restart which was successful and I went back to Settings -> Semantic Search to check. The page now says there are unsaved changes:

Clicking "Save" results in a red "Error updating config" error.

[hawkeye217]

Thanks, this is fixed in #23763

When it is merged, please test the latest dev build and report back if you are able.

[hawkeye217]

Also, I noted from your logs that you may be trying to use an instruct model for embeddings. This isn't recommended. I'd suggest Qwen3-VL-Embedding instead.

[ZhaiSoul]

From the Chinese community: a user reported an error with face recognition.

2026-07-19 09:58:19.206206987  loading data from : /config/model_cache/facedet/landmarkdet.yaml
2026-07-19 09:58:19.209623754  Exception in thread embeddings_maintainer:
2026-07-19 09:58:19.209627462  Traceback (most recent call last):
2026-07-19 09:58:19.209629576    File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_inner
2026-07-19 09:58:19.209630947      self.run()
2026-07-19 09:58:19.209632772    File "/opt/frigate/frigate/embeddings/maintainer.py", line 290, in run
2026-07-19 09:58:19.209634197      self._process_updates()
2026-07-19 09:58:19.209636092    File "/opt/frigate/frigate/embeddings/maintainer.py", line 508, in _process_updates
2026-07-19 09:58:19.209637610      processor.process_frame(data, yuv_frame)
2026-07-19 09:58:19.209639474    File "/opt/frigate/frigate/data_processing/real_time/face.py", line 291, in process_frame
2026-07-19 09:58:19.209640967      res = self.recognizer.classify(face_frame)
2026-07-19 09:58:19.209642379            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2026-07-19 09:58:19.209644163    File "/opt/frigate/frigate/data_processing/common/face/model.py", line 415, in classify
2026-07-19 09:58:19.209645869      blur_reduction = self.get_blur_confidence_reduction(face_image)
2026-07-19 09:58:19.209647365                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2026-07-19 09:58:19.209649332    File "/opt/frigate/frigate/data_processing/common/face/model.py", line 121, in get_blur_confidence_reduction
2026-07-19 09:58:19.209650744      variance = cv2.Laplacian(input, cv2.CV_64F).var()
2026-07-19 09:58:19.209652087                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2026-07-19 09:58:19.209654314  cv2.error: OpenCV(4.11.0) /io/opencv/modules/imgproc/src/deriv.cpp:792: error: (-215:Assertion failed) !_src.empty() in function 'Laplacian'
2026-07-19 18:05:41.819773  2026-07-19 09:58:19.209655352
2026-07-19 09:58:19.213808322  [2026-07-19 17:58:19] frigate.embeddings             ERROR   : Embeddings maintainer thread exited unexpectedly
2026-07-19 09:58:23.059253848  [2026-07-19 17:58:23] frigate.watchdog               WARNING : Process embeddings (PID 1845125) exited with code 1

[ZhaiSoul]

By the way, does the Debug Replay feature support viewing the OCR pipeline for license plates? I’m still encountering cases where the plate is detected, but the OCR fails to recognize the characters.

[hawkeye217]

Thanks, this was already reported in #23732 and fixed in #23736

[hawkeye217]

s the Debug Replay feature support viewing the OCR pipeline for license plates? I’m still encountering cases where the plate is detected, but the OCR fails to recognize the characters.

Yes, Debug Replay acts exactly like a regular camera. See the official docs: https://docs-dev.frigate.video/troubleshooting/dummy-camera#debug-replay

[ZhaiSoul]

Yes, Debug Replay acts exactly like a regular camera.

To clarify, I’m hoping the debug UI can expose a more granular view of the OCR pipeline—for example, displaying each candidate image fed into the OCR engine, the corresponding recognition result, and the remaining retry count. Having to manually enable debug logs for the relevant modules and then monitor a separate terminal or log viewer alongside the main UI is far too cumbersome for efficient debugging.

[hawkeye217]

No, this is not supported. From the docs:

Debug Replay isn't intended to be a one-stop pane for all Frigate diagnostics or a comprehensive debugging environment for every Frigate feature. It merely makes it easier to spin up a "dummy camera" and perform some common adjustments in real time. You'll still need to use the normal tools (logs, an MQTT client, etc) to debug your feature.

[Hukuma1]

Is there a recommended way of doing a cropped cam? I had code working okay in stable and now it's giving me hiccups (feed loads, but feels like it doesn't have HWA).

I just want to crop a specific region and make it a feed into a generic camera I can call in Home Assistant.

  streams:
    bedroom:
      - ffmpeg:rtsp://USER:PASS@192.168.1.126:554/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif#video=copy#audio=opus
    bedroom_record:
      - rtsp://USER:PASS@192.168.1.126:554/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
    bedroom_detect:
      - rtsp://USER:PASS@192.168.1.126:554/cam/realmonitor?channel=1&subtype=1&unicast=true&proto=Onvif
    bedroom_zoomed:
      - ffmpeg:bedroom_record#video=h264#audio=copy#raw=-vf crop=800:600:1120:250

Previously the main bedroom stream didn't have ffmpeg in it, just rtsp. But I need it for WebRTC, correct? (opus instead of aac)

Or do I need to add a full standalone stream (like record, but not share it with record process) and then apply the ffmpeg crop command to it?

[hawkeye217]

Frigate uses MSE by default, not WebRTC, so unless you are looking to use a two-way talk feature with bedroom, the ffmpeg directive (and transcoding to opus audio) is not required. However, you could easily replace that with:

  streams:
    bedroom:
      - rtsp://USER:PASS@192.168.1.126:554/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
      - ffmpeg:bedroom#audio=opus
    ...

bedroom_detect is now a redundant stream. bedroom_zoomed looks fine for cropping.

You may want to use a custom go2rtc version or reach out on the go2rtc GitHub for additional help if you are still having issues.

[Hukuma1]

Thank you! But now I'm even more confused. When I did the setup via the new webUI setup Camera UI, it had me set a detect and record stream. So the main bedroom stream is the 2k untouched one. That's what I want to record as well.

So I should go back to my old config from stable? Like this is still recommended for Frigate? I did tick the box to limit connections to the camera, which I figured would be better. Is that what made the extra redundant stream? I am using Advanced Camera Card alongside Frigate to get the WebRTC streaming out via Home Assistant. (I originally did have the backchannel code etc in Bedroom for two-way talk, but scrapped it for the time being). This is what the majority of my stable code looks like. So I should migrate back to this?

  streams:
    driveway_main:
      - rtsp://USER:PASS@192.168.1.122:554/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
      - ffmpeg:driveway_main#audio=opus
    driveway_sub:
      - rtsp://USER:PASS@192.168.1.122:554/cam/realmonitor?channel=1&subtype=2&unicast=true&proto=Onvif

cameras:
  Frigate-Driveway:
    enabled: true
    ffmpeg:
      inputs:
        - path: rtsp://127.0.0.1:8554/driveway_main
          roles:
            - record
        - path: rtsp://127.0.0.1:8554/driveway_sub
          roles:
            - detect

[hawkeye217]

The Add Camera Wizard is a starting point for configuring a camera, and it can generate several different kinds of configurations based on the streams chosen and the switches that you enable. The first full config you posted above (with bedroom) is not something that the wizard could generate on its own.

The driveway config you posted is indeed a valid config as well as extremely similar to one that the wizard will generate, apart from the line to transcode to opus audio.

Back to the bedroom camera. Based on your original config, this would work just fine:

go2rtc:
  streams:
    bedroom:
      - rtsp://USER:PASS@192.168.1.126:554/cam/realmonitor?channel=1&subtype=1&unicast=true&proto=Onvif
      - ffmpeg:bedroom#audio=opus
    bedroom_sub:
      - rtsp://USER:PASS@192.168.1.126:554/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif
    bedroom_zoomed:
      - ffmpeg:bedroom#video=h264#audio=copy#raw=-vf crop=800:600:1120:250

cameras:
  bedroom:
    enabled: true
    ffmpeg:
      inputs:
        - path: rtsp://127.0.0.1:8554/bedroom
          roles:
            - record
        - path: rtsp://127.0.0.1:8554/bedroom_sub
          roles:
            - detect

Note that subtype=1 is your substream, and subtype=0 is your main stream.

The camera name matches the go2rtc stream name so your Live view will use the full resolution stream, and you are transcoding the audio of the main stream for two way talk. The bedroom_zoomed is also taking the main stream and cropping it.

For more on all of this, see the docs:

https://docs-dev.frigate.video/configuration/restream#reduce-connections-to-camera
https://docs-dev.frigate.video/configuration/go2rtc
https://docs-dev.frigate.video/troubleshooting/go2rtc

[ZhaiSoul]

I’d like to understand the team’s stance on running GenAI locally. Are there any plans to introduce a request queue?

In my setup with over 10 cameras, it’s common for two or three to trigger Review Summary generation simultaneously. Even when using Ollama’s queue, subsequent summary requests often exceed the 120-second timeout, resulting in failed generations.

Given the growing availability of edge computing accelerators capable of running lightweight GenAI models, this bottleneck will become increasingly significant. Would Frigate consider supporting a native GenAI request queue? A slower processing speed would be perfectly acceptable to me.

[YBonline]

But in any case, using ollamas queue plus overwriting the timeout should be sufficient for the desired queue behavior

I will say that from my experience with 0.18, running locally with the hardware that I have (which is probably inadequate TBH, but I haven't decided to invest in upgrades purely for the GenAI features at this point), that the chat is unusable for me due to speed, but the summaries seem to work well enough. I do get some timeouts, but realistically, 90% of my timeouts are daily during the coming home rush (4:30-6:30), when I honestly barely look at the cameras because if someone is doing something bad, someone is going to going to notice and call for the most part.

I imagine if Frigate managed the queue, prioritizing the chat, its gotta work a lot faster. If I try to use the chat at night, when there is almost no activity, it works reasonably.

[hawkeye217]

I'm in agreement with @NickM-27, a request queue is not a feature that we plan to implement or accept a PR for.

A number of technical reasons come to mind:

• A queue adds no throughput. If arrivals outpace inference, it grows without bound no matter how it's tuned.
• Queued requests hold their already-extracted frames in memory, so queue depth means memory growth in the embeddings process.
• Queued work references runtime data that expires (preview frames, recordings, config reloads). A request that runs 20 minutes later may have no valid input.
• Restarts have no good answer: drop the queue (silent loss users report as a bug) or persist it (new state, migration, replay, stale inputs).
• Ordering becomes policy: FIFO starves recent activity, priority needs preemption for chat. Each option is a new config knob and support thread.
• Timeouts stop meaning "the model was slow" and start meaning "you waited behind other work," which is much harder to diagnose.
• Ollama, llama.cpp, and LM Studio already queue and already serialize on the GPU. A second queue means two places to configure and two places to drop requests.
• Frigate can't know what else shares the accelerator, so any concurrency limit is the user's guess.
• Timeout is already overridable via provider options, and model/context/frame-count knobs already exist.

As far as user experience:

• The new failure mode is worse: today a request fails fast and tells you the hardware is undersized; with a queue everything "works" while getting quietly, unboundedly later.
• Review summaries feed notifications. A summary that arrives long after the event isn't degraded, it's useless. Security alerting is not a batch workload.
• Backlogs make the UI look broken: review items without descriptions, lagging search and analytics, bug reports for summaries that are merely pending.
• Every knob (queue size, per-feature concurrency, priority, queued vs active timeouts) is permanent surface area for a feature whose real usage is unknown.

As already noted, the correct fix is capacity or load with a smaller model, smaller context, fewer frames, alerts only, fewer genai cameras, or hardware matched to the camera count. Queue semantics already exist outside Frigate today: the inference server's own queue plus a raised timeout, or a proxy in front of it.

[bagobones]

I am currently using openrouter but have been researching this for local use.

Some thoughts.

• Having per genai provider timeout settings would potentially be useful, if you split out your provider from live chat for example you may want a short time out and a longer time out for reviews and embeddings for another provider.
• Using something like llmgateway and separately defined providers (using the current settings) you could potentially sell fall backs for processes if the local LLM was too slow, and if you defined two providers in frigate differentiate what rules would be used for each.

[NickM-27]

I don't think there really makes sense to be a timeout for chat because chat is streamed, so unless you don't get a response at all in so many seconds then it will just show an error in the UI

[bagobones]

I don't think there really makes sense to be a timeout for chat because chat is streamed, so unless you don't get a response at all in so many seconds then it will just show an error in the UI

If chat already doesn't have a time out that is fine.. I just assumed there was a general timeout per provider not per request type.

In general I agree with moving the problem out of frigate, and maybe using some kind of router (can be self hosted) to prioritize stuff.

And in the frigate side just maybe allow defining a specific provider per camera or task so that you could lets say have a high priority and a lower priority provider defined per camera or per task, they could point to the same router and the router would just handle them differnetly.

IE maybe the doorbell goes to localLLMrouterHigh, and the basement goes to localLLMrouterLow. They both point to the same server but with separate API keys and the LLMrouter decides how to route the request.

The only flexibility change on frigates side is allowing a specific LLM to be defined per camera or per task (already there)

[nacree]

I tried out the onvif for my camera and I'm getting following error. Where is that IP coming from? Onvif on the other camera actually works, so I assume only some issues with this specific camera..

  etuovi:
    enabled: true
    ffmpeg:
      inputs:
        - path: rtsp://localhost:8554/etuovi
          roles:
            - record
            - detect
    onvif:
      host: 10.0.0.36
      port: 8899
      user: admin
      pass: xxx

[hawkeye217]

Is this camera being accessed on forwarded ports from outside your local network?

[nacree]

Hmm, no, everything is in 10.0.0.x network. I did try to access camera through the HA with external IP, but still I don't recall owning such network as 192.168.x.x.

[hawkeye217]

What camera brand and model is it? Perhaps there is a firmware update or the ONVIF port is different than you think it is?

The only issue reminiscent of this was when users had remote port forwarded their camera: #12528

[nacree]

It's super old camera (iCSee brand, maybe?) which model I have no idea. Just happened to configure a new camera with ONVIF successfully, and gave a try for this as well. go2rtc seems to work fine with the ONVIF, as well as Onvier Android app, but frigate gave this error. I was just expecting this to be some default error description, but the actual IP actually come from the camera itself? If so, then we can leave it like it is, not even trying to find any updates for that. :D

Thanks for checking!

[nacree]

It seems to be actually the configured IP of the ethernet port, but now I'm connected over WLAN. They both were available through the ONVIF discovery.. It was possible also to change the IP, and now I'm not able to connect to camera anymore at all... :D

But yeah, eventually got it working by disabling the static IP for the ethernet port.

[ZhaiSoul]

By the way, if a camera has go2rtc restream enabled and you later disable it, the stream URL doesn’t revert to the original camera address—it still points to the go2rtc restream URL. Is this going to be fixed?

[hawkeye217]

If you are referring to switching between "Restream" and "Manual input path" in Settings --> Camera Configuration --> FFmpeg (streams), then yes, the path field keeps the rtsp://127.0.0.1:8554/<stream> URL and you have to replace it yourself if you want your actual camera URL there.

A go2rtc stream is a source definition, not just a URL, so in many configurations there often isn't a single camera address to swap back to. For example, ffmpeg: sources with transcoding, http-flv and similar, multiple sources in one stream, env var substitution, echo:/exec:, or a stream shared by several cameras. Guessing wrong means silently pointing a camera at the wrong source.

On top of that, "disable restream" is ambiguous about the go2rtc stream itself. Should it be deleted? It may still be referenced by live.streams or another camera, so we can't safely assume.

Changing a camera input from a go2rtc restream after initial setup is likely an advanced use case anyways. For the vast majority of users we recommend leaving restreaming on, since it keeps Frigate to a single connection to the camera regardless of how many things are consuming the stream.

For those reasons, I don't see this as a bug or anything that needs to be fixed, so no, we won't be making any changes.

EDIT: I did notice a few small issues that occur with the fields before saving, so I've corrected those in #23763

[andregoncalvespires]

I’m excited about the new features. I installed the beta version for testing today, and the improvements for the user are remarkable.

Forgive me if this is a silly question, but after the initial camera setup—assuming a fresh installation rather than a migration—how do I add a new camera using the wizard? I couldn't find an option for it in the settings.

There is an option for new streams for go2rtc, but nothing for cameras.

[andregoncalvespires]

TKS, and sorry

[andregoncalvespires]

I missed having the option to select the go2rtc stream when adding a new camera, without having to go back and change it later.

[NickM-27]

Can you elaborate what you mean?

[hawkeye217]

You'll definitely want to see the updated documentation for this new version. https://docs-dev.frigate.video

[andregoncalvespires]

Sorry. I actually did read the documentation, but I need to understand a few terms that are confusing me. The option I mentioned is already there (Reduce connections to camera). It might just not be very intuitive. But once you understand it, it becomes obvious.

[ZhaiSoul]

It appears there is no input validation on the listening port setting. Entering an invalid port number causes the process to crash repeatedly in a loop.

2026-07-23 15:56:45.762064136  [INFO] Service NGINX exited with code 1 (by signal 0)
2026-07-23 15:56:46.769998777  [INFO] Starting NGINX...
2026-07-23 15:56:48.498187383  nginx: [emerg] invalid port in "0" of the "listen" directive in /usr/local/nginx/conf/listen.conf:2

Additionally, is it possible to disable the internal listening port? For certain cameras that must run in host network mode, the service becomes exposed on port 5000. If we don’t want that port accessible externally, what’s the recommended way to handle it?

[ZhaiSoul]

However, there appears to be no range validation on the listening port. The system accepts out-of-bounds values (e.g.,  0  or  9999999 ) instead of rejecting them as invalid.

[hawkeye217]

That's because 9999999 is also a valid string. The Pydantic field accepts both int and string, so 9999999 is completely valid.

[ZhaiSoul]

Could we validate whether the input is a numeric string or a general text string? For example, using a regex: if the input consists solely of digits, we parse it as an integer and verify that it falls within the valid port range (1–65535). If it contains non‑numeric characters, we treat it as a plain string and skip numeric validation.

[hawkeye217]

This configuration option is intended for advanced users who understand the implications, as noted in both the UI and the docs. Users already have many ways to misconfigure Frigate. Given the existing warnings in the UI and documentation, there are no plans to add code to change the validation behavior here.

[hawkeye217]

See the documentation for instructions on bind mounting your own nginx config: https://docs-dev.frigate.video/configuration/advanced/system#customizing-the-nginx-configuration

[18923]

FYI
One of my cameras went offline during the night. When reviewing the clip on Windows Chrome, the message "No recordings found for this time" is hardly visible.
The same message is quite visible on my iPhone.
See image below. The message is hard to see it but it's there.

82Xats

[hawkeye217]

If you switch Frigate to dark mode, is the text visible? There's no easy way for the UI to determine the color of the background there.

[18923]

Do you guys ever sleep?
Yes, it's visible in dark mode.
Thank you.

[18923]

Just a thought. Maybe have the text with it's own background?

[hawkeye217]

I'd venture to guess that most users don't have a completely dark scene with their cameras, and the goal of the text is to be as non-intrusive to the scene as possible.

[stuartb55]

Latest dev build has broken pinch to zoom on Android. Used to be able to zoom into the live view and explore view images, now can't.

[hawkeye217]

This is due to an upstream dependency change. I pinned the version of the dep to what was used in 0.17 in this PR: #23818

After it's merged, please test to confirm everything works as expected again.

[stuartb55]

Working again now, thanks!

[dstrohl]

UI Suggestion/minor bug:
in the Settings/System/Logging/Advanced settings area, the per-process log level ui.

the logger name section should be much larger than the value section... I added "frigate.data_processing.real_time.custom_classification" to troubleshoot some classification issues and I can only see "frigate.data_proces" while the value section is probably 3x the size needed, and both together are only half of the overall size of the box they are in.