The live page can expose two entries for one match, an audio feed and a video
feed, and discovery returned whichever manifest loaded first. That race came
out differently twice on the same night: at 21:11 the page served the video
entry, at 22:30 the audio one. The scheduled run recorded audio against a video
pass, and nothing looked wrong -- it fails by producing a complete, playable,
healthy recording of the wrong thing.
--prefer cannot rescue that; it picks a rendition inside one master, after the
entry is already chosen. So add --feed, which chooses between entries:
video (default) prefer a video feed, fall back to audio
audio the reverse
any first discovered, the old behaviour
both record every feed in parallel
--entry <id> skip discovery and pin one
find_manifest now returns every entry it sees and keeps watching 15s past the
first hit, rather than returning on it. Each candidate is classified by the
codecs in its master, never by entry id -- ids name a feed, but relying on that
would bake in an observation that has already been wrong once.
A preference is not a filter. Non-preferred feeds stay on the list, because a
feed you hold no pass for resolves a master fine and only 403s later on the
segments; the recorder falls through to the next candidate when a download dies
immediately, so a wrong guess costs seconds rather than the match.
Output files are tagged -video / -audio, which matters once --feed both writes
two at once.
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
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
Mikkeli Matlock