update recordings docs

docs/docs/troubleshooting/recordings.md

@@ -80,3 +80,85 @@ Some users found that mounting a drive via `fstab` with the `sync` option caused
 #### Copy Times < 1 second
 
 If the storage is working quickly then this error may be caused by CPU load on the machine being too high for Frigate to have the resources to keep up. Try temporarily shutting down other services to see if the issue improves.
+
+## I see the message: WARNING : Too many unprocessed recording segments in cache for camera. This likely indicates an issue with the detect stream...
+
+This warning means that the detect stream for the affected camera has fallen behind or stopped processing frames. Frigate's recording cache holds segments waiting to be analyzed by the detector — when more than 6 segments pile up without being processed, Frigate discards the oldest ones to prevent the cache from filling up.
+
+:::warning
+
+This error is a **symptom**, not the root cause. The actual cause is always logged **before** these messages start appearing. You must review the full logs from Frigate startup through the first occurrence of this warning to identify the real issue.
+
+:::
+
+### Step 1: Get the full logs
+
+Collect complete Frigate logs from startup through the first occurrence of the error. Look for errors or warnings that appear **before** the "Too many unprocessed" messages begin — that is where the root cause will be found.
+
+### Step 2: Check the cache directory
+
+Exec into the Frigate container and inspect the recording cache:
+
+```
+docker exec -it frigate ls -la /tmp/cache
+```
+
+Each camera should have a small number of `.mp4` segment files. If one camera has significantly more files than others, that camera is the source of the problem. A problem with a single camera can cascade and cause all cameras to show this error.
+
+### Step 3: Verify segment duration
+
+Recording segments should be approximately 10 seconds long. Run `ffprobe` on segments in the cache to check:
+
+```
+docker exec -it frigate ffprobe -v error -show_entries format=duration -of default=noprint_wrappers=1 /tmp/cache/<camera>@<segment>.mp4
+```
+
+If segments are only ~1 second instead of ~10 seconds, the camera is sending corrupt timestamp data, causing segments to be split too frequently and filling the cache 10x faster than expected.
+
+**Common causes of short segments:**
+
+- **"Smart Codec" or "Smart+" enabled on the camera** — These features dynamically change encoding parameters mid-stream, which corrupts timestamps. Disable them in your camera's settings.
+- **Changing codec, bitrate, or resolution mid-stream** — Any encoding changes during an active stream can cause unpredictable segment splitting.
+- **Camera firmware bugs** — Check for firmware updates from your camera manufacturer.
+
+### Step 4: Check for a stuck detector
+
+If the detect stream is not processing frames, segments will accumulate. Common causes:
+
+- **Detection resolution too high** — Use a substream for detection, not the full resolution main stream.
+- **Detection FPS too high** — 5 fps is the recommended maximum for detection.
+- **Model too large** — Use smaller model variants (e.g., YOLO `s` or `t` size, not `e` or `x`). Use 320x320 input size rather than 640x640 unless you have a powerful dedicated detector.
+- **Virtualization** — Running Frigate in a VM (especially Proxmox) can cause the detector to hang or stall. This is a known issue with GPU/TPU passthrough in virtualized environments and is not something Frigate can fix. Running Frigate in Docker on bare metal is recommended.
+
+### Step 5: Check for GPU hangs
+
+On the host machine, check `dmesg` for GPU-related errors:
+
+```
+dmesg | grep -i -E "gpu|drm|reset|hang"
+```
+
+Messages like `trying reset from guc_exec_queue_timedout_job` or similar GPU reset/hang messages indicate a driver or hardware issue. Ensure your kernel and GPU drivers (especially Intel) are up to date.
+
+### Step 6: Verify hardware acceleration configuration
+
+An incorrect `hwaccel_args` preset can cause ffmpeg to fail silently or consume excessive CPU, starving the detector of resources.
+
+- After upgrading Frigate, verify your preset matches your hardware (e.g., `preset-intel-qsv-h264` instead of the deprecated `preset-vaapi`).
+- For h265 cameras, use the corresponding h265 preset (e.g., `preset-intel-qsv-h265`).
+- Note that `hwaccel_args` are only relevant for the detect stream — Frigate does not decode the record stream.
+
+### Step 7: Verify go2rtc stream configuration
+
+Ensure that the ffmpeg source names in your go2rtc configuration match the correct camera stream. A misconfigured stream name (e.g., copying a config from one camera to another without updating the stream reference) will cause the wrong stream to be used or the stream to fail entirely.
+
+### Step 8: Check system resources
+
+If none of the above apply, the issue may be a general resource constraint. Monitor the following on your host:
+
+- **CPU usage** — An overloaded CPU can prevent the detector from keeping up.
+- **RAM and swap** — Excessive swapping dramatically slows all I/O operations.
+- **Disk I/O** — Use `iotop` or `iostat` to check for saturation.
+- **Storage space** — Verify you have free space on the Frigate storage volume (check the Storage page in the Frigate UI).
+
+Try temporarily disabling resource-intensive features like `genai` and `face_recognition` to see if the issue resolves. This can help isolate whether the detector is being starved of resources.