Files
bambuddy/backend/tests/unit
maziggy ce5f4e5f1a fix(camera): don't open competing socket while a viewer is attached (#1348)
Obico polling could freeze the live camera stream within seconds of opening
  the viewer. Cause: when the buffer-reuse path in obico_detection._capture_frame
  saw an empty _last_frames[printer_id] entry (stream startup before the first
  JPEG lands, or upstream mid-reconnect after a 30s read timeout), it fell
  through to capture_camera_frame_bytes() and opened a second RTSP socket. On
  firmwares that allow only one camera connection, that second socket forced
  the printer to drop the live fan-out connection - the viewer's ffmpeg then
  hit its own 30s timeout, looped through 30 reconnects at 0.2s, all racing
  the next Obico poll, and the broadcaster pump exited.

  Widen the gate from "do we have a buffered frame?" to "is any fan-out stream
  registered for this printer?". New is_stream_active() helper checks
  _active_streams / _active_chamber_streams independently of buffer state.
  _capture_frame consults it first: if a viewer is attached, it returns the
  buffered frame when available or None (skip this poll cycle) when not. Never
  opens a competing socket while a viewer is connected.

  Cost: at most one missed Obico detection cycle per viewer-attach (~10s lag).
  Benefit: zero competing-socket events while any viewer is connected.

  try_get_active_buffered_frame() refactored to delegate to is_stream_active()
  so the two helpers stay in lockstep. The /camera/snapshot caller is unchanged
  behaviorally (snapshot is a user-initiated single-shot; falling through to
  fresh capture on an empty buffer is the desired behavior there).
2026-05-16 12:31:11 +02:00
..
.
2026-04-12 14:16:17 +02:00