After a restart whose gate re-aimed below its boundary, the clock runs ahead of the picture by the re-aim — captions early, and further out after each such restart (6.40.0 early-opening gate, loopback-HLS VOD, native path)

[rrgomes]

Same asset as #408 (h264 MKV, Matroska Cues on non-random-access points), PGS subtitles on, engine 6.41.0 and 6.42.0 (6.42.0 is on our pin; nothing in it touches this path), Apple TV 4K 3rd gen / tvOS 26.6. Two sessions on 2026-08-25, heard on the couch and then read out of the log; the second with AVPlayer's own loaded ranges in the log.

What the viewer sees. Resume from 354.0 s: lip sync fine, captions about four seconds ahead of the dialogue — both sessions. A burst of far seeks, further ahead: in the first session "much more than four seconds" after a landing whose restart re-aimed 14 s; in the second, about eight seconds at 699 s after restarts that re-aimed 3.1 s and 5.0 s. Seeks that landed without a restart did not change it, and no restart put it back.

What the producer did at each restart (#65 ledger, sourceStart − planSource):

session 1
resume 354.0   boundary 352936 not a random-access point; re-aimed 4s → gate actual=349891   seg-88  itemAxis=349.891 planSource=352.936 drift=-3.045s shift=0.000s
seek → 622.0   restart idx=154, gate actual=616074 (no re-aim)                                seg-154 itemAxis=616.074 planSource=616.074 drift= 0.000s
seek → 682.0   boundary 676134 re-aimed 4s, 8s, 16s → gate actual=662078                      seg-169 itemAxis=662.078 planSource=676.134 drift=-14.056s
seek → 992.0   boundary 972847 re-aimed 4s → gate actual=969802                               seg-243 itemAxis=969.802 planSource=972.847 drift=-3.045s
seek → 1102.0  boundary 1084375 re-aimed 4s → gate actual=1083332                             seg-271 itemAxis=1083.332 planSource=1084.375 drift=-1.043s
session 2
resume 354.0   as above                                                                       seg-88  drift=-3.045s shift=0.000s
seek → 519.3   boundary 512053 (first sync sample 0.96s later); re-aimed 4s → actual=508925   seg-128 itemAxis=508.925 planSource=512.053 drift=-3.128s shift=0.000s
seek → 609.3   gate actual=604896 target=604521 (a late opening: shift=375 applied)           seg-151 itemAxis=604.521 sourceStart=604.896 drift=0.375s shift=0.375s
seek → 689.3   boundary 684809 re-aimed 4s, 8s → gate actual=679762                           seg-171 itemAxis=679.762 planSource=684.809 drift=-5.047s shift=0.000s

Every landing read seek#N programmatic landed rendered≈target, VOD shift published: 0.000s … foldShift=0.000s at each re-aimed seam, and the host's 4 Hz sample read frameAhead=0.000 producerShift=0.000 hostShift=0.000 with t == avpClock — except after the one LATE opening, where the shift machinery engaged as designed (producerShift=0.375 hostShift=0.375). The host places each PGS cue at its source time against sourceTime.

Where AVPlayer put the re-aimed segment. At the resume, before playback started, the clock sat on the plan boundary, not on the media the segment carries: t=352.936 avpClock=352.936 … loaded=[352.9-…] while seg-88 itemAxis=349.891 sourceStart=349.891. And the loaded range then grew by the playlist's planned durations, not the media's: +3.6 / +4.5 / +3.2 / +4.8 / +3.5 s as seg89…93 loaded, against plan durations 3.587 / 4.547 / 3.211 / 4.838 / 3.462 s and media durations 2.544 / 4.713 / 2.002 / 5.797 / 5.965 s. So the player's timeline is the manifest axis, and a segment whose media begins 3.045 s before its manifest position is presented 3.045 s later than its timestamps say. Audio and video sit in the same segment, so lip sync survives; the cues are on the file's real axis; and the clock every consumer reads — currentTime, sourceTime, and for a synced-playback host the position it reports to the room — is on the other one. On 6.39.0 the same restarts applied the shift and the clock was consistent (the landing was what was wrong then). In-window seeks in the second session also landed past their targets (seek#2 target=397.30 landed rendered=399.27, seek#5 449.27 → 449.87), which reads as the same disagreement seen from the seek side.

Whether the error is the latest restart's re-aim or accumulates across restarts I cannot say from ears alone (about 4 s → about 8 s over restarts of −3.0, −3.1, +0.4 shifted and −5.0); happy to measure whatever would settle it.

Incidental, from the same run on 6.42.0: the resume start logged landingWithheld=1 on the #357 subtitle-delivery line and no caption overstayed a landing — the #416 refusal doing its job here.

I don't have a view on the right fix. Re-applying the shift for an early-opening gate puts the clock back on the manifest axis and reopens the landing error #408 fixed; the alternatives are a manifest that tells the truth about where the re-aimed segment starts and how long it runs, or a map that carries the re-aim into sourceTime and the landing. Happy to run any of them against this asset on both devices.

[superuser404notfound]

Read out of the picture rather than reasoned about, and the reading says the third of the three options, with one correction to it. Thank you for the loaded ranges: they are what made it worth building the instrument instead of arguing from the ledger.

What AVPlayer does with the segment

aetherctl play --picture-probe now attaches an AVPlayerItemVideoOutput to the running item and decodes the source time out of the frame itself. The fixture states its own frame number in the picture (12 blocks on one pixel row, bit k of the frame index, Scripts/timecode-fixture.sh), so pic is what is on screen, picItem is AVPlayer's own itemTimeForDisplay for that same frame, and their difference needs no tolerance to interpret. Every other axis observable here, MuxedVideoFrameTime included, describes what the engine WROTE.

On a fixture carrying your shape (Cues injected at non-sync positions, a 12 s keyframe drought at 43 s), resuming at 53 s so the gate re-aims three times and opens at 38.417:

t=02 cur=54.80 pic=41.250 picItem=54.833 axisErr=-13.583 capErr=-13.550
t=12 cur=64.80 pic=51.292 picItem=64.875 axisErr=-13.583 capErr=-13.508

axisErr is exactly the re-aim (52.000 - 38.417), constant for the whole run, across three segment boundaries. So: AVPlayer presents a segment at the position the playlist gives it, not at the tfdt it carries, and then plays continuously from there. Your loaded ranges said it; this says it with the picture in hand. The assumption 6.40.0 shipped on, that keeping the segment's own timestamps leaves the item axis where the plan puts it, is simply false, and nothing in the engine could see that at the time.

Worth putting next to it, the same fixture with the re-aim disabled, which is the pre-6.40.0 arm:

video gate open: actual=55000 target=52000 desired=52000 shift=3000
t=02 cur=57.80 pic=57.875 picItem=54.875 axisErr=+3.000 capErr=+0.075

The picture is three seconds off the item axis there too. What differs is that the shift was published, so sourceTime described it correctly. The machinery was never wrong; 6.40.0 switched it off for the one case that needed it most.

The fix

Your option (c), with the correction that the map belongs to the decode RUN and not to the timeline.

The offset a consumer folds is measured against the segment's ADVERTISED start, never against where the gate opened. A pinned (late) gate makes those two identical, which is exactly why publishing the muxer's shift held for years and broke the moment a gate that opens early existed. The muxer's own shift is untouched: it is the source-to-item offset for the bytes, and moving it is what would re-open the landing error.

That offset stops applying when AVPlayer starts a fresh run. This half was not obvious and the measurement forced it. Only an epoch's first segment can carry an offset (every segment cut after it starts on its own boundary), a run carries it across every boundary it plays through, and a seek that leaves the loaded region without provoking a restart lands on a sequentially cut, axis-true segment where the old offset must be dropped. With only the first half in, a seek out of the region read capErr=+0.892 where the defect had been -0.875: the same error mirrored. The provider now reports the index each fresh run begins on, and the axis is republished from that segment's own worth:

[HLSVideoEngine] #418 decode run re-anchored at seg11 (advertised 44.000s): axis shift -0.875s -> 0.000s

Measured, source time decoded from the picture:

arm	published shift	picture vs item axis	picture vs sourceTime
before 6.40.0 (pinned)	+3.000	+3.000	+0.075
6.40.0 as shipped	0.000	-13.583	-13.550
with this change	-13.583	-13.583	-0.009

and for the seek that leaves the loaded region, +0.892 before, +0.017 after. The control fixture, identical except that its Cues ARE its sync samples, is untouched on both arms: no re-aim, no seam, axisErr 0 on every tick.

Your open question, whether it accumulates

It does not. The error is the offset of the segment the CURRENT run began on, and a new run replaces it rather than adding to it. What reads as accumulation is a later restart with a deeper re-aim: your second session ended on -5.047 at 689.3 s, and about eight seconds by ear at 699 s is that restart, not the sum of the four. The prediction the fix makes is checkable in a log without the fixture: after each re-aimed restart the VOD shift published line should now carry that restart's own drift, and a seek that leaves the buffer should be followed by a #418 decode run re-anchored line naming the segment it landed on.

Two things to say plainly

The clock will now read LOWER than the target after a resume or seek into a drought, by the re-aim. That is not a new landing error and not the one 6.40.0 fixed coming back: the picture was already there, it is only being described honestly for the first time. Nothing about which frame is on screen changed in this commit.

And the landing itself is worth its own issue rather than a sentence here: the re-aim's 4 / 8 / 16 / 32 s backoff opens on the first sync sample above where it landed, not on the nearest one below the boundary, so the resume above went to 38.417 when 43.0 was available and would have cost 9 s less. That is now visible because the clock stopped hiding it.

PR #420, not merged yet. A release note follows when it ships. Retest whenever it suits, and the same thanks as last time for keeping the asset available.

[superuser404notfound]

Released in 6.43.0, with both consumers on the new pin. Leaving this open for the retest.

[superuser404notfound]

One thing to know before that retest, because it will move the numbers in the table above and I would rather it not read as a discrepancy.

6.43.0 carries #423 alongside this fix, and the two touch the same restarts. #423 changes the re-aim's backoff from doubling (4, 8, 16, 32) to even steps (4, 8, 12, ... 32), because each attempt opens on the first sync sample at or above where it aimed and everything above the previous aim is already proven empty, so the DISTANCE between two attempts is the worst case by which the gate can overshoot the sample that would have covered the boundary. On the fixture that moved the gate from 38.417 to 43.000 against a boundary at 52.0, with the same three attempts.

So on your asset expect the drifts to be SMALLER than the ones you tabulated, not equal to them. The -14.056 row is the one most likely to change, since it took three doublings; a run of even steps should find something the 16 s jump flew over. The prediction worth checking is therefore not a number but three relations:

• presentedShift= appears in the video gate open line whenever the gate opened early, and is no longer 0 there. It should equal sourceStart - planSource, whatever that distance turns out to be now.
• VOD shift published carries that same value, with seamAt= on the segment's ADVERTISED start rather than on where the gate opened.
• #418 decode run re-anchored at segN (advertised …) appears after a seek that leaves the loaded region without provoking a restart, and puts the shift back to 0 for that run.

And the part that is easiest to misread as a regression: after a resume or seek into a drought the clock will now read LOWER than the target, by the re-aim. The picture was always there; before 6.43.0 the clock claimed the target while showing content that far back. Captions matching the dialogue is the reading that settles it, not the position readout.

If any of the three relations fails on real media, the log lines above are enough to say which half of the fix it fell out of.

[rrgomes]

Retested on 6.43.0, same asset (h264 MKV, lying Cues, PGS on), Apple TV 4K 3rd gen / tvOS 26.6. The resume into the re-aimed start is fixed — captions on the dialogue for the first time in three builds, and the clock reading below the target read exactly as you describe, not as a regression.

Your three relations, on real media: (1) holds — presentedShift equals sourceStart − planSource at every early gate (three this run: −3.045 at the 352.936 boundary, −2.044 at 536.995, −14.056 at 676.134). Worth reporting against your prediction: none of the three got smaller under #423. The two 4 s ones open on the first attempt, which both ladders share. The −14.056 one took four attempts instead of three (4, 8, 12, 16 rather than 4, 8, 16), and the extra 12 s attempt at 664.134 found nothing at or below the boundary, so both ladders converge on the same aim of 660.134 and the same sample at 662.078. On this asset the drought is real rather than an artifact of the doubling: there is no sync sample between 662.078 and the boundary at 676.134.

(2) holds — VOD shift published carries that same value with seamAt= on the advertised start. (3) is the one that failed, in a case the fix did not anticipate: it fired for a seek that had NOT left the re-aimed run.

A fast forward-seek burst (six programmatic seeks in ~6 s, 391 → 721, the transport-bar drag our UI issues):

seek#5 → 680.96  restart idx=169, re-aim 4/8/12/16s,  presentedShift=-14056  landed 680.96
seek#6 → 720.96  #418 decode run re-anchored at seg179 (adv 716.591): -14.056 -> 0.000
                 landed rendered=739.28 target=720.96   (no producer restart)

Through the burst AVPlayer lagged badly — its currentTime was still 541 while the engine's clock stood at 683, and our seek-age counter reached 6.3 s — so when it moved, the provider saw a fetch that did not follow its predecessor and called seg-179 a fresh decode run, and the shift went to 0 while AVPlayer was still inside the re-aimed seg-169 run. From there every internal axis agreed at the wrong place (avpClock == currentTime == sourceTime == 740.4), applySubtitleEvent placed the 739-742 cue there, and the captions ran about 14 s ahead of the picture until the next restart — the pre-fix shape, re-entered through the burst.

The reading I can offer: "fetch does not follow predecessor" is not a reliable fresh-run signal during a seek burst, because a burst produces exactly that pattern without AVPlayer having left the re-aimed run. What I cannot show from here is the picture itself — avpClock follows the playlist, so it is fooled the same way, and frameAhead read 0.000 throughout. Your play --picture-probe with a burst on the lying-Cues fixture should reproduce it directly. Happy to run whatever would settle it, on this asset and both devices.

[superuser404notfound]

Relation (3) was right to fail, and the burst was right to be the thing that broke it. It reproduces on the fixture without a burst at all, which is the more useful news: the trigger was not merely unreliable under load, it was the wrong question.

Reproduced

tc-cues-lie.mkv, resume at 53 s so the gate re-aims and opens 9 s below its boundary, then one seek:

aetherctl play --seconds 17 --start-position 53 --seek-every 12 --seek-count 1 \
    --seek-pattern 80 --picture-probe file:///tmp/tc-cues-lie.mkv

t=13 cur=89.90 pic=80.917 picItem=89.917 axisErr=-9.000 capErr=-8.983

axisErr never moved. The picture is exactly where it was, the run carried straight on, and the only thing that changed is that the engine stopped describing it. Same shape at seek targets 80 and 85, none at 75 (no out-of-sequence fetch, nothing to trigger on). So no lag and no burst are needed; one forward seek is enough, and the burst on real hardware just made it easy to hit.

What the fetch order actually is

The reading offered here holds, and the fixture says why. Two things AVPlayer does that a fetch-order signal cannot tell apart:

• On a seek it asks for a segment below its target. Measured repeatedly: seek to 30 fetched seg5 while seg7 covered the target, seek to 48 fetched seg10 against seg12, and the reported seg179 against a target in seg180 is the same move.
• It asks out of order while continuing the run it is already playing, which is the case above.

Both look identical from the provider: an index that does not follow its predecessor.

The rule underneath, measured

The picture probe answers this one directly, and it is not the rule 6.43.0 shipped. Re-aims of 0.5, 0.875, 1, 3, 5, 7, 9 and 11 s, on two fixtures:

AVPlayer places a segment at its advertised start read through the mapping its timeline ALREADY carries. So the offset is not a property of a run that starts and ends. It composes.

case	true axis	6.43.0 published
resume, gate 9 s below its boundary	-9.000	-9.000
then a seek onto an axis-true segment	-9.000	0.000
then a seek that re-places that same segment	-18.000	0.000
then a seek whose restart re-aims 5 s more	-14.000	-5.000
tiered fixture, -11 re-placed	-22.000	0.000

Row 3 is the one worth pausing on: re-fetching the overlong segment adds its offset a second time, exactly, at every magnitude tested. Which means the answer given here to the accumulation question was wrong in one direction. It does not accumulate across restarts the way it appeared to, that part holds. It does accumulate when AVPlayer re-places the same overlong segment, and 6.43.0 could not see that because it published zero for those cases anyway.

One more thing fell out, and it is why 6.43.0 looked right on small re-aims: AVPlayer discards a sub-second axis at a seek and snaps back to the playlist. -0.500 and -0.875 read axisErr=0.000 after one; -1.000, -1.083, -1.292, -1.500, -3, -4, -7, -9 and -11 all survive unchanged. The boundary sits between -0.875 and -1.000. The -1.043 row of the ledger is just above it; the +0.375 late one is below.

The change

The axis moves when AVPlayer places a segment, by exactly what that segment carries below its advertised start, and the seam sits at that advertised start read through the axis in effect before it landed. The single anchor pair becomes a record keyed by index, because several epochs can leave an overlong segment in the cache at once, and a new epoch drops the entries at and above its own index (it rewrites those axis-true). A gate no longer publishes on its own: it records what its segment is worth and the placement publishes it, so an epoch AVPlayer never fetches from cannot move the clock. The VOD seek path publishes the sub-second snap from the landing forward.

Thirteen arms of the fixture matrix, including the four that read capErr=-8.983, now read +0.017, which is one frame at 24 fps. The control fixture (Cues that ARE its sync samples) is untouched on both arms.

On the #423 prediction

That prediction was wrong on the reporting asset and the measurement of it explains why better than the prediction did: with no sync sample between 662.078 and the boundary at 676.134 the drought is real, both ladders converge on the same aim, and the even steps only cost one extra attempt that found nothing. Worth having stated, since it separates "the ladder flew over a sample" from "there is nothing there" for good on that asset.

What to look for on retest

The decode run re-anchored line is gone; there is nothing left that re-anchors. In its place:

• [HLSVideoEngine] #418 segN placed (advertised …s, worth …s): axis shift …s -> …s from item …s on every placement that moves the axis, and only on those. A seek onto an axis-true segment now prints nothing, which is the fix: seg179 in the burst above should produce no line at all and leave the shift at -14.056.
• [HLSVideoEngine] #418 axis …s discarded at the seek landing …s where a sub-second axis snaps.
• presentedShift= and VOD shift published are unchanged in meaning, except that VOD shift published now carries the composed value and its seamAt= is read through the previous axis rather than being the raw advertised start.

If the captions still run ahead after a seek, the placed lines say which placement the engine credited and by how much, which is enough to tell a missing composition from a spurious one.

Released in 6.45.0, both consumers on the new pin. Leaving this open for the retest, and thanks again for keeping the asset and both devices available. Round 1 would have shipped as correct without that burst.

[rrgomes]

Retested on 6.45.0 (Apple TV 4K 3rd gen, same asset). The resume is right and the in-window seeks print nothing, as designed. The burst now overshoots in the other direction: after it the captions run 2-3 seconds BEHIND the picture, and the composition is why.

seg88  placed (advertised 352.936s, worth -3.045s): axis 0.000 -> -3.045   [resume]
seg187 placed (advertised 748.122s, worth -2.043s): axis -3.045 -> -5.088  [seek 748, restart]
seg197 placed (advertised 788.204s, worth -5.589s): axis -5.088 -> -10.677 [seek 788, restart]

At t=800.123 the host's 4 Hz sample reads avpClock=810.868 and loaded=[791.2-816.6], so the engine is subtracting 10.745 while the segment being presented opened 5.589 s below its advertised start. The loaded range holds only the current epoch: the segments seg88 and seg187 belong to are long gone from the timeline.

None of the three is a re-placement of the same overlong segment, which is the case the composition rule was measured on. Each is the first segment of a new epoch after a far seek, and each epoch replaced what AVPlayer had buffered. Composing them charges the clock for content that is no longer in the timeline; the run being played is worth -5.589 on its own.

What I cannot say from here is whether the right rule is "the current placement replaces the axis when its epoch replaced the buffer" or something narrower about what survives a flush — play --picture-probe with two successive far seeks, each provoking a restart that re-aims, should separate them. Happy to run whatever helps on this asset and both devices.