[Bug] Pinned Linux FFmpeg build disappears under BtbN retention policy (from issue #521)

[amansingh-121]

Tracked from issue #521: #521

Summary: HFlow-reviewed pinned BtbN FFmpeg build (autobuild-2026-08-16-13-00) now returns HTTP 404, so the default Linux FFmpeg provisioning path fails before the first video operation runs. BtbN retains only the last 14 daily builds, so the pin can rot again.

Context: On a fresh Linux setup (Arch, system FFmpeg n8.0.1) the Egocentric-10K corpus prepares successfully using HFLOW_FFMPEG=/usr/bin/ffmpeg (96/96 episodes), confirming the failure is isolated to FFmpeg provisioning, not the dataset path.

Open directions:

• Pin a BtbN asset with a documented long retention lifetime (the last build of each month is kept for two years).
• Mirror the exact pinned artifacts somewhere whose retention HFlow controls.
• Run the opt-in HFLOW_NETWORK_TESTS=1 download test periodically to catch a dead pin before users hit it.

Deliberately not falling back silently to system FFmpeg, since HFlow pins FFmpeg for reproducibility.

[Sagar-024]

Great catch, @amansingh-121, this is a textbook case of a supply-chain rot and you are absolutely right that silently falling back to system FFmpeg breaks the reproducibility promise.

Of your three options, I think combining option 1 + option 3 is the best course of action in the short term

1. Pin a monthly BtbN build — the end-of-month builds are kept for much longer (usually years), and swapping the pin from a daily autobuild to the latest monthly release will immediately fix the 404

2. Add an opt-in network test — adding a light HFLOW_NETWORK_TESTS=1 check will let us know when the next pin rot will occur before a user hits it in the wild.

Mirroring the builds to HFlow's GitHub releases (option 2) is ideal, but is a bit more infra-heavy and can be considered as a follow-up once the monthly pins become a thing.

Would you be open to open a PR that updates the pin to the latest monthly build and adding the network test? I would be happy to review and help test it across the provisioning paths.

[kstonekuan]

This landed in #526 on 2026-09-13.

The pin is now autobuild-2026-08-31-13-27, the last August build rather than a mid-month daily, and .github/workflows/pinned-assets.yml checks both Linux assets every Monday. First scheduled run passed on 2026-09-14, and both assets return 200 right now.

Thanks for working it through here.