Don't you need this instead of type:cuda

detectors:
  onnx_0:
    type: onnx
	device: gpu 

Edited September 10, 2025Sep 10 by dopeytree

Hi! I'm trying a fresh install with an rtx a4000 and the yolox_m.onnx but I'm getting this error:

onnxruntime.capi.onnxruntime_pybind11_state.InvalidArgument: [ONNXRuntimeError] : 2 : INVALID_ARGUMENT : Unexpected input data type. Actual: (tensor(uint8)) , expected: (tensor(float))

any ideas why?

thanks

9 hours ago, renk1 said:

Hi! I'm trying a fresh install with an rtx a4000 and the yolox_m.onnx but I'm getting this error:

onnxruntime.capi.onnxruntime_pybind11_state.InvalidArgument: [ONNXRuntimeError] : 2 : INVALID_ARGUMENT : Unexpected input data type. Actual: (tensor(uint8)) , expected: (tensor(float))

any ideas why?

thanks

You did not copy the required input_dtype config https://docs.frigate.video/configuration/object_detectors#yolo-v3-v4-v7-v9-1

detectors:

onnx:

type: onnx

gpu: true

input_tensor: nchw

input_dtype: float

num_threads: 2

model_path: /config/model_cache/yolox_m.onnx

Sorry I forgot to post my config, I did have it defined but still gives me the same error. Tried with float and float_denorm

11 minutes ago, renk1 said:

detectors:

onnx:

type: onnx

gpu: true

input_tensor: nchw

input_dtype: float

num_threads: 2

model_path: /config/model_cache/yolox_m.onnx

Sorry I forgot to post my config, I did have it defined but still gives me the same error. Tried with float and float_denorm

Width and height missing... Copy the proposed configuration

unraid 7.1.4

frigate 0.16.0-rc4

Hi, for many hours I've been struggling unsuccessfully to get face recognition to work in an efficient configuration. I've tried almost everything and would like to ask for help.

Goal: An efficient configuration: person detection on a 640x480 stream, face recognition on a 4K snapshot.

Tested Configurations and Results:

1. Two streams (directly from the camera):

   • Result: Detects person, but never attempts face recognition. The process of taking a 4K snapshot silently fails.

2. One stream (4K only) for detection and recording:

   • Result: Face recognition WORKS CORRECTLY.

   • Problem: Unacceptably high power consumption (~29W).

3. Two streams (via the built-in go2rtc):

   • Result: After rebooting the camera (to clear its IP block), the connection was established correctly.

   • Problem: Despite a working connection, the behavior is identical to Configuration 1 (no face recognition attempt).

4. One 4K stream with downscaling to 640x480 in the detect section:

   • Result: Low power consumption, person is detected.

   • Problem: Behavior identical to Configurations 1 and 3 (no face recognition attempt).

Probable Diagnosis (based on facts):

The problem likely lies within Frigate's internal mechanism. When the detection (detect) source and the snapshot (record) source are not the exact same stream (as in Configurations 1, 3, and 4), the process of fetching the 4K snapshot fails in a way that is not logged. This is likely a timing issue or a bug in switching context between streams.

The Only Working Solution (A Compromise):

Using a single 4K stream for everything (detect and record) with a drastically lowered fps in the detect section (e.g., to 2 FPS) to reduce power consumption. This bypasses the Frigate bug and is the only confirmed working method in this case.

Does anyone have any suggestions on how to solve this, to make it work with go2rtc and two separate streams while maintaining low power consumption?

25 minutes ago, Xwint5 said:

unraid 7.1.4

frigate 0.16.0-rc4

Hi, for many hours I've been struggling unsuccessfully to get face recognition to work in an efficient configuration. I've tried almost everything and would like to ask for help.

Goal: An efficient configuration: person detection on a 640x480 stream, face recognition on a 4K snapshot.

Tested Configurations and Results:

1. Two streams (directly from the camera):

   • Result: Detects person, but never attempts face recognition. The process of taking a 4K snapshot silently fails.

2. One stream (4K only) for detection and recording:

   • Result: Face recognition WORKS CORRECTLY.

   • Problem: Unacceptably high power consumption (~29W).

3. Two streams (via the built-in go2rtc):

   • Result: After rebooting the camera (to clear its IP block), the connection was established correctly.

   • Problem: Despite a working connection, the behavior is identical to Configuration 1 (no face recognition attempt).

4. One 4K stream with downscaling to 640x480 in the detect section:

   • Result: Low power consumption, person is detected.

   • Problem: Behavior identical to Configurations 1 and 3 (no face recognition attempt).

Probable Diagnosis (based on facts):

The problem likely lies within Frigate's internal mechanism. When the detection (detect) source and the snapshot (record) source are not the exact same stream (as in Configurations 1, 3, and 4), the process of fetching the 4K snapshot fails in a way that is not logged. This is likely a timing issue or a bug in switching context between streams.

The Only Working Solution (A Compromise):

Using a single 4K stream for everything (detect and record) with a drastically lowered fps in the detect section (e.g., to 2 FPS) to reduce power consumption. This bypasses the Frigate bug and is the only confirmed working method in this case.

Does anyone have any suggestions on how to solve this, to make it work with go2rtc and two separate streams while maintaining low power consumption?

Face Recognition | Frigate

Face recognition identifies known individuals by matching detected faces with previously learned facial data. When a known person is recognized, their name will be added as a sub_label. This informati

38 minutes ago, yayitazale said:

Face Recognition | Frigate

Face recognition identifies known individuals by matching detected faces with previously learned facial data. When a known person is recognized, their name will be added as a sub_label. This informati

It works for me too, it recognizes the faces of saved people, but only with the option I described, and that's the problem.

One stream (4K only) for detection and recording:

• Result: Face recognition WORKS CORRECTLY.

• Problem: Unacceptably high power consumption (~29W).

I just figure face detection is a growing extra.
It takes a while to build up a database.
I'm running the large model on an intel igpu works well.

5x streams 640x480 or similar sized.
High quality stream is 3k.
No extra power usage.

16 minutes ago, Xwint5 said:

It works for me too, it recognizes the faces of saved people, but only with the option I described, and that's the problem.

One stream (4K only) for detection and recording:

• Result: Face recognition WORKS CORRECTLY.

• Problem: Unacceptably high power consumption (~29W).

Of course 4K requires much more power to be processed...

7 minutes ago, yayitazale said:

Of course 4K requires much more power to be processed...

Unfortunately, with 4k and face recognition, the entire server consumes ~29W, but if go2rtc or a similar alternative worked, it would consume ~24W. Because then it does detection at 640x480, but when it detects a person, it does facial recognition from a 4k photo, but that's what I can't get to work. For me, detection is now running at 4k 2fps all the time with ~26,5W (server). As I described above, I tried various options.

Currently running on

model:
  path: /models/efficientdet_lite1_384_ptq_edgetpu.tflite
  labelmap_path: /models/coco_labels.txt
  width: 384
  height: 384

face_recognition:
  enabled: true
  model_size: large

In the past, I used OpenVINO and iGPU with i5-12500. I bought Coral for testing, but it didn't really give me anything except taking up an m2 slot. Perhaps with more cameras, it will be useful in terms of lower W. I am now using it on

detectors:
  coral:
    type: edgetpu
    device: pci

model:
  path: /models/efficientdet_lite1_384_ptq_edgetpu.tflite
  labelmap_path: /models/coco_labels.txt
  width: 384
  height: 384

When it comes to decoding, what works best for me is

ffmpeg:
  hwaccel_args: preset-vaapi
  input_args:
    - -rtsp_transport
    - tcp

It is better optimized than quick sync.

Edited October 3, 2025Oct 3 by Xwint5

1. what has 4k got to do with it? the model size is 384px

2. what size is your substream on the camera?

3. log into camera webgui or use vlc media info on stream url

4. the 4k video should just being recorded

5. detection should be on the substream

6. which is already a smaller resolution read for the models to work efficiently

Edited October 3, 2025Oct 3 by dopeytree

dopeytree

My main camera stream is 4k 20FPS (I reduced the fps due to W), the sub-stream is currently 640x480, but of course I can change it to 720p. Currently recording 4k and 20FPS video. Face recognition in Frigate runs at 4k 2FPS on the CPU. The 384px model only recognizes people and cars (in my case) and has nothing to do with face recognition, because that's always done by the CPU. Unless you're asking why I wrote about the model I use? It's about power consumption, it's a pretty good model, better than ssd_mobilenet_v2.

For me, face recognition has to be at 4k, because I have ~12m to cover to the gate from a height of 5m. 720p sometimes catches half of it, completely fails, and 640x480 is a total disaster.

Edited October 3, 2025Oct 3 by Xwint5

You likely need a zoom lens (either fixed telephoto or PTZ type or just take apart & change lens) on another camera rather than resolution to help solve Face Recognition from a distance

Thanks for the input. For my use case, a 4mm wide angle lens is optimal. A 6mm lens would make it easier to cover the gate, but I’d lose the garage view on the right. I don’t want another camera because I want both wide and long face capture. Nowadays 4K resolution is quite standard.

In my opinion, the problem lies in Frigate itself. In Frigate 0.16.0-rc4, snapshots for face recognition are always taken from the first input (detect). In practice, this means that with dual-stream (small stream for detection + 4K for recording), only the person is detected, but the face recognition mechanism does not receive the image from 4K. In my tests, it only worked on a single 4K stream.

You may well be correct but alas we can't control frigates coding updates - where-as changing the cameras is possible today.

Some options:

1. FCD600 - 6MP UHD Dual-Lens Outdoor PoE 180° Panoramic View https://www.annke.com/products/fcd600

2. CZ804 - 4K 4X Optical Zoom PoE 12 MM Motorized Varifocal Lens https://www.annke.com/products/cz804

3. NightChroma^TM NCT425 - 2-in-1 Dual Lens PTZ 25X Optical Zoom https://www.annke.com/products/nct425

Reaching out for help here as I've done research elsewhere and tried optimizing a handful of different things both in hardware and software but still having the same issue with the coral TPU going offline making Frigate stop working (even though the container doesn't crash). This has started happening more frequently recently, on the order of multiple times a week, escalating today where it happened post reboot within 30 minutes. How can i correctly troubleshoot this to figure out what to do to fix it?

System info:

• intel i7-9700K processor (w/ quicksync)

• ASRock Z390 Pro4 ATX LGA1151 Motherboard

  • 2x M.2 key M slot + 1x M.2 Key E slot

• 32 GB RAM (4x8GB)

• Google Coral TPU Accelerator, M.2 (A/E Key)

• 1 HDD for frigate storage in pool (no parity)

  • some dashcam footage is also synced to this drive

• 2 nvme for zfs cache (mirrored)

Cameras:

• 7x 1080p wyze v3 (thingino fw)

• 2x 2K tapo c120

• 1x 2K reolink wifi doorbell

• 1x 4K reolink POE

Here are some of the steps i've taken thus far:

• confirmed all streams are using sub stream for detect, and main stream only for record/audio

• moved 1 nvme ssd from M.2 key M slot to PCIe slot via M.2 to PCIe adapter

  • previously when coral tpu offline issue occurred, reboot would cause second nvme ssd to become unavailable - only solution was full shutdown. Making this change mitigated this, allowing normal reboot to bring coral tpu back online.

• optimized Frigate container Extra Parameters:

  • --shm-size=4G --mount type=tmpfs,target=/tmp/cache,tmpfs-size=1000000000 --restart unless-stopped --log-opt max-size=10m --log-opt max-file=3 --memory=16G --memory-swap=16G

• optimized Extra Parameters on one other high RAM use container:

  • --memory=12G --memory-swap=12G

• installed Netdata container

  • not sure what to look for yet

EDIT: given all i've read about the issues with coral A+E key TPUs causing issues on desktop motherboards' m.2 slot meant for wifi chips, I ended up replacing my coral M.2 A+E key TPU with a Hailo-8L M.2 B+M key TPU. It's only been a few weeks but haven't had any issues since.

Edited October 17, 2025Oct 17 by john_smith
update hw

john_smith

What version of BIOS do you have on your motherboard? Do you have the latest BIOS?

Imho most likely causes

• PCIe conflict/instability in the M.2 E‑key (CNVi) slot on Z390: lane sharing with other slots/SATA, ASPM/L1.2, AER. The NVMe becoming unavailable after a reboot is a strong clue.

• Coral M.2 overheating (no heatsink/airflow) → watchdog/device reset.

• Bug/incompatibility of the apex/gasket driver with the kernel version (AER/ASPM).

• 3.3 V power on the M.2 E‑key (PCH VRM) – voltage drops under load.

• Physical contact of the 2230 module – poor seating/pressure, intermittent disconnects.

On 10/4/2025 at 8:45 PM, john_smith said:

Reaching out for help here as I've done research elsewhere and tried optimizing a handful of different things both in hardware and software but still having the same issue with the coral TPU going offline making Frigate stop working (even though the container doesn't crash). This has started happening more frequently recently, on the order of multiple times a week, escalating today where it happened post reboot within 30 minutes. How can i correctly troubleshoot this to figure out what to do to fix it?

System info:

• intel i7-9700K processor (w/ quicksync)

• ASRock Z390 Pro4 ATX LGA1151 Motherboard

  • 2x M.2 key M slot + 1x M.2 Key E slot

• 32 GB RAM (4x8GB)

• Google Coral TPU Accelerator, M.2 (A/E Key)

• 1 HDD for frigate storage in pool (no parity)

  • some dashcam footage is also synced to this drive

• 2 nvme for zfs cache (mirrored)

Cameras:

• 7x 1080p wyze v3 (thingino fw)

• 2x 2K tapo c120

• 1x 2K reolink wifi doorbell

• 1x 4K reolink POE

Here are some of the steps i've taken thus far:

• confirmed all streams are using sub stream for detect, and main stream only for record/audio

• moved 1 nvme ssd from M.2 key M slot to PCIe slot via M.2 to PCIe adapter

  • previously when coral tpu offline issue occurred, reboot would cause second nvme ssd to become unavailable - only solution was full shutdown. Making this change mitigated this, allowing normal reboot to bring coral tpu back online.

• optimized Frigate container Extra Parameters:

  • --shm-size=4G --mount type=tmpfs,target=/tmp/cache,tmpfs-size=1000000000 --restart unless-stopped --log-opt max-size=10m --log-opt max-file=3 --memory=16G --memory-swap=16G

• optimized Extra Parameters on one other high RAM use container:

  • --memory=12G --memory-swap=12G

• installed Netdata container

  • not sure what to look for yet

If you are sure that it is not related to temperature issues, test with https://coral.ai/software/, maybe you have a faulty device.

5 hours ago, Xwint5 said:

john_smith

What version of BIOS do you have on your motherboard? Do you have the latest BIOS?

Imho most likely causes

• PCIe conflict/instability in the M.2 E‑key (CNVi) slot on Z390: lane sharing with other slots/SATA, ASPM/L1.2, AER. The NVMe becoming unavailable after a reboot is a strong clue.

• Coral M.2 overheating (no heatsink/airflow) → watchdog/device reset.

• Bug/incompatibility of the apex/gasket driver with the kernel version (AER/ASPM).

• 3.3 V power on the M.2 E‑key (PCH VRM) – voltage drops under load.

• Physical contact of the 2230 module – poor seating/pressure, intermittent disconnects.

I do have the latest BIOS actually, forgot to mention this in my troubleshooting steps. I did this after the first step actually.

I am wondering if it's related to load, but why would it fail catastrophically? shouldn't it just throttle and then take longer to detect?

5 hours ago, yayitazale said:

If you are sure that it is not related to temperature issues, test with https://coral.ai/software/, maybe you have a faulty device.

i will look into this

Edited October 6, 2025Oct 6 by john_smith

Hi, So my frigate instance which is connected to HA OS suddenly stopped running and when I try to restart it I get this message:

Error: open /config/config.yaml: too many open files

I tried setting the ulimit option but that made no difference.

Any idea why this is happening?

On 10/6/2025 at 9:01 AM, Xwint5 said:

john_smith

What version of BIOS do you have on your motherboard? Do you have the latest BIOS?

Imho most likely causes

• PCIe conflict/instability in the M.2 E‑key (CNVi) slot on Z390: lane sharing with other slots/SATA, ASPM/L1.2, AER. The NVMe becoming unavailable after a reboot is a strong clue.

• Coral M.2 overheating (no heatsink/airflow) → watchdog/device reset.

• Bug/incompatibility of the apex/gasket driver with the kernel version (AER/ASPM).

• 3.3 V power on the M.2 E‑key (PCH VRM) – voltage drops under load.

• Physical contact of the 2230 module – poor seating/pressure, intermittent disconnects.

I had reseated it a few times, and never saw the temps go anywhere near even throttling.

I don't know whether it was a power issue under load, something buggy with the kernel/driver/apex, or a PCIe conflict/instability, but tbh it sounded like more than one of these, and I was a bit tired of troubleshooting this.

Given all i've read about the issues with coral A+E key TPUs causing issues on desktop motherboards' m.2 slot meant for wifi chips (here and elsewhere) I ended up replacing my coral M.2 A+E key TPU with a Hailo-8L M.2 B+M key TPU.

It's only been a few weeks but haven't had any issues since.

14 hours ago, supawiz6991 said:

Hi, So my frigate instance which is connected to HA OS suddenly stopped running and when I try to restart it I get this message:

Error: open /config/config.yaml: too many open files

I tried setting the ulimit option but that made no difference.

Any idea why this is happening?

Update: I resolved this. My appdata plugin was ultimately to blame. My appdata plugin started failing to backup (root cause of this is still under investigation), once this failure started it kept retrying the backup and failing repeatedly. This resulted in two things: 1. Backup directory got spammed with failed partial backups. 2. Errors spammed the log from the failing backups. The two of these caused my system to hit the minimum free space setting which then caused docker to fail and spam the logs even more.

Partial resolution: Disable the appdata backup plugin, delete the 4TB of failed partial backups, restart the server to clear the logs and everything came back up normally.

To Do: Determine the root cause as to why the appdata backup plugin went off the rails, mitigate the cause and re-enable the plugin so that backups can resume.

TL:DR Cascade failure due to a misbehaving backup plugin that caused the minimum free space threshold to be reached.

Edited October 18, 2025Oct 18 by supawiz6991

Hi all,

I recently switched to an intel Core Ultra 7 and was wondering if there is any way to use the embedded NPU.
I noticed there is an accel0 device detected within unraid and could read here and there that people managed to use the NPU in Frigate but I couldn't put my hands on an actual guide to do this.
Thanks!

On 10/24/2025 at 3:31 PM, mathgoy said:

Hi all,

I recently switched to an intel Core Ultra 7 and was wondering if there is any way to use the embedded NPU.
I noticed there is an accel0 device detected within unraid and could read here and there that people managed to use the NPU in Frigate but I couldn't put my hands on an actual guide to do this.
Thanks!

Frigate v16 doesn't support NPU, v17 will do. https://github.com/blakeblackshear/frigate/discussions/13248 https://github.com/blakeblackshear/frigate/pull/20536