coinosv3.git/tools/feed-media-cache-test.js, branch fdroid-v1.9

Video frames from bytes, not from a CORS player; pager clips load plainly again

2026-10-03T22:52:38Z

Regression from 6488806: pager clips were loaded crossorigin so their frame could be kept, and on a phone the large clip's slide went black. Some hosts (Primal's R2 bucket) send CORS headers only to a request with an Origin and don't Vary on it, so a copy the browser cached from a plain player load answers a later CORS load without them, and it fails. The same thing made the size probe fail for any clip that had played in the feed. - Pager clips load plainly again; the still under a tap-to-play cover is restored on every return. - The probe (and its HEAD) go past the browser cache (no-store). - A clip's frame is now made from bytes: the opening of the file (index plus about 1 MB, no-store) decoded from a blob and kept as a JPEG — for tiles and as the pager's poster. No CORS player anywhere. Files whose index trails, or hosts whose bytes can't be read, keep the plain player still (shown, not kept). - Kept frames are 480 px wide (were 270) and capped at 600. - Probe failures are stored as failedAt, so earlier failures are asked again at once. - Test: an R2-style host, its clip cached by a plain load first, is still measured and its frame kept (failed before this change). Co-Authored-By: Claude Fable 5.1 Claude-Session: https://claude.ai/code/session_01ULQZS9MQa6iAsXnrJUD9Du

Video tiles: a frame even when the size check fails; retry it later

2026-10-03T22:32:41Z

Efrat's clip (blossom.primal.net → r2a.primal.net) showed a blank tile on a phone: the 64 KB probe failed there (slow connection), the failure was kept for good, and a tile with a failed probe never tried for a frame. - A failed probe is dated and asked again after an hour (it was kept forever; old 'failed: true' entries are retried). The probe waits 10 s. - A tile whose probe failed still tries for a first frame, giving up and letting go of the file after 8 s. - Primal's CDN lets scripts read the bytes but not Content-Range, so the size was unknown: a HEAD's Content-Length (readable by any page) fills it in. - No size in imeta but a bitrate and duration (Primal posts those): the size is estimated from them. 'dim 1080.0x1920.0' is understood. - A tile with nothing to show is dark, like a video, not a pale gap. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01ULQZS9MQa6iAsXnrJUD9Du

Media views keep their own cache and crawl for media directly

2026-10-03T22:05:52Z

Videos was slow because the grid read from the feed's page of posts: the feed cache holds 30, so after every reload the grid re-crawled the relays, ten posts a step, each post first waiting (up to 8 s) for its avatar, pictures and link cards — none of which the grid shows. - Each feed now keeps a media index (IndexedDB, src/media-cache.js): the posts carrying pictures and those carrying clips, 400 of each, and how far back it has looked. The grid and pager read from it; a reload paints them at once. - The crawl reads older posts straight into the index, 100 at a time, without the readiness wait and without touching the feed's own page; it resumes from where it stopped. The bottom of a feed is looked for again after a day. Curated feeds still page the usual way. - A tile's first frame is kept (a small JPEG in the Cache API, when the host lets its pixels be read) and painted as a picture from then on: in the grid, as the pager's poster and the feed's. - Probe results kept for 2000 clips (was 600). - Forgetting a wallet wipes the index and the frames. tools/feed-media-cache-test.js Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01ULQZS9MQa6iAsXnrJUD9Du