[pallaoro]

Reported on an iPad: playing through one cut, the preview kept jumping back and forth between the clip before it and the clip after it. Other cuts in the same project played fine.

Cause

While a video plays, the preview's playhead follows that video's position. At a cut, the playhead moves to the next clip and follows its video. If that video reads even slightly before its trim point, the playhead lands before the cut. Then:

1. The previous clip becomes the active one again. It has already played past the cut and isn't re-seeked (the gap is under the 0.75 s tolerance), so it plays on and hands forward again.
2. Meanwhile the incoming clip, ahead of the playhead, is sent back to its first frame. It reads short again, and the loop repeats.

The incoming clip can read short in two ways:

• A transition at the cut. Its incoming side plays alongside and is only nudged into step: up to 0.08 s behind when buffered, 0.4 s when not.
• A trim point between two frames. A browser may report the frame just before it (Safari frame snapping; not confirmed on a device).

Every playhead write was checked. All seek() calls are user actions, and the wall clock only moves forward, so the media clock is the only thing that can move the playhead backward on its own.

Fix

The media clock never returns a time earlier than the active clip's start (src/client/edit.tsx, one line).

Known cost: on a transition where the incoming video arrives behind, the playhead now waits at the cut for that gap (up to 0.08 s, or 0.4 s if not buffered) while the video shows the frames just before its trim point. That's a brief one-off instead of an endless loop.

Not verified

• No device repro: the reporting project is in another workspace.
• Typecheck and tests run in CI only (no Node on the authoring machine).

Check on a device: scrub to just before a cut that has a transition, or one trimmed between frames, and press play.