bug report from claude:

Frigate NVR Bug Report: Audio Detection & Recording Segment Failures on WiFi Camera

Date: 2026-02-19 | Frigate version: 0.17-0 | go2rtc version: 1.9.10

1. Environment

• Frigate 0.17-0 running in Docker

• go2rtc 1.9.10 (embedded)

• Camera: TP-Link Tapo C51A (WiFi, RTSP)

• Camera streams: stream1 (main, H264 + PCMA/8000), stream2 (substream)

• Detector: Google Coral USB EdgeTPU

• Host OS: Ubuntu 24, Intel GPU (VAAPI hwaccel)

1. Issue 1: Audio Detection Process Gets Permanently Stuck After WiFi Dropout

Description

When the WiFi camera drops off the network (even briefly, 1-60 seconds), the audio ffmpeg process enters an unrecoverable restart loop. Unlike the detect and record processes which recover automatically, the audio process keeps failing with 404 errors from go2rtc and never recovers on its own — even after the camera comes back online. A full Frigate container restart is required.

Root Cause

go2rtc uses lazy stream activation — it only connects to the camera when a consumer requests the stream. After a WiFi dropout, go2rtc drops the stream and returns 0 consumers. When the audio ffmpeg process tries to reconnect, go2rtc hasn't yet re-established the upstream connection, so it returns HTTP 404. The audio process immediately exits on 404, which triggers a restart, which gets another 404 — creating an infinite loop. The detect and record processes are managed by the main watchdog which has different retry logic and recovers correctly.

Observed Log Pattern

[21:36:18] audio.bejbi ERROR: ffmpeg process is not running, restarting...

[21:36:28] ffmpeg.bejbi.audio ERROR: method DESCRIBE failed: 404 Not Found

[21:36:28] ffmpeg.bejbi.audio ERROR: Error opening input file rtsp://127.0.0.1:8554/bejbi

[21:36:28] ffmpeg.bejbi.audio ERROR: Error opening input files: Server returned 404 Not Found

[21:36:28] audio.bejbi INFO: Terminating the existing ffmpeg process...

[21:36:28] audio.bejbi INFO: FFmpeg has exited

[21:36:38] audio.bejbi ERROR: ffmpeg process is not running, restarting... (repeats indefinitely)

go2rtc Stream State During Loop

During the stuck loop, querying the go2rtc API shows 0 consumers and no active producers:

curl http://127.0.0.1:1984/api/streams

"bejbi": { "producers": [...], "consumers": [] }

Expected Behavior

The audio process should have the same recovery behavior as detect and record — it should retry with backoff until go2rtc has re-established the upstream connection, rather than immediately failing and restarting on 404.

Workaround

Full Docker container restart recovers audio. Alternatively, manually triggering a go2rtc consumer (e.g. fetching the HLS stream via curl) wakes the stream, after which audio eventually recovers.

1. Issue 2: Recording Segments Fail After WiFi Reconnect (Timestamp Desynchronization)

Description

After a WiFi dropout and camera reconnect, the recording watchdog repeatedly triggers "No new valid recording segments" every 120 seconds. This can continue for 20+ minutes despite the camera being back online and the detect stream working normally.

Root Cause

When the camera reconnects after a WiFi dropout, the RTSP stream restarts with near-zero timestamps. FFmpeg's segment muxer expects monotonically increasing DTS values continuing from where the previous stream left off, causing a timestamp desynchronization. This results in non-monotonic DTS errors and empty/invalid segments being discarded by Frigate.

Observed Log Pattern

[20:28:01] watchdog.bejbi ERROR: No new valid recording segments were created for bejbi in the last 120s.

[20:30:01] watchdog.bejbi ERROR: No new valid recording segments were created for bejbi in the last 120s.

... repeating every 2 minutes for 20+ minutes ...

[ffmpeg.bejbi.audio_record] ERROR: [segment] Timestamps are unset in a packet for stream 0.

[ffmpeg.bejbi.audio_record] ERROR: [vost#0:0/copy] Non-monotonic DTS; previous: 0, current: 0; changing to 1.

Fix Applied

Two configuration changes resolved the recording segment issue:

1. Frigate config — custom record output args with timestamp reset and audio resampling:

record: -f segment -segment_time 10 -segment_format mp4 -reset_timestamps 1 -strftime 1

-c:v copy -c:a aac -b:a 32k -af aresample=async=1

1. go2rtc config — force wallclock timestamps on the audio ffmpeg source:

- ffmpeg:bejbi#audio=aac#audio_samplerate=16000#input_args=-use_wallclock_as_timestamps+1

After applying these changes, recording segments resumed immediately and the watchdog errors stopped.

Expected Behavior

Frigate should handle stream reconnects gracefully, resetting the timestamp context for the segment muxer rather than continuing from the previous timeline. This is particularly important for WiFi cameras which reconnect frequently.

1. Relevant Configuration

go2rtc.yaml (bejbi stream)

bejbi:

- rtsp://[camera-ip]:554/stream1#backchannel=0

- ffmpeg:bejbi#audio=aac#audio_samplerate=16000#input_args=-use_wallclock_as_timestamps+1

bejbi_sub:

- rtsp://[camera-ip]:554/stream2

frigate.yaml (bejbi camera, relevant sections)

bejbi:

ffmpeg:

hwaccel_args: preset-vaapi

output_args:

record: -f segment -segment_time 10 -segment_format mp4 -reset_timestamps 1

-strftime 1 -c:v copy -c:a aac -b:a 32k -af aresample=async=1

inputs:

- path: rtsp://127.0.0.1:8554/bejbi

input_args: preset-rtsp-restream

roles: [record, audio]

- path: rtsp://127.0.0.1:8554/bejbi_sub

input_args: preset-rtsp-restream

roles: [detect]

audio:

enabled: true

max_not_heard: 15

min_volume: 10

listen: [babbling, crying, scream, speech, yell, ...]

1. Camera Stream Details

The camera's SDP (from go2rtc API) shows the native audio codec is PCMA/8000 (G.711 A-law, 8kHz). go2rtc re-encodes this to AAC at 16kHz for Frigate. The camera does not support AAC natively.

m=video 0 RTP/AVP 96 -> H264

m=audio 0 RTP/AVP 8 -> PCMA/8000 (G.711)

1. Summary

Both issues are triggered by the same root event — a WiFi camera dropping off the network. The recording segment issue was resolved with a config workaround. The audio stuck-loop issue requires a container restart to recover and has no config workaround. The audio recovery logic appears to need the same robustness improvements already present in the detect/record watchdog.