Frigate detect/record pipeline jams under CPU starvation — needs a restart

On telep-mainframe, a sustained all-core CPU load (a 20-min power stress test) starved Frigate’s detect/record processes so hard that its frame queues and recording-segment cache jammed and did NOT self-recover even after the load dropped. The main-page live tiles went black and latest.jpg froze. Fix was a single sudo docker restart frigate.

For Agents

• The tell: curl http://127.0.0.1:5000/api/stats shows normal camera_fps (~5) but global detection_fps = 0.0, per-camera process_fps collapsed to ~0.1, and skipped_fps ≈ camera_fps. Log spam: frigate.record.maintainer WARNING: Too many unprocessed recording segments in cache for <cam>... This likely indicates an issue with the detect stream.
• The fix: sudo docker restart frigate — clears it instantly (process_fps → ~5, detection_fps → 113, warnings stop). Frigate does NOT recover on its own once the queues jam.
• per-camera detect_fps=None is a display quirk of this build — trust the global detection_fps, not the per-camera field.
• This is a DIFFERENT failure from the wedged-RTSP case in 2026-08-03-cam-stall-recovery-and-casino-alert: that one lives camera-side (a Frigate restart does NOT fix it, you reboot the camera over ONVIF). THIS one is server-side and a Frigate restart IS the fix.

Symptoms

• Frigate main-page live tiles go black; latest.jpg is frozen / identical across cameras.
• The TV camwall / anything downstream of the detect stream stalls.

Diagnosis — /api/stats

curl http://127.0.0.1:5000/api/stats:

metric	healthy	jammed
camera_fps	~5	~5 (still normal — capture is fine)
process_fps	~5	~0.1 (collapsed)
skipped_fps	~0	≈ camera_fps (every frame skipped)
global detection_fps	~113	0.0

Normal camera_fps with a collapsed process_fps = frames are being captured but not processed. Global detection_fps = 0.0 is the unambiguous “the detector is doing nothing” signal.

Log spam confirming the record side is also jammed:

frigate.record.maintainer WARNING: Too many unprocessed recording segments in cache
for <cam>... This likely indicates an issue with the detect stream

Root cause

A sustained all-core CPU load (a ~20-min power stress test — see 2026-08-06-power-root-cause-gpu-12v-connector-stress-test-pass) starved Frigate’s detect + record processes of CPU. The internal frame queues and the recording-segment cache backed up and jammed. Crucially it did NOT self-recover even after the load dropped: the frigate container was back to ~10% CPU and the box’s load was normal, but process_fps/detection_fps stayed pinned at ~0.

Fix

sudo docker restart frigate

Cleared it instantly: process_fps → ~5, global detection_fps → 113, the record.maintainer warnings stopped.

Prevention

Protect Frigate from heavy CPU jobs on this box

When running heavy CPU work on telep-mainframe, nice/ionice it so Frigate keeps its CPU share, then re-check /api/stats afterward — if detection_fps is 0, restart the container. This is the same class of “cap heavy jobs” hygiene that 2026-08-05-power-root-cause-nvme-damage-ups-kb-handover recommends for a different reason (mains stability).

Architecture note (this build)

Frigate detect/record stream topology

graph LR
    C1["Cam .119<br/><i>stream2</i>"] --> G["go2rtc restream<br/>rtsp://127.0.0.1:8554/camN_sub"]
    C2["Cam .139<br/><i>stream7</i>"] --> G
    G --> D["Frigate <b>detect</b><br/>ONNX ~15ms"]
    G --> R["Frigate <b>record</b><br/>segment cache"]
    style G fill:#264653,stroke:#2a9d8f,color:#fff
    style D fill:#2d2d2d,stroke:#888,color:#fff
    style R fill:#3d2020,stroke:#888,color:#fff

• 2 physical cameras (192.168.30.119, 192.168.30.139), streams stream2 / stream7, feed go2rtc’s internal restream (rtsp://127.0.0.1:8554/camN_sub).
• Frigate’s detect and record roles both pull from that go2rtc restream (not the cameras directly).
• Container image ghcr.io/blakeblackshear/frigate:stable-tensorrt; ports 5000 / 8971 bound to 127.0.0.1.
• Detector is ONNX (~15 ms inference).

Related

• 2026-08-06-power-root-cause-gpu-12v-connector-stress-test-pass — the stress test whose CPU load triggered this jam
• 2026-08-03-cam-stall-recovery-and-casino-alert — the OTHER camera-stall failure mode (wedged RTSP, camera-side; a Frigate restart does NOT fix that one)
• 2026-07-18-birdseye-nvenc-blue-glare — another “restart Frigate to clear a wedged pipeline” case (NVENC birdseye corruption)
• telep-mainframe — the host running Frigate + go2rtc
• [[telep-mainframe#the-stack-nvr|The stack (~/nvr)]] — the ~/nvr docker stack
• homelab
• LOG
• TOPICS