A P2S support bundle on 0.2.5b1 — per-model probesize fix already
applied — showed the camera still failing: ffmpeg connects, stays alive
30+ seconds, emits zero JPEG bytes, the 30s stdout.read times out,
reconnect loop repeats. No ffmpeg stderr appeared anywhere in the log to
explain why.
The cause was a diagnostic bug, not the camera path. _read_ffmpeg_stderr
called process.stderr.read() — read-to-EOF. A stalled-but-still-alive
ffmpeg (the P2S RTSP failure mode) never closes stderr, so the read
blocked until the 2s wait_for timeout and returned None, discarding the
banner + stream-analysis lines ffmpeg had already printed. ffmpeg stderr
was captured only when it fully exited; once the probesize bump turned
the earlier crash into a hang, the diagnostic went dark.
Drain stderr incrementally in bounded 8KB chunks (64KB cap), returning
whatever ffmpeg printed so far whether or not it has exited. Also log
the resolved per-model probesize/analyzeduration on the info-level
"Starting RTSP camera stream" line, and log the full ffmpeg argv at
debug level with only the credential-bearing camera URL redacted
instead of hiding the entire command.
No behaviour change to streaming — this makes the unresolved P2S RTSP
stall diagnosable in the next support bundle.
Two bugs surfaced while investigating camera reconnect behaviour in #925.
The camera page briefly displayed "Reconnecting attempt 6 of 5" before
giving up, because the attempt counter could be incremented to the
maximum while the reconnect banner was still rendering. The displayed
value is now clamped to the configured maximum.
Every failed ffmpeg spawn logged the full ~20-line ffmpeg version,
configuration, and lib* banner, producing hundreds of lines of noise
per failed camera click (one reported click produced 555 log lines
across 30 retries). A new _summarize_ffmpeg_stderr helper strips the
banner and caps output at the last 10 meaningful lines, applied at
all three stderr log sites (immediate-failure, stream-ended,
read-timeout). Covered by unit tests for empty input, banner
stripping, line cap, blank-line filtering, and banner-only input.
The underlying "camera service stops accepting connections after
prolonged uptime" behaviour in the X1C firmware is still under
investigation — these two fixes are independent of that root cause.
maziggy