[Recording] Log a per-speaker captured/expected ratio so a timeline regression is one grep away #327
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Severity: MEDIUM. Found in the August 2026 session lifecycle review (#319).
Why
The dev stack cannot exercise the Discord bot at all (no token), so the capture fix is prod-only to verify end to end. It needs a tripwire that proves itself on the first real session without anyone inspecting audio.
The data has always been there and was never compared.
close()already logsfile_bytesper user (recording.py:236-240) and the upload already logs the wall-clockduration(recording.py:733-736) — into the same log stream, never diffed. Meanwhile the live dashboard has been publishingseconds_capturednext toelapsed_secondsevery two seconds since the feature shipped (services/recording_status.py:7,26,54). The smoking gun was on screen the whole time.Proposed fix
close(), log per user:expected_bytes = duration_s * 192000,written_bytes, andratio. One grep after the first post-deploy session proves the fix (ratio ~1.0) or disproves it (ratio ~0.2). This requires passingduration_sorstarted_atinto the sink — currently absent, which is itself telling.seconds_capturedvselapsed_secondsdivergence on the recording dashboard as a visible warning rather than two numbers a human has to compare.jitter_synthetic_packets,opus_decode_ok/err,rtp_unknown_ssrc_dropped) available viavc.get_recv_diagnostics(), which the bot never surfaces.Acceptance criteria
close()logs expected/written/ratio per speakerget_recv_diagnostics()counters are logged at stopdocs/OPERATIONS.mdas the post-deploy verification step for the capture fixShipped — closing as part of a v3.11.5 bookkeeping sweep.
bot/questboard_bot/cogs/recording.py:356, inclose():It logs
written_bytes / expected_bytesper speaker and raises anAUDIO_DIAG short_trackwarning below 0.9.services/recording_status.py:30carries the live counterpart, distinguishing track position (silence included) from decoded speech.The design intent held: the ratio is exactly the signal that made #320 diagnosable after the fact, and it is why a regression would now be one grep rather than another lost session.