Two failure modes cost a match silently, and neither was detectable from
inside the recorder.
preflight.py: the session can be dead while every local signal looks fine --
right cookie, right expiry, right profile. Only the server knows. This spends
one request asking it to mint a JWT and exits non-zero if it will not, so a
dead login surfaces hours before kickoff instead of at it. Reports cookies and
tokens by length; it never prints a value.
watchdog.py: a scheduled launch has been seen to hang at interpreter startup,
alive but frozen before any of our code runs. So "is a recorder process
running" is the wrong question -- the hung process answers yes. This asks
whether recording is *progressing*, via a growing .ts or a freshly written
log, and only intervenes when both signals are stale. A healthy capture is
never interrupted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fr1fLMnVGNAKH5L2BmhMxn
The recorder passed no -f, so yt-dlp used its default, which prefers video.
That was never a decision: on 2 Sep the master held exactly one rendition, so
there was nothing to choose between. If a master ever carries a video variant
the account is not entitled to, the default would take it and 403 on segments.
--prefer audio|video|best makes it explicit. best keeps the old behaviour.
Every run now logs the renditions the master advertises, parsed from
EXT-X-STREAM-INF, so we build evidence about whether video and audio ever
appear together instead of assuming entitlement shapes the master.
Observed so far, both audio nights: one rendition, mp4a.40.2 at 140 kbps.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kyt7QHQvLJtQRuiY4wAqKB
The TLS-handshake explanation for the 403 was wrong. The split is by token
form, not by client: Python fetches the master (query token) fine and fails
only on the media playlist (path token). That is why record_live.py mints a
master and why --downloader ffmpeg is required.
"The stream never ends" was one video observation stated as a rule, and an
audio stream has since contradicted it by terminating cleanly well inside the
cap. Both are now recorded as single observations rather than conclusions.
Also records the state of play: unattended recording works, login has never
been tested, and the decision not to automate it -- the cookie outlives a
quarter, so automating the riskiest step to save four manual logins a year is
a bad trade.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kyt7QHQvLJtQRuiY4wAqKB
record_live.py runs the whole chain alone: headless browser only to learn the
entry id (it appears at runtime; static HTML has none when nothing is live),
then plain Python mints a fresh master playlist, then ffmpeg records.
No password needed. Firefox session cookies run to late November, well past
any kickoff, so the job authenticates from the stored session.
Three failures found by testing against a live feed rather than at kickoff:
- yt-dlp's native HLS downloader fetches variant playlists with Python and
gets 403/404 on path-token URLs. Forced --downloader ffmpeg; this is
required, not a preference.
- ffmpeg 4.3.1 has no -reconnect_on_network_error. Removed here and in
catcher.py, which had the same unsupported flag.
- A master playlist outlives its stream: after a match ends the master is
still served while its variants 404. So a found master does not mean a live
stream, and a downloader that dies immediately means "not up yet" rather
than "failed". It now retries until the wait window expires.
Untested: the actual segment download for an audio-only stream, because
nothing is live right now. Video was verified working on 29 Aug.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kyt7QHQvLJtQRuiY4wAqKB
Playwright discovery against the live feed found every link, then the whole
chain was replayed in plain urllib with no browser at all:
SSESS cookie -> GET /oauth/browser-token -> JWT (90 min)
JWT + x-api-key -> GET /v1/entry/{id} -> hdnts master URL (~25s)
master -> hdntl token (24h) -> ffmpeg
Both auth hops live off the Akamai CDN, so plain Python reaches them; ffmpeg
handles the CDN, which is the only host Python gets 403s from. Nothing needs
a fingerprint forged and Camoufox is now a fallback rather than the plan.
Two assumptions this disproved:
- The play click is not part of auth. Manifests arrive before any click, so
a headless run needs no interaction to mint a token.
- The 90 minute JWT does not constrain a 2 hour recording. It is spent before
ffmpeg starts; the 24h hdntl token carries the match.
discover.py drives the page with Playwright and identifies the mint and token
endpoints by what they RETURN rather than by guessing endpoint names, so it
survives the endpoints being renamed. It rides existing Firefox cookies and
needs no password. Verified working with --headless.
Sniffer v0.5 adds muted autoplay: the browser only has to trigger the manifest
fetch, ffmpeg records real audio separately, and muted autoplay is permitted
where audible is not. It stands down once playback starts, because the control
is a toggle and clicking twice would pause the recording.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kyt7QHQvLJtQRuiY4wAqKB
The feed switches to a static league slate and keeps serving at full CBR
bitrate. No end marker, and no stall to detect, so neither of the obvious
exit conditions fires. The duration cap is the only stop condition.
Observed on a live match: 116 min recorded, still running 2h04m after
kickoff, stopped manually.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kyt7QHQvLJtQRuiY4wAqKB
Verified end to end against a live match: 1080p H.264/AAC MPEG-TS at
~5.2 Mbit/s, recorded while the browser played the same stream.
Components:
- tampermonkey sniffer hooks fetch/XHR at document-start, captures the
manifest URL verbatim and POSTs it to the local catcher. v0.4 also traces
the API chain to find which call mints the token.
- catcher receives the URL and launches yt-dlp. Dedupes on the Kaltura asset
id and checks downloader liveness, so a mid-match page reload is both safe
and the recovery path for a dead downloader.
- creds stores secrets in the OS vault rather than a gitignored file, and
refuses to run on a backend that does not encrypt.
Protocol notes are in the README: the stream uses a two-stage token chain
(a ~25s hdnts token for the master playlist, a ~24h hdntl token for media),
concurrency is unrestricted, and the live window is ~30s with no DVR.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kyt7QHQvLJtQRuiY4wAqKB
Mikkeli Matlock