Repository navigation
fix(core): preview fetches only the clips due next, and drops passed clips still downloading - #6160
Conversation
…clips still downloading A fast-cut film started a fetch per clip inside the look-ahead and let passed clips finish.
![heygengenesis[bot]](https://avatars.githubusercontent.com/in/2913576?s=60&v=4){kind=small}
There was a problem hiding this comment.
Verdict: REQUEST CHANGES · 1 blocker · 0 important · 0 nits · head fd125580
The slot queue itself works: it hands out slots earliest first and refills them as clips settle. The blocker is how spent interacts with the 2 s look-back window. Details are in the inline comment.
Scope
I read init.ts (preloadNearPlayhead, slot helpers, dueSoon, mediaStaysDue, unchangedSincePlayedFrom) and preloadMedia.ts. The 37 tests in entry.test.ts pass locally. I reproduced the blocker with a throwaway probe in the same suite: a networkState getter that load() drives, two clips on one track, and play with keepPlaying steps from 2.05 s to 4.0 s. CI was still running at the time of review.
Edit accuracy: accurate 271 (base branch 271), smooth 139 of thoseThe gate passes. Quarantined, measured but not gated (0) Unstable (1)
|
It was refetched each pass inside the look-back window.
What
Studio's preview now keeps fetches to the clips that matter in a fast-cut film: the clip on screen, the next one on its track, and a few more that are due soonest. A clip the playhead has passed stops downloading while it plays.
Why
A cut sequence with dozens of short clips has most of them inside the 2 s look-ahead. Every one started a full fetch, and the clips already played kept downloading for 4 s more. With about 16 fetches in flight against the browser's 6 per origin, the clip that was due queued behind clips that were not, so later clips entered at
readyState1 and showed a stale frame.Both are decided in one place,
preloadNearPlayheadininit.ts:Measured
Headless Studio on a synthetic project: 36 clips of 0.2 to 0.6 s, cut from 6 portrait sources (20 MB each) across 4 sub-compositions, played from 0 for 14 s with the link limited to 12 Mbit/s. Clips that entered their window below
readyState3, and clips whose first frame took over 150 ms:At 12 Mbit/s, before: 24 clips never became ready inside their window. After: 6 of 7 runs had every clip ready on entry or within 141 ms; one run (the machine was loaded) had 8 late. Fetches in flight at once, peak: 16 before, 6 to 9 after.
Before
Frame at 5.4 s on the 12 Mbit/s link. The burned-in timecode of the source shows the clip sitting on its first frame (00:00:00.000).
After
Same moment after the change. The clip shows the frame it should (00:00:06.133).
Test plan
entry.test.ts: slots hand out earliest first and refill oncanplay/suspend/error; a passed clip still loading is released while playing and a finished one is kept. Both fail on main'sinit.tsand pass here (37 tests in the file; core media, init and entry suites pass).Not changed: a render still loads every clip; the capture page and thumbnails use the same code path as the live preview and gain the same limit.