跳过正文

Frigate

摄像头崩溃级联排查:LLM 每日健康检查如何发现一个隐藏的 Frigate Bug

每日 LLM 健康检查报告显示 10 台摄像头中有 8 台当天崩溃次数达到数百次。 追查下去,根因是两台婴儿监控摄像头、一个 go2rtc 重连窗口,以及一次 vaapi 级联崩溃——没有一个环节是直接显而易见的。以下是完整的排查与修复过程。 问题是如何发现的 # 我在搭建一个每日家庭健康代理——一个定时脚本,查询所有家庭服务(Frigate、Home Assistant、Paperless、arr 媒体栈),然后将数据交给本地 LLM 分析。核心思路是:不再手动逐个检查仪表盘,而是每天早上收到一份摘要,自动标出异常项。 Frigate 的检查项查询 /api/stats,提取每台摄像头的崩溃次数。某天早上,报告返回了这样的数据: 1 2 3 4 5 6 nanit_adelia: 2228 次崩溃 nanit_leonard: 2228 次崩溃 backyard: 847 次崩溃 front_door: 391 次崩溃 side_a: 203 次崩溃 ... 如果没有健康检查,我根本不会注意到——Frigate 容器本身从未重启,Web UI 上各摄像头仍然显示"在线",也没有任何告警弹出。 根因:崩溃级联 # 顺着日志往前追,每天上午 9 点的事件链如下:

Frigate 换用 YOLOv9t + OpenVINO(Intel N97)

将 Frigate 默认的 SSD MobileNet 检测器替换为 YOLOv9t(tiny),通过 OpenVINO 运行在 Intel N97 的核显上。涵盖模型导出、正确的 Frigate 配置,以及一个会导致 100% 误报的关键坑。 环境 # 服务器: Intel N97(Debian 13),8 路摄像头 Frigate: 0.17,Docker 运行 检测器: OpenVINO GPU(/dev/dri/renderD128) 原模型: SSD MobileNet v2(内置,300×300) 新模型: YOLOv9t ONNX(320×320,8.3 MB) 为什么换 YOLOv9t? # Frigate OpenVINO 镜像自带的 SSD MobileNet v2 速度快、资源占用低,但对画面边缘目标和部分遮挡目标的识别能力较弱。YOLOv9t(tiny)在精度上有明显提升,计算量却相差不大——在 320×320 输入、N97 核显约 18ms 推理速度下,跑 8 路摄像头完全够用。

Frigate NVR 配置全记录:从 Docker 到 HA 推送通知

在 Debian 服务器(Intel N97)上部署 Frigate NVR,替代传统 NVR 的检测功能。 涵盖 Docker Compose、go2rtc 流配置、硬件加速、HA 集成、推送通知及基于区域的告警。 VLAN 间流量经由主路由器(UCG Ultra)转发。 硬件与背景 # 服务器: Intel N97 迷你主机(debian.lan,10.0.10.11),Debian 13 摄像头: 8 台 Reolink PoE 摄像头(摄像头 VLAN,10.0.40.0/24),2 台 Nanit 婴儿监控器(IoT VLAN,10.0.20.0/24) 现有 NVR: 保留运行,负责持续录像;Frigate 专注于检测和事件片段 Home Assistant: 位于 IoT VLAN(10.0.20.10),已运行 MQTT Broker 存储设计 # 录像存储在 NAS 专用共享目录,避免占用本地 NVMe。