Skip to main content

Docker

Fixing a Camera Crash Cascade: How an LLM Health Check Found a Hidden Frigate Bug

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.

Frigate NVR Setup: From Docker to HA Notifications

Setting up Frigate NVR on a dedicated Debian server (Intel N97) to replace a traditional NVR. Covers Docker compose, go2rtc stream config, hardware acceleration, HA integration, push notifications, and zone-based alerting. Traffic between VLANs goes through the main router (UCG Ultra). Hardware & Context # Server: Intel N97 mini PC (debian.lan, 10.0.10.11), Debian 13 Cameras: 8 Reolink PoE cameras on camera VLAN (10.0.40.0/24), 2 Nanit monitors on IoT VLAN (10.0.20.0/24) Existing NVR: kept running for continuous recording; Frigate handles detection and event clips only Home Assistant: on IoT VLAN (10.0.20.10), MQTT broker already running Storage Design # Frigate recordings go to a dedicated NAS share — no local NVMe waste for surveillance video.

AI-Powered Document Classification with paperless-ai and Ollama

·2743 words·13 mins
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.

Paperless-ngx: Migrating a Decade of Documents from Google Drive

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.

AirPrint on Synology NAS via CUPS Docker

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: