Hi,

I was looking into getting a few Raspberry Pi Zero 2 Ws for installing Mint or similar and running VLC to view Birdseye and outputting the HDMI into TVs around the house so users can "switch to HDMI2" on the TV to view the CCTV etc. but it seems these Zero 2 Ws are constantly out of stock.

Any suggestions for an alternative to do similar?

I'm completely rebuilding my UnRAID server with a pair of Xeon Golds and a lot of memory.

My current setup is an Intel i9-10850K with a Coral, a 3060 8GB, and a Hailo — all of which I'm getting rid of.

I'd like to keep power draw and spend low-ish. What suggestions do you all have for a card (or cards) to handle detection/inference and decode?

Will be running 15 4k cameras, looking for accurate detections.

I'm considering an Intel B580 paired with an A310 for decode, but open to other ideas from someone with more experience.

A 3090 is out of the question financially — already spent most of my allowance on the new server.

Disclaimer: non native english speaker here, so I asked an AI to summarize what I found and writte the post. seems I have to specify that, some people think that as it has been written by an ai, it's not relevant...

TL;DR: Cheap Chinese cloud cameras (IMOU / Dahua OEM, and others) often go into a reboot loop every few seconds the moment you block their internet access. Everyone assumes the camera "needs the cloud." In my case it didn't. It needed the time. Blocking the internet also blocked NTP, the camera couldn't get a clock, and that was what made it reboot. Serve NTP locally (and transparently intercept it), then firewall the camera off the internet, and it runs happily offline forever while your local NVR keeps recording. Here's the full debugging story and the fix.

The setup

• A hypervisor running a router/firewall VM (OPNsense) as the LAN gateway.
• A separate box doing DNS ad-blocking + DHCP.
• Home Assistant + Frigate recording the cameras over local RTSP.
• A handful of IMOU / Dahua-based IP cameras (plus some YI/Kami ones), all on the LAN.

Everything is private-range IPv4. I'll use these throughout:

• 10.0.0.100 = OPNsense (gateway)
• 10.0.0.94 = my test PC
• 10.0.0.232 = the camera under test (a Dahua-based IMOU unit)

The problem

I wanted the cameras off the internet for privacy (no telemetry or images to the vendor cloud) while keeping local recording in Frigate. Frigate pulls RTSP over the LAN, so in theory it doesn't need the internet at all.

But every time I cut a camera off (by IP, by rule, by VLAN, didn't matter how), it would reboot every few seconds, tearing down the RTSP stream Frigate was reading. So "local only" was effectively unusable. Classic Chinese-cam behavior: if it can't call home, it panics.

First realization: Frigate isn't the problem, the camera's tantrum is

Frigate pulls RTSP on the LAN. That traffic doesn't even traverse the gateway, so the camera being offline should be invisible to Frigate. The only reason cutting the internet broke recording was the camera rebooting itself and dropping the stream. The real task wasn't "keep the cloud", it was "stop the camera from rebooting when the cloud is gone."

Hypotheses for the reboot

Cheap cameras reboot-on-no-internet for one of a few reasons, easiest to hardest:

1. NTP / time sync fails at boot, firmware bails and restarts. Very common, easy to fix.
2. DNS fails, interpreted as "no network."
3. Cloud handshake fails: the firmware requires a successful connection to the vendor P2P servers.

The right move isn't to guess. It's to watch what the camera actually does and find the minimum that keeps it alive. Time to break out packet captures on the gateway.

Fixing candidate #1: serve time locally

OPNsense has a built-in NTP server (Services → Network Time). Enable it, pick the LAN interface, leave upstream pools so the firewall itself has correct time. Done, the gateway now answers NTP.

But that's only half of it. The camera won't magically ask my server; it targets hardcoded time servers on the internet. Since I couldn't reconfigure the camera, I transparently intercepted all NTP with a NAT redirect:

Firewall → NAT → Port Forward
  Interface:            LAN
  Protocol:             UDP
  Destination:          any
  Destination port:     123 (NTP)
  Redirect target IP:   10.0.0.100   (OPNsense itself)
  Redirect target port: 123

Now any NTP query from any device, aimed anywhere, gets answered locally by the firewall.

Neat trick: how to prove the interception works

When you redirect like this, the reply reaches the client with the original destination IP spoofed back (so the client accepts it). Looking at the source IP is useless, it still says "Google" or "Ubuntu." The tell is the NTP payload's Reference-ID field, which identifies the responder's upstream.

I queried two different public NTP servers and captured the replies. Both came back with the exact same Reference-ID. That's impossible for two genuinely different servers, so both were really being answered by my firewall. Interception confirmed, and it was catching every subnet on the LAN.

The decisive test: cut the internet, watch the camera

Rule of thumb: block the camera from the internet but allow it to reach local/private networks (so Frigate/RTSP and local NTP still work).

Alias RFC1918 = 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

Firewall → Rules → LAN (order matters, both above the default allow):
  1) PASS  proto any  source 10.0.0.232/32  dest RFC1918   (quick)
  2) BLOCK proto any  source 10.0.0.232/32  dest any       (quick)

Then a continuous ping 10.0.0.232 in one window and a packet capture in another.

Gotcha #1: stateful firewall

At first the block "didn't work". The camera's keepalive to the cloud kept getting replies. The reason: pf is stateful, and the camera already had established connections open before I added the rule. New rules don't tear down existing states. The giveaway in the capture was subtle but clear: new connections were being dropped and retransmitted, while the old keepalive sailed through on its grandfathered state.

Fix: Firewall → Diagnostics → States, filter the camera IP, and kill the states (or reset the state table). Now every packet is re-evaluated against the new rules. Always do this after changing rules mid-connection.

The result

With states cleared, the cut was total. In the capture the camera was frantically trying to reach its cloud, rotating through a whole catalog of P2P/relay servers and ports, and getting nothing back. All of it died at the firewall. Nothing left toward the WAN. Zero telemetry.

And the camera... just kept running. No reboot. Ping rock-steady.

Gotcha #2: how to prove it didn't reboot (without touching it)

You don't need console access to know whether an appliance restarted. Two forensic signals in a capture:

• TCP TS val (timestamp option) is a monotonic counter tied to uptime. Across several minutes of the block it kept climbing steadily. A reboot would reset it to a low value. It never did, so the device stayed up.
• A reboot also produces an ARP burst + DHCP DISCOVER + boot sequence. I saw only lone periodic who-has gateway ARPs (normal cache refreshes), never a boot storm.

So the camera was demonstrably alive the whole time. It just couldn't reach the cloud, and didn't care enough to restart. The missing piece all along was the clock: previously, cutting the internet also cut NTP, the camera couldn't get time and rebooted. With NTP served locally, it gets time even while fully firewalled, and stays up.

Bonus findings worth knowing

• These cameras ignore your DNS. Under stress mine issued DNS queries straight to hardcoded 8.8.8.8, not the DNS server handed out by DHCP. So domain-based blocking (Pi-hole/AdGuard blocklists) is useless here, the camera never asks your resolver. Firewall by IP is the only thing that works.
• It is not streaming your video to the cloud 24/7. At rest the traffic was tiny: a lightweight keepalive every ~20s, a few hundred bytes. Actual video seems to only leave on demand, when you open the vendor app remotely. Still worth cutting (the keepalive is identity/online telemetry, and some firmwares upload event thumbnails), but it recalibrates the panic. It's not firehosing your living room to the far side of the world around the clock.
• Your local NVR doesn't need the internet at all. Frigate pulls RTSP over the LAN; that path never touches the gateway. Kill the reboot loop and it records with the camera 100% offline.

The recipe, condensed

1. Enable an NTP server on your router/firewall.
2. Transparently redirect all outbound UDP/123 to it (so cameras get time regardless of their hardcoded servers).
3. Firewall the camera off the internet but allow RFC1918 (LAN/local) so RTSP + local NTP keep working.
4. Reset firewall states after adding the rules.
5. Verify: capture shows cloud attempts dying at the firewall; TS val climbing = no reboot; ping steady; NVR still recording.

Caveats / things I'm still chasing

• Firmware varies. Some units reboot on cloud loss regardless of time. If NTP-local isn't enough, the next levers are: try Reject instead of Block (a fast RST/ICMP unreachable is sometimes handled more gracefully than a silent timeout), or, worst case, fake the cloud handshake with a local listener (hard, proprietary protocol).
• Other brands differ. My YI/Kami cameras use a different cloud entirely; their reboot trigger may not be NTP. Test one at a time, don't assume the Dahua fix generalizes.
• This is WAN-blocking, not true isolation. If your LAN is flat (multiple subnets sharing one L2 segment), IP ranges alone don't isolate anything. A compromised cam can still talk to your trusted devices at layer 2. For real containment you want a dedicated IoT VLAN on a managed switch, with the firewall enforcing the boundary.

Hope this saves someone the two hours I spent staring at tcpdump. The headline lesson: when a cheap camera reboots on "no internet," suspect the clock before the cloud.

Disclaimer: non native english speaker here, post aided by AI.

I set up frigate with a couple Reolink cams. When I went to create a separate user account for frigate, I found that the cameras wouldn't let me create new user accounts. Instead they wanted me to run through a sharing workflow using a QR code and some kind of song and dance.

It turns out recent versions of the Reolink firmware and apps have been removing the user management functionality, which seems like an odd thing to do.

However, I was able to work around this by using the Reolink API on the cameras. Something like this did the trick for me:

> virtualenv .
> source bin/activate
> pip install reolinkapi
> python3
>>> from reolinkapi import Camera
>>> c = Camera('<ip address>', password='<admin_password')
>>> c.login()
>>> c.add_user('<frigate_username>', '<frigate_password>')

Is a bundled libhailort 5.3.0 in the works? Been out of the loop for a while and I may have missed a fix.

Been suffering with the crashing 4.21 driver in Unraid 7.3.1 for a while now and was wondering whether I should go to a Telsa or something else.

I was using an intel iGPU, and now I'm using an Nvidia GPU on a different computer.
I changed the image to "frigate:0.17.2**-tensorrt**"
/dev/dri/renderD128 stayed the same as before.

#Solution: Remove "-tensorrt" from the image name
Install Nvidia drivers on my Ubuntu VM to where the 'NVIDIA-SMI' command would work.
THEN add this to the docker config:

deploy:
  resources:
    reservations:
      devices:
        # Reserve all available GPUs
        - driver: nvidia
          count: all
          capabilities: [gpu]

Thank you.

#Docker Config services: frigate: container_name: frigate privileged: true restart: unless-stopped stop_grace_period: 30s image: ghcr.io/blakeblackshear/frigate:0.17.2-tensorrt secrets: - frigate_rtsp_pass shm_size: "512mb" devices: - /dev/dri/renderD128:/dev/dri/renderD128 volumes: - /etc/localtime:/etc/localtime:ro - frigate:/config - /mnt/FrigateMedia:/media/frigate - type: tmpfs # Optional: 1GB of memory, reduces SSD/SD Card wear target: /tmp/cache tmpfs: size: 1000000000 ports: - "8971:8971" - "5000:5000" # Internal unauthenticated access. Expose carefully. - "8554:8554" # RTSP feeds - "8555:8555/tcp" # WebRTC over tcp - "8555:8555/udp" # WebRTC over udp - "1984:1984" # Go2RTC environment: FRIGATE_RTSP_PASSWORD: frigate_rtsp_pass YOLO_MODELS: yolov9-t-320 NVIDIA_VISIBLE_DEVICES: all NVIDIA_DRIVER_CAPABILITIES: compute,utility,video

secrets:
  frigate_rtsp_pass:
    file: /var/lib/docker/secrets/frigate_rtsp_pass.txt

volumes:
  frigate:

#Frigate Config version: 0.17-2

detect:
  enabled: true

tls:
  enabled: false

detectors:
  onnx_0:
    type: onnx
    device: GPU

model:
  model_type: yolo-generic
  width: 320 # <--- should match the imgsize set during model export
  height: 320 # <--- should match the imgsize set during model export
  input_tensor: nchw
  input_dtype: float
  path: /config/model_cache/yolov9-t-320.onnx
  labelmap_path: /labelmap/coco-80.txt

ffmpeg:
  hwaccel_args: preset-nvidia


#Record
record:
  enabled: true

go2rtc:
  streams:
    FrontYard: 
      rtsp://admin:PASSWORD@192.168.1.6/cam/realmonitor?channel=1&subtype=0
    FrontYardSub: 
      rtsp://admin:PASSWORD@192.168.1.6/cam/realmonitor?channel=1&subtype=1

cameras:
  FrontYard:
    ffmpeg:
      inputs:
        - path: rtsp://127.0.0.1:8554/FrontYard?video=copy
          input_args: preset-rtsp-restream
          roles:
            - record
        - path: rtsp://127.0.0.1:8554/FrontYardSub?video=copy
          input_args: preset-rtsp-restream
          roles:
            - detect
      output_args:
        record: preset-record-generic-audio-copy
    live:
      streams:
        FrontYard: FrontYard

So my FR works fine, the min value is calibrated, now I want to understand what makes it take a picture? It can't be just the minimum value as pictures are not taken every single second so is there a maximum limit that whenever a face is seen there must be a maximum of x pictures?

I'm trying to understand, sometimes visitors are at my door for a good 30 seconds and then a couple of more minutes after I open the door and speak to them and then when I look at my FR I only see approximately 6 snapshots of one particular second or maybe two sets of 6 snapshots each

They have been times when the person is looking straight on the camera and a very good resolution/front angle is available but yet FR chooses a side angle with lower resolution

Is there anything that I can do to improve this?

I am a Frigate+ subscriber with a fairly well fine-tuned model; however, from time to time, I still receive false positive notifications in Home Assistant, mostly during rainfall.
Is there a way to pass the Frigate detection to Home Assistant, but prior to triggering a notification, use a vision model to verify that the detection is valid and also provide a brief description of it?
I have attempted to achieve this with the assistance of AI, but I seem to be reaching a dead end. I would greatly appreciate any advice. Thank you in advance.

With Frigate 0.17.2 dropping today, I have released version 1.4.0 of the automated Proxmox LXC installation and update script.

This release fixes a few long-standing issues and adds automated migration support for updating older container setups to the new compose standards.

Key Changes in v1.4.0:

• Automatic Docker Compose Migration: Since standardizing on compose.yml instead of the legacy docker-compose.yml name, updating older container installations would fail. The update script now automatically detects and renames /opt/frigate/docker-compose.yml to compose.yml on the fly to prevent update failures.
• Streamlined CLI Flags: VLAN, MTU, and Proxmox container firewall settings have been moved from interactive prompts to optional CLI flags (--vlan, --mtu, and --firewall), making the default installation path much faster.
• Intel QSV Troubleshooting: Added documentation and automated workarounds for Intel QSV surface allocation errors ("Can't allocate a surface") commonly seen on newer Intel Alder Lake and Raptor Lake CPUs.
• Better Network Wait Hook: Replaced the basic interface IP check in the installer with a proper DNS resolution loop, preventing the installer from failing early if the container receives a DHCP lease a second before name resolution is fully routed.
• Exposed Ports by Default: The generated compose file and Proxmox container firewall rules now automatically expose go2rtc (1984) and Frigate Auth (8971) by default.
• GPU Render Node Fallbacks: The script now resolves and binds the first detected render node on the host automatically if only one GPU is present, preventing manual mapping issues.

How to use it:

To update an existing installation to 0.17.2:

bash <(curl -s https://raw.githubusercontent.com/saihgupr/frigate-proxmox-script/main/update.sh) --id <your_ct_id> --version latest

(The update script will prompt you to take a container snapshot first, which is highly recommended before performing the update).

If you are setting up a clean installation:

bash <(curl -s https://raw.githubusercontent.com/saihgupr/frigate-proxmox-script/main/install.sh)

Source code and full changelog: https://github.com/saihgupr/frigate-proxmox-script

If you run into any issues during the upgrade, please let me know or open an issue on the repo.

I've been pulling my hair out for days. I've been using v0.13.2 in an community scripts lxc container passing in a Coral TPU for years, rock solid. I've been trying to get v0.17.2 via proxmox community scripts wokrin so I can use my Arc A310 rather then the TPU, but even fresh installs with sample conf are going into a bootloop. So I broke down and did it per the docs and built it on docker. Exact same issue! What am I missing? Here is the logs before it reboots itself:

info    | 2026-06-29 22:58:33 | startup                   | Preparing Frigate...
info    | 2026-06-29 22:58:33 | startup                   | Starting Frigate...
info    | 2026-06-29 22:58:35 | frigate.util.config       | Checking if frigate config needs migration...
info    | 2026-06-29 22:58:35 | frigate.util.config       | frigate config does not need migration...
info    | 2026-06-29 22:58:35 | frigate.app               | Starting Frigate (0.17.2-3d4dd3a)
info    | 2026-06-29 22:58:35 | peewee_migrate.logs       | Starting migrations
info    | 2026-06-29 22:58:35 | peewee_migrate.logs       | There is nothing to migrate
info    | 2026-06-29 22:58:35 | frigate.app               | Recording process started: 443
info    | 2026-06-29 22:58:35 | frigate.app               | Review process started: 456
info    | 2026-06-29 22:58:35 | frigate.app               | go2rtc process pid: 120
info    | 2026-06-29 22:58:36 | frigate.app               | Embedding process started: 466
info    | 2026-06-29 22:58:36 | frigate.app               | Output process started: 515
info    | 2026-06-29 22:58:36 | frigate.camera.maintainer | Camera processor started for House: 564
info    | 2026-06-29 22:58:36 | frigate.camera.maintainer | Capture process started for House: 621
info    | 2026-06-29 22:58:36 | frigate.api.fastapi_app   | Starting FastAPI app
unknown | 2026-06-29 22:58:36 | unknown                   | Process frigate.detector:ov:
unknown | 2026-06-29 22:58:36 | unknown                   | Traceback (most recent call last):
unknown | 2026-06-29 22:58:36 | unknown                   | File "/usr/lib/python3.11/multiprocessing/process.py", line 314, in _bootstrap
unknown | 2026-06-29 22:58:36 | unknown                   | self.run()
unknown | 2026-06-29 22:58:36 | unknown                   | File "/opt/frigate/frigate/object_detection/base.py", line 143, in run
unknown | 2026-06-29 22:58:36 | unknown                   | object_detector = LocalObjectDetector(detector_config=self.detector_config)
unknown | 2026-06-29 22:58:36 | unknown                   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
unknown | 2026-06-29 22:58:36 | unknown                   | File "/opt/frigate/frigate/object_detection/base.py", line 62, in __init__
unknown | 2026-06-29 22:58:36 | unknown                   | self.detect_api = create_detector(detector_config)
unknown | 2026-06-29 22:58:36 | unknown                   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
unknown | 2026-06-29 22:58:36 | unknown                   | File "/opt/frigate/frigate/detectors/__init__.py", line 18, in create_detector
unknown | 2026-06-29 22:58:36 | unknown                   | return api(detector_config)
unknown | 2026-06-29 22:58:36 | unknown                   | ^^^^^^^^^^^^^^^^^^^^
        |                     |                           | 

I also tried building in docker per instructions, same results. Docker Compose:

version: "3.9"
services:
  mqtt:
    image: eclipse-mosquitto:2
    restart: unless-stopped
    ports: ["1883:1883"]
    volumes:
      - ./mosquitto/config:/mosquitto/config
      - ./mosquitto/data:/mosquitto/data
  frigate:
    image: ghcr.io/blakeblackshear/frigate:stable
    privileged: true
    restart: unless-stopped
    shm_size: "1024mb" # Adjust for camera count
    devices: ["/dev/dri/renderD129"] # Intel iGPU acceleration
    volumes:
      - ./config:/config
      - ./storage:/media/frigate
      - type: tmpfs
        target: /tmp/cache
        tmpfs: { size: 1000000000 }
    ports: ["5000:5000", "8554:8554", "8555:8555/tcp", "8555:8555/udp"]
    depends_on: [mqtt]

frigate config

mqtt:
  enabled: False
#  host: mqtt.vand                 # MQTT broker hostname
#  user: HAAS                      # MQTT username
#  password: {passowrd}           # MQTT password


ffmpeg:
  hwaccel_args: preset-intel-qsv-h264   # Use Intel QuickSync on the Arc A310


detectors:
  ov:
    type: openvino                # OpenVINO detector
    device: GPU                  # Use Intel Arc GPU for inference


objects:
  track:
    - person                      # Detect people
    - car                         # Detect cars
    - dog                         # Detect dogs
    - cat                         # Detect cats


snapshots:
  enabled: true                   # Enable snapshots
  bounding_box: true              # Draw boxes on snapshots
  timestamp: true                 # Add timestamp to snapshots


cameras:
  House:
    ffmpeg:
      inputs:
        - path: rtsp://10.0.0.1:7447/{path to camera}
          roles:
            - detect
    detect:
      width: 1920
      height: 1080
      fps: 5
    objects:
      track:
        - person
        - cat
        - dog
    motion:
      mask:
        - 0,0,351,0,354,84,0,92

I am migrating my doorbell over to an RSTP model, and I was curious about the frigate+ stuff. I've been using the standard frigate on my unraid server with the Coral GPUs for a couple of years, and have been happy.

For those of you that have frigate+ (or had it and got rid of it), what are some of the things you learned about it? Is it worth it to help better my detection? I currently run 9 cameras.

Morning :)

I have been tinkering away with Frigate for a few days to get to know the app and really like it but have hit a few walls with crashes so am looking for some advice on the best setup I should be looking to use for my hardware.

AMD Ryzen 9 6900HX with Radeon Graphics | 8 Cores | 3.30 GHz | 16 Threads
32GB 4800 MHz DDR5
AMD Rembrandt [Radeon 680M]
ZimaOS
4TB HDD Space

4 x Aqara G100 Cameras - likely to add 4 more external cameras over the next few weeks

Looking to setup for 2 day continuous record and then snapshots on motion detection - maybe look into object detection if its possible to run on this hardware.

ZimaOS is already running a handful of services for me locally including Jellyfin but this is currently setup for direct play only

Any advice on frigate version or directions would be greatly appreciated.

UPDATED

I have managed to get the system stable with the following config which I can add all 4 cameras in without issue. What I really want to do now is look at setting up the detection & motion alerts somehow with my current hardware specs. I've tried blindly tweaking so thought this time I would ask for some pointers and advice :)

mqtt:
  enabled: False

cameras:
  Office:
    enabled: true
    ffmpeg:
      inputs:
        - path: rtsp://319:693@192.168.4.227:8554/ch1
          roles: [detect]
        - path: rtsp://319:693@192.168.4.227:8554/ch1
          roles: [record]
    detect:
      enabled: false
    snapshots:
      enabled: true
      timestamp: true
      bounding_box: true
    record:
      enabled: true
      continuous:
        days: 2

version: 0.17-0

Please your help , i need to add 2 xiaomi cameras on frigate , i have the c500 (dual) and the cw500 (dual) , they area pain in the yaml adding secction

Thanx

My server pc just has an intel cpu and 16gb ram with no gpu. This will only be for my doorbell camera so it won't be adding a heavy load regardless of which choice I go with

Noticed my PC hardware specs arent enough to run Frigate 0.17, Yolo9 small and Ollama. PC specs: Corei7 8th gen, 16Gb Ram, 2TB NVME, Nvidia Quadro T1000. Using just 4 cameras.

https://preview.redd.it/f1iadyyh24ah1.png?width=684&format=png&auto=webp&s=f53a096a7beac84ab8351bd4b743901bc61dca08

usage after tunning ffmpeg, fps=5 for detection, min area 15000....