Xwint5

Update: hardware changes + SMB/FTP testing - Changed cache from BTRFS to XFS + docker.img --> Docker Directory - Replaced server realtek 2,5GbE NIC with Intel I226-V (2.5GbE) - Added NVMe Lexar NM790 2TB as separate pool (XFS) for testing Test: always the same .mkv file 16.7GB, Windows --> Unraid. - SMB: first copy after server and Windows restart usually ~230–270 MB/s, subsequent ones (especially to deeper folders) drop to ~80–90 MB/s - FTP: same file goes stable ~250–270 MB/s -SMB: Unraid (reading from Cache) --> Windows (writing) goes stable 275-281 MB/s. With copying from server to windows there was never a problem. - Source in Windows tested from SSD and NVMe - no impact on result - Overall in FTP Intel is faster than Realtek - Problem occurred on both cards (Realtek + Intel), so it wasn't a NIC issue

I ordered an Intel I226-V 2.5GbE PCIe yesterday and should have it in about 2 weeks. This SMB write bottleneck has been plaguing me since day one, and I've been unable to resolve it despite extensive testing. I've had this issue on two different configurations, though sometimes I do get around 230 MB/s, especially when writing to deeper directory paths. Using filezilla (FTP) gives me ~165 MB/s to the main multimedia share, but ~220-240 MB/s to deeper subdirectories, even though both locations span multiple disks in the array.

iostat monitoring during 80 MB/s SMB write to cache: The NVMe drive was barely working - %util only 2.7%, w_await 2.6ms, and most of the time showing 0.00 activity across all metrics. This clearly shows the bottleneck is not the storage - the MSI M450 NVMe can handle much more but SMB write path is limiting throughput somewhere between the network and filesystem layers. If this was a DRAM-less + BTRFS issue, we'd expect high %util (50-80%) and elevated w_await times, but the drive is practically idle during slow SMB writes. Local write test results: dd if=/dev/zero of=/mnt/cache/test_speed.img bs=1M count=4000 oflag=direct status=progress 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 3.84098 s, 1.1 GB/s Local write: 1.1 GB/s vs SMB write: ~150 MB/s This confirms the NVMe and BTRFS are not the bottleneck - the issue is specifically in the SMB write path. The drive has 7-8x more capacity than SMB is utilizing.

results (SMB Write from Windows): Direct to cache (NVMe): ~155 MB/s Direct to disk2 (HDD): ~165 MB/s (Parity disk was active during this copy, as expected). To confirm FUSE was fully bypassed, I monitored processes while copying to disk2. smbd was working, but shfs remained at 0.0% CPU: 857891 myuser 20 0 92832 20420 15480 S 21.0 0.0 0:14.25 smbd 833042 root 20 0 625036 11156 1844 S 0.0 0.0 0:40.74 shfs 833029 root 20 0 139356 2052 1732 S 0.0 0.0 0:00.00 shfs Since writing directly to the NVMe cache is still slow (~155 MB/s) and bypassing /mnt/user didn't improve the speed, FUSE is clearly not the bottleneck here. With iperf3 showing a solid 2.35 Gbps and SMB reads hitting ~270 MB/s, what would you suggest checking next? Could it be related to Samba settings or the Windows TCP stack?Results (SMB Write from Windows): UPDATE: Ubuntu Live USB SMB Write Results: Ubuntu 26.04 LTS - same file from same source drive, copying to Unraid via SMB: Direct to cache (MSI M450 1TB NVMe, btrfs): ~127 MB/s Direct to disk2 (HDD): ~150 MB/s

Thanks for the link JorgeB! I tried the same approach from that thread. I temporarily disabled bridging (Settings -> Network Settings -> Enable bridging = No). After applying, br0 disappeared and my server IP (192.168.0.XX) moved to bond0, with the default route also via bond0 (confirmed with: ip -br addr / ip route). Unfortunately SMB write performance to \\server\\multimedia did not improve - it still sits around ~150 MB/s (sometimes lower), so it does not seem to be the exact same br0/bridging routing issue as in that topic. For reference, my routing table already has the local subnet via br0: 192.168.0.0/24 dev br0 default via 192.168.0.1 dev br0 I also noticed TcpRetransSegs increasing during slow copies (via nstat), while ip -s link shows 0 errors/dropped. iperf3 results (Unraid iperf3 server: iperf3 -s) Windows -> Unraid: iperf3.exe -c 192.168.0.XX -P 1 -t 30 ~2.33 Gbits/sec avg iperf3.exe -c 192.168.0.XX -P 4 -t 30 2.35 Gbits/sec sender / 2.35 Gbits/sec receiver Unraid -> Windows (-R): iperf3.exe -c 192.168.0.XX -P 4 -t 30 -R 2.34 Gbits/sec sender / 2.34 Gbits/sec receiver So raw TCP throughput over 2.5GbE looks good. SMB write to \\server\\multimedia still fluctuates around ~80-160 MB/s, which suggests the limitation is higher up the stack (SMB + shfs user share/union overhead and/or Samba behavior), not the link speed itself.

Symptom: - Copying from Windows to \\server\multimedia\... is inconsistent: ~80–160 MB/s (sometimes ~100 MB/s), even though files ultimately land on the NVMe cache pool (btrfs) and the link is 2.5GbE. - Depending on the path/folder, throughput can vary (sometimes I see ~220–230 MB/s in deeper subfolders). - Copying from the server to Windows is usually ~270 MB/s, so the issue seems specific to writes to the server. Environment: - Unraid 7.3.1 (same behavior observed on older Unraid versions as well) - Cache pool: NVMe (btrfs) - CPU: i5-12500, RAM: 48GB - NIC: Realtek RTL8125B 2.5GbE; tested r8169 and currently using r8125 (OOT driver) - MOBO: MSI MAG B660M MORTAR DDR4 - Bonding: bond0 active-backup (fault-tolerance), primary+active slave eth0 @ 2500 Mbps full duplex - Windows client: Windows 10 Hard facts / observations: 1) The "multimedia" share is not “exclusive” - it exists on multiple array disks (union via shfs/FUSE): /mnt/disk1/multimedia/ /mnt/disk2/multimedia/ /mnt/disk3/multimedia/ Example: the destination folder "Filmy Dokumentalne" exists on multiple disks at the same time: /mnt/disk1/multimedia/Filmy Dokumentalne/ /mnt/disk2/multimedia/Filmy Dokumentalne/ /mnt/disk3/multimedia/Filmy Dokumentalne/ 2) During slow copies, top CPU consumers are shfs and smbd (highest %CPU), suggesting a bottleneck in the user shares layer (shfs/FUSE/union) + Samba, not the NVMe itself. 3) The network interface shows no errors/drops: ip -s link show eth0 -> errors=0, dropped=0 4) TCP retransmits increase during the copy (nstat): after nstat -r, TcpRetransSegs increases during the transfer (e.g. 272 -> 295), while TcpExtTCPTimeouts = 0. Conclusion (hypothesis): - This looks like a combination of: a) shfs (user shares/union) overhead due to the share being spread across multiple disks, b) plus TCP retransmits, which may reduce SMB write speed to ~80–100 MB/s even when the interface itself shows no errors/drops. If needed, I can post diagnostics ZIP. Additionally, I had the same kind of issues on a different platform: - Motherboard: MSI B250M MORTAR - CPU: i7-7700 - RAM: 16GB DDR4 (single stick) - Storage: ~60TB HDD, 1TB NVMe, 1TB SSD

I updated from 7.2.4 to 7.3.1. After the update, I read your post and was a little worried because I have 4 Toshiba HDDs: 1x 18TB MG series, 2x 16TB MG series, and one 12TB N300. Fortunately, they are all working and spinning down fine. I haven’t had any issues with these drives. For context, I also have a PCIe to SATA adapter with a couple of drives connected to it. Additionally, I run Frigate, and recordings are saved to a separate Crucial SSD. Even this SSD successfully goes to sleep (spins down) without any issues. Only the NVMe cache stays active most of the time, but that's normal. BTW I disabled the two SATA ports on the ASMedia controller on my motherboard because of their poor power-saving capabilities. So, out of the six SATA ports on my motherboard, only four are working. Maybe check your sata ports. I should also mention that I run some fairly advanced custom scripts to force power-saving states (like PCIe ASPM and SATA DIPM) on my server. I’m not sure if actively forcing these power states is what helps my drives go to sleep successfully compared to a stock Unraid setup, but everything is working perfectly on my end.

The update from 7.2.4 to 7.3.1 went smoothly. I stuck with the standard USB setup, just like I’ve been doing for years. Before updating Unraid, as always, I updated the plugins, stopped all Docker containers, and prevented them from starting after the reboot. In addition, the Update Helper plugin automatically downloaded the latest update for Coral-Driver after 7.3.1 was installed. I also have some fairly advanced scripts that help me save power on my server. I disabled those scripts during the update as well, even though theoretically they shouldn’t cause any problems and are currently working.

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.

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.

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.

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: largeIn 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: 384When it comes to decoding, what works best for me is ffmpeg: hwaccel_args: preset-vaapi input_args: - -rtsp_transport - tcpIt is better optimized than quick sync.

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).

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: Two streams (directly from the camera): Result: Detects person, but never attempts face recognition. The process of taking a 4K snapshot silently fails. One stream (4K only) for detection and recording: Result: Face recognition WORKS CORRECTLY. Problem: Unacceptably high power consumption (~29W). 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). 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?

I currently have this set, but I want to buy something better for permanent face recognition for the main 4K stream from the camera, and in the future, more 4K cameras (20FPS). The goal here is to minimize power consumption. Mobo:MSI B250M MORTAR CPU:i7-7700 RAM:16GB DDR4 (1) 60TB HDD, 1TB nvme, 1TB SSD PSU:BE QUIET! Pure Power 11 400W 80 Plus Gold 3x120mm FAN Idle - ~22W. Frigate 4k 20FPS record, 720p substream face recognition 12FPS + objects ssdlite_mobilenet_v2 model - igpu/openvino - ~26W. Frigate 4k 20FPS record, 4k 5FPS face recognition - constantly jumps between 32W and 40W, which is too much. Especially when I add more 4K cameras, it will increase significantly. In the future, there will be a trigger and HA, which will minimize power consumption even further, but we are focusing on continuous face recognition in 4K and power consumption. I would prefer to buy the i5-13500 because of the Intel UHD Graphics 770, but I am concerned about stability issues during C - am I right? Does anyone have this CPU, with which motherboard, and what is its power consumption from the wall when idle? I think the safest option is the i5-12500 with the same igpu, but the processor itself is less efficient and less future-proof. I would like a motherboard with at least 6x SATA + preferably 2x m2 (I will accept 1x m2). Preferably with 2.5GbE Lan, because then I won't have to use my card and there will be an additional slot for SATA. DDR 4, because I have a lot of those chips. I am initially considering the MSI MAG B660M MORTAR. I have no idea how this motherboard performs in terms of power consumption. Can you recommend any proven motherboards and how much power your sets consume from the wall?

No, Frigate will not automatically download the model, but it has some in the container. I don't recommend trying yolo, because I had a lot of trouble with it, specifically with YOLOv8 (and a few others). Including the u8 != f32 error, I also had to do a lot of preprocessing here. My big problem was a non-standard directory for Config Path, which caused a lot of confusion in Frigate, although it shouldn't have. Currently, igpu works for me on the ssdlite_mobilenet_v2 model (FP16 precision IR model). This is a model from the Frigate documentation. I recommend testing on this model, I currently have Frigate 0.16-0. You also need to do the config. correctly and specify the path to the model /openvino-model/ssdlite_mobilenet_v2.xml. This model is physically located in the docker image layers. https://docs.frigate.video/configuration/object_detectors/#supported-models-2

I've been trying to set up Frigate with OpenVINO on my Unraid server and have been running into persistent stability issues with iGPU hardware acceleration. I'm hoping to share my findings in case it helps developers or other users. System Details: Unraid Version: 7.0.1 CPU: Intel® Core™ i7-7700 with HD Graphics 630 Docker: Frigate (latest stable) with OpenVINO detector Problem Description: The Frigate container starts fully with iGPU acceleration enabled, and I can even see the live camera feed for a short period (a few seconds). However, the container consistently crashes and restarts. The primary error in the Frigate logs is: frigate.watchdog INFO : Detection appears to have stopped. Exiting Frigate... This indicates that the OpenVINO detection process, running on the iGPU, is freezing or becoming unresponsive. Troubleshooting Steps Taken: I've followed all the standard recommendations to stabilize Intel iGPU passthrough on Unraid: Syslinux/Boot Parameters: Added intel_iommu=on iommu=pt i915.enable_guc=2 to the append line. Docker Container Settings: Set to Privileged: ON. Passed the device using Extra Parameters: --device=/dev/dri:/dev/dri. Increased shared memory with mount -o remount,size=1G /dev/shm. Frigate Config (config.yml): Used preset-vaapi for hwaccel_args. Configured the OpenVINO detector with device: iGPU. Despite all these measures, the setup remains unstable and crashes after a few minutes of operation. Working Solution (Workaround): The system is 100% stable when running Frigate in CPU-only mode: Docker container with Privileged: OFF and no extra device passthrough. Frigate config using type: cpu for the detector and no hwaccel_args. This confirms the issue is specifically related to the stability of the iGPU driver stack (i915/VAAPI/OpenVINO) within the Docker environment on Unraid. It seems like there might be a deeper conflict or a driver issue with this specific hardware/software combination. Has anyone else with a Kaby Lake (7th gen) CPU experienced similar iGPU freezes with hardware acceleration? I now have Unraid 7.1.4. I couldn't get it to work, even though I spent several hours trying. I went back to the CPU and it works. I'll probably try again with the igpu.

I had exactly the same thought as you regarding the Unraid upgrade. I also saw the changes related to the GPU and hoped that it would help. I now have Unraid 7.1.4. I couldn't do it, even though I spent several hours trying. I went back to the CPU and it works. I'll probably try again with the iGPU. I'll copy this post from above to the thread about Docker and Frigate.

We have the same problem, but I will also write in your thread, because maybe one of the developers or other experts will be able to solve it somehow. I've been trying to set up Frigate with OpenVINO on my Unraid server and have been running into persistent stability issues with iGPU hardware acceleration. I'm hoping to share my findings in case it helps developers or other users. System Details: Unraid Version: 7.0.1 CPU: Intel® Core™ i7-7700 with HD Graphics 630 Docker: Frigate (latest stable) with OpenVINO detector Problem Description: The Frigate container starts fully with iGPU acceleration enabled, and I can even see the live camera feed for a short period (a few seconds). However, the container consistently crashes and restarts. The primary error in the Frigate logs is: frigate.watchdog INFO : Detection appears to have stopped. Exiting Frigate... This indicates that the OpenVINO detection process, running on the iGPU, is freezing or becoming unresponsive. Troubleshooting Steps Taken: I've followed all the standard recommendations to stabilize Intel iGPU passthrough on Unraid: Syslinux/Boot Parameters: Added intel_iommu=on iommu=pt i915.enable_guc=2 to the append line. Docker Container Settings: Set to Privileged: ON. Passed the device using Extra Parameters: --device=/dev/dri:/dev/dri. Increased shared memory with mount -o remount,size=1G /dev/shm. Frigate Config (config.yml): Used preset-vaapi for hwaccel_args. Configured the OpenVINO detector with device: iGPU. Despite all these measures, the setup remains unstable and crashes after a few minutes of operation. Working Solution (Workaround): The system is 100% stable when running Frigate in CPU-only mode: Docker container with Privileged: OFF and no extra device passthrough. Frigate config using type: cpu for the detector and no hwaccel_args. This confirms the issue is specifically related to the stability of the iGPU driver stack (i915/VAAPI/OpenVINO) within the Docker environment on Unraid. It seems like there might be a deeper conflict or a driver issue with this specific hardware/software combination. Has anyone else with a Kaby Lake (7th gen) CPU experienced similar iGPU freezes with hardware acceleration?

I've been trying to set up Frigate with OpenVINO on my Unraid server and have been running into persistent stability issues with iGPU hardware acceleration. I'm hoping to share my findings in case it helps developers or other users. System Details: Unraid Version: 7.0.1 CPU: Intel® Core™ i7-7700 with HD Graphics 630 Docker: Frigate (latest stable) with OpenVINO detector Problem Description: The Frigate container starts fully with iGPU acceleration enabled, and I can even see the live camera feed for a short period (a few seconds). However, the container consistently crashes and restarts. The primary error in the Frigate logs is: frigate.watchdog INFO : Detection appears to have stopped. Exiting Frigate... This indicates that the OpenVINO detection process, running on the iGPU, is freezing or becoming unresponsive. Troubleshooting Steps Taken: I've followed all the standard recommendations to stabilize Intel iGPU passthrough on Unraid: Syslinux/Boot Parameters: Added intel_iommu=on iommu=pt i915.enable_guc=2 to the append line. Docker Container Settings: Set to Privileged: ON. Passed the device using Extra Parameters: --device=/dev/dri:/dev/dri. Increased shared memory with mount -o remount,size=1G /dev/shm. Frigate Config (config.yml): Used preset-vaapi for hwaccel_args. Configured the OpenVINO detector with device: iGPU. Despite all these measures, the setup remains unstable and crashes after a few minutes of operation. Working Solution (Workaround): The system is 100% stable when running Frigate in CPU-only mode: Docker container with Privileged: OFF and no extra device passthrough. Frigate config using type: cpu for the detector and no hwaccel_args. This confirms the issue is specifically related to the stability of the iGPU driver stack (i915/VAAPI/OpenVINO) within the Docker environment on Unraid. It seems like there might be a deeper conflict or a driver issue with this specific hardware/software combination. Has anyone else with a Kaby Lake (7th gen) CPU experienced similar iGPU freezes with hardware acceleration?

Unfortunately, I haven't tried it yet. I already have all the equipment, but at one point I need to have someone to help me stretch the cable and I haven't gotten around to it yet :) However, I suppose I will also have a problem with the configuration.

Thanks JorgeB, it is in progress

My empty Toshiba N300 12TB drive that I added a few weeks ago has stopped working (I have it from 2023). I will be sending the drive for warranty. Toshiba is sending a courier and the drive is going from me from Poland to Germany. I don't know how long it will take or what the finale will be. There was no data on the drive, except 230GB, which was added by the system. In Unraid I saw that the drive had over 2k errors and would not boot. The disk was making loud noises and I quickly shut down the server and pulled it out. Unfortunately, I did not withdraw it to “Unassigned Disks”. Faulty 12TB disk has in Unraid status "not installed". I want to remove this disk from Unraid and have parity protection on the 2x16TB disks where I have data. How do I go about this? Of course, I want to keep the data on the 2x 16TB and I want it to be protected by parity. What do I need to do? 1.)Stop Array 2.)Tools --> New Config And what to set there? In “Preserve current assignments:” 3.)Then I need to run the array and it will start rebuilding by itself with preservation of data? Will Jellyfin work during the rebuild?

bmartino1 thank you for your time and help. I currently have 1TB nvme m2 in Pool Devices for cache and apps. If I add 1TB SSD sata to Pool Devices will I somehow manage to use it only for CCTV/cameras? Will cache and apps not write to this new 1TB SSD sata drive? I want to use an SSD because I want low power consumption and silence. Currently my server in idle takes only ~23W from the wall, and I have 62TB hdd + 1TB nvme cache + 2.5GbE LAN+16GB ram + 3x120mm fans + i7-7700. Of course, if openVINO doesn't work out (or I can't handle the configuration) and the server draws too much power, I'll buy coral. I read somewhere that the power consumption is very similar coral vs openVINO. At the very end there is still the purchase of a dedicated DVR for the cameras, I already have one model in mind and even have a plan on how to convert it for lower power consumption.

I'd like to install one 4k camera to start with (if everything works out, I'll buy 2-3 more) I'm thinking of buying a Hikvision DS-2CD2087G2-L (if the model makes any difference) for camera surveillance in front of the house. 1.)Is there any tutorial on how to install and configure Frigate + OpenVINO. I have an i7-7700 2.)How do you advise to install SSD in Unraid under monitoring with Frigate? I don't want to add it to the array, will I be able to use it with Unassigned Devices, or do I need to add it to Pool Devices? 3.)Do you have any comparison of power consumption of Coral Mini PCIe vs OpenVINO (iGPU) and 1-4 4k cameras.