You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Overlapping subtitle cues: a long cue vanishes while a shorter, later-starting cue is active #181
The binary search lands on the last cue with startTime <= time; the backward walk stops at the first non-active neighbour, so an active cue further back (earlier start, longer duration) is never reached. Cues are sorted by start time only (SubtitleTrack.loadText's onflush), which is the normal shape of overlapping tracks.
Reproduced with the real Utils.binarySearch and cues [0-100 "SIGN"], [10-12 "l1"], [11-13 "l2"]:
time
shown
5
SIGN
11.5
SIGN, l1, l2
12.5
l2 (SIGN missing)
20
nothing (SIGN missing)
Any SRT/VTT with a sign, song or narrator cue spanning dialogue (common in anime subtitles) flickers the long cue on and off as dialogue cues start and end. No test covers overlapping cues.
Also: WebUtils.replaceChildrenPerformant only appends new nodes, so a cue that became visible later is appended below one that started later, and after a backward seek into an overlap the lines swap positions until the first ends.
Suggested fix
Precompute maxEndSoFar[i] on flush/shift (cues sorted by start) so the back-walk can stop when maxEndSoFar[i-1] < currentTime and collect every cue in between with endTime >= currentTime; or simply scan back while startTime <= currentTime (tracks are small). Order the children by startTime after the diff in replaceChildrenPerformant (insertBefore when parent.children[i] !== child).
Confidence: high.
From a line-by-line code review of the tree at 41363fd (2026-10-02). Each claim above was checked against the source before filing; the reproduction steps and line references are as of that commit.
Activity