6.21.1 - Live subtitle re-anchor

Drop-in from 6.21.0. One placement that survives a moving source axis, and the numbers to tell two indistinguishable symptoms apart.

A rendition that re-anchors instead of drifting

Cues of a live SUBTITLES rendition are placed by pairing a segment's wall time with the session's shift, the offset between the player clock and the source axis. That pairing holds until a producer seam republishes the shift, and then every cue already placed refers to an axis that no longer exists.

Unfixed this reads as subtitles drifting further out the longer a channel runs, in steps rather than smoothly, and it cannot appear in a short session at all: eight minutes against a public broadcaster showed a lead constant at 21.4 s (±0.3) with no seam in sight. The loop now watches the shift it anchored against and re-anchors when it moves, dropping the cues placed on the old axis rather than letting them stay behind by the delta.

Two numbers instead of a guess

[LiveSubs] states its anchor once, where a placement that landed in the wrong hour is visible before any cue is due:

[LiveSubs] anchored at wall 2026-08-12 15:26:47 +0000 = source 30993.99, first cue 31003.19
[LiveSubs] lead=21.6s cues=57 newest=31051.07 source=31029.49 shift=30993.99

and then repeats the running relation about every 30 s. A viewer reporting "the subtitles lag" cannot distinguish a misplaced anchor from a fetch that has stalled, because both end as an overlay that is not keeping up. A stable lead with a growing cue count says the delivery is healthy and the offset is in the authoring; a shrinking lead says the fetch is behind. The interval matters: the log is a ring buffer, and a line every two seconds pushes out everything a reader opened it for.