A daily LLM-powered health check flagged that 8 out of 10 cameras had crash counts in the hundreds. The root cause turned out to be two baby monitor cameras, a go2rtc reconnect window, and a vaapi cascade failure — none of which were directly obvious. Here’s how we found it and fixed it.
How the Issue Was Found # I’ve been building a daily home health agent — a scheduled script that queries all home services (Frigate, Home Assistant, Paperless, the arr stack) and passes the data to a local LLM for analysis. The idea: instead of manually checking dashboards, get a morning summary that flags anything unusual.
Replacing Frigate’s default SSD MobileNet detector with YOLOv9t (tiny) running on the Intel N97’s integrated GPU via OpenVINO. Covers model export, correct Frigate config, and a critical gotcha that causes 100% false positives if you get it wrong.
Setup # Server: Intel N97 (Debian 13), 8 camera streams Frigate: 0.17, running in Docker Detector: OpenVINO GPU (/dev/dri/renderD128) Previous model: SSD MobileNet v2 (built-in, 300×300) New model: YOLOv9t ONNX (320×320, 8.3 MB) Why YOLOv9t? # The default SSD MobileNet v2 bundled with Frigate’s OpenVINO image is fast and lightweight, but accuracy suffers on partially occluded objects and objects at the edges of the frame. YOLOv9t (tiny) offers meaningfully better detection quality with a similar computational footprint — at 320×320 input and ~18ms inference on the N97 iGPU, it handles 8 concurrent camera streams comfortably.
This post is a complete runbook for integrating AI-powered auto-tagging and classification into paperless-ngx using paperless-ai and a locally-running Ollama instance. The setup uses a local LLM to read document text and automatically populate metadata fields — title, document type, tags, correspondent, date, and custom fields.
Hardware and Architecture # NAS (Synology DS1621+, 10.0.10.10): runs paperless-ngx on port 5656 Desktop PC: Windows with WSL2, Docker Desktop, RTX 4090 Goal: AI auto-tagging/classification using a local LLM, zero cloud dependency The key architecture decision is a pull model: paperless-ai runs in WSL2 Docker, polls the paperless-ngx API for documents tagged ai-pending, processes them with Ollama, and writes metadata back. This is the correct approach for a desktop that is not on 24/7 — the NAS holds the queue and the desktop drains it when available.
Runbook and design journal for migrating ~400 personal documents from a folder-based Google Drive system into Paperless-ngx on a Synology NAS. Covers taxonomy design, bulk import from Google Takeout, ML classifier setup, and ongoing intake workflow.
Problem Statement # For years my “document management” was a manually maintained folder tree on 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 - 旅行计划/ This worked well enough for filing but poorly for retrieval. Finding “what insurance forms did I have in 2022?” meant navigating six folders and guessing what I named things. Paperless-ngx offers full-text search, OCR, and an ML classifier that learns from your own labeling — a meaningfully better system for a document archive that spans immigration paperwork, tax filings, mortgage docs, and medical records across 10+ years.
Runbook for setting up AirPrint on a Synology NAS so iOS/macOS devices can print to a USB or network printer over the local network. Uses a Docker CUPS container and Synology’s built-in avahi (mDNS) daemon for service discovery.
Architecture # 1 2 3 4 5 6 7 8 9 10 11 iPhone │ mDNS discovery (_ipp._tcp) ▼ Synology avahi-daemon (eth4, port 5353) │ reads service files from /etc/avahi/services/ │ CUPS Docker container (host network, port 631) │ generates /etc/avahi/services/AirPrint-*.service │ proxies print jobs to printer ▼ Printer (e.g. socket://10.0.20.50:9100) Key design decisions:
Personal runbook for migrating a family photo library from Synology Photos to a self-hosted Immich instance. Covers bulk upload, Google Takeout import, and album reconstruction via the Synology PostgreSQL database.
Setup # Source: Synology NAS running Synology Photos (multiple users) Destination: Immich self-hosted on the same NAS Upload tool: immich-go v0.31+ Client: WSL2 on Windows, SSH access to NAS Album script: custom Python (migrate_albums.py) using Immich REST API Phase 1: Photo Uploads # Strategy # Two sources per user: