Self-Hosted on Yang's Notes

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

yang@yhu.me (Yang Hu) — Fri, 03 Apr 2026 00:00:00 -0800

每日 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）

yang@yhu.me (Yang Hu) — Thu, 19 Mar 2026 00:00:00 -0800

将 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 路摄像头完全够用。

使用 paperless-ai 与 Ollama 为 paperless-ngx 添加 AI 文档分类功能

yang@yhu.me (Yang Hu) — Thu, 12 Mar 2026 00:00:00 -0800

本文是一份完整的操作手册，介绍如何通过 paperless-ai 和本地运行的 Ollama 为 paperless-ngx 集成 AI 自动标签和分类功能。整套方案使用本地大语言模型读取文档文本，自动填充元数据字段——包括标题、文档类型、标签、联系人、日期以及自定义字段。

硬件与架构
#

NAS（群晖 DS1621+，10.0.10.10）：在 5656 端口运行 paperless-ngx
台式 PC：Windows，安装了 WSL2、Docker Desktop，配备 RTX 4090
目标：使用本地 LLM 实现 AI 自动打标/分类，零云端依赖

核心架构决策是拉取模式（pull model）：paperless-ai 运行在 WSL2 的 Docker 容器中，轮询 paperless-ngx API 寻找带有 ai-pending 标签的文档，调用 Ollama 处理后将元数据写回。对于不是 24 小时开机的台式机而言，这是最正确的方案——NAS 保存待处理队列，台式机开机后自动消费。

1
2
3
4
5
6
7


paperless-ngx (NAS)
 ↑ ↓ (REST API)
 paperless-ai (WSL2 Docker)
 ↑ ↓ (HTTP)
 Ollama (Windows 原生)
 ↑
 RTX 4090 (GPU)

Ollama 以原生方式运行在 Windows 上（而非 WSL 内），以获得最佳 GPU 访问性能。在 WSL2 的 Docker 容器内，通过特殊主机名 host.docker.internal 访问 Ollama。

用 Paperless-ngx 整理十年文档：从 Google Drive 文件夹到全文检索归档库

yang@yhu.me (Yang Hu) — Wed, 11 Mar 2026 00:00:01 -0800

将近十年积累的个人文档从 Google Drive 文件夹体系迁移到 Paperless-ngx 的完整记录。涵盖分类体系设计、从 Google Takeout 批量导入、ML 分类器训练，以及日常收件箱工作流。

为什么要迁移
#

过去多年，我的"文档管理"是一棵手工维护的 Google Drive 文件夹树：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


10 - 文书材料/
 10 - 证件材料/身份证件/
 30 - 移民文档/
 30 - Tax Filing/
 40 - Finance/
 50 - 车辆注册/
 60 - 住房买房/
 80 - Medical/
20 - 家装住房信息/
80 - 旅行计划/

归档时还算顺手，但检索很痛苦。想找"2022 年的保险表格"，要翻六个文件夹，还得猜当时的命名。 Paperless-ngx 提供全文检索、OCR、以及会从你自己的标注中学习的 ML 分类器—— 对于横跨移民手续、税务申报、房产合同、医疗记录的文档库来说，这是本质性的提升。

在 Synology NAS 上通过 CUPS Docker 实现 AirPrint

yang@yhu.me (Yang Hu) — Wed, 11 Mar 2026 00:00:00 -0800

在 Synology NAS 上配置 AirPrint 的操作手册，让 iOS/macOS 设备可以通过局域网打印到 USB 或网络打印机。使用 Docker CUPS 容器和 Synology 内置的 avahi（mDNS）守护进程实现服务发现。

架构
#

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


iPhone
 │ mDNS 发现 (_ipp._tcp)
 ▼
Synology avahi-daemon（eth4，端口 5353）
 │ 从 /etc/avahi/services/ 读取服务文件
 │
CUPS Docker 容器（host 网络模式，端口 631）
 │ 生成 /etc/avahi/services/AirPrint-*.service
 │ 将打印任务代理到打印机
 ▼
打印机（如 socket://10.0.20.50:9100）

关键设计决策：

Synology Photos 迁移到 Immich 操作手册

yang@yhu.me (Yang Hu) — Mon, 09 Mar 2026 00:00:00 -0800

将家庭相册从 Synology Photos 迁移到自托管 Immich 实例的个人操作手册。涵盖批量上传、Google Takeout 导入，以及通过 Synology PostgreSQL 数据库重建相册。

环境说明
#

来源：运行 Synology Photos 的 Synology NAS（多用户）
目标：同一 NAS 上自托管的 Immich
上传工具：immich-go v0.31+
客户端：Windows 上的 WSL2，SSH 访问 NAS
相册脚本：自定义 Python（migrate_albums.py），使用 Immich REST API

第一阶段：照片上传
#

策略
#

每位用户有两个来源：

Self-Hosted on Yang's Notes

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

问题是如何发现的 #

根因：崩溃级联 #

Frigate 换用 YOLOv9t + OpenVINO（Intel N97）

环境 #

为什么换 YOLOv9t？ #