The sub-second axis snap asks about the size of the axis, not about whether AVPlayer rebuilt the timeline (and cannot fire at all on a source whose timestamps start above zero)

[superuser404notfound]

Found while measuring PR #533 on a source whose timestamps do not start at zero, but this is not about that source: it costs a zero-origin session 0.375 s of cue accuracy on the arm below, on main today.

The rule

snapAxisAfterSeek discards the axis at a seek when it is under a second:

static let axisSnapsBelowSeconds = 1.0
static func axisShiftAfterSeek(_ shift: Double) -> Double {
    return abs(shift) < axisSnapsBelowSeconds ? 0 : shift
}

The premise (AE#418 round 2) is that AVPlayer throws a sub-second offset away at a seek and snaps back to the playlist, measured at -0.500 and -0.875 against -1.000 and above.

What the picture says

Two arms, same fixture (Scripts/timecode-fixture.sh + Scripts/mkv-cue-fixture.py, tc-cues-lie.mkv over Scripts/slowrange.py at 600 kbps / 300 ms), same standing axis of -0.375 (a resume at 73 s re-aims seg18 from its boundary at 72.000 to the covering sync sample at 71.625). The only difference is whether the seek target is inside what AVPlayer already holds:

arm	seek	buffered to	landing held	AVPlayer	snap fires	capErr after
--seek-every 30 --seek-pattern 78	73 → 78	95.62	yes	KEEPS -0.375	yes	-0.400
--seek-every 12 --seek-pattern 80	73 → 80	75.62	no	discards it	yes	+0.025

aetherctl play --seconds 60 --start-position 73 --picture-probe \
  --seek-every 30 --seek-count 1 --seek-pattern 78 http://127.0.0.1:8880/tc-cues-lie.mkv

In the first arm the session publishes #418 axis -0.375s discarded at the seek landing 78.375s (AVPlayer snaps a sub-second axis), and from the next tick the picture disagrees with it by exactly that: capErr reads -0.400 for the rest of the run, a cue placed at sourceTime lands 0.4 s early, and nothing corrects it because a seek that stays inside the run fetches nothing, so neither a placement nor the AE#481 landing reading is armed.

The second arm is the same code being right, for the same reason the rule was written.

So the discriminator is not the size

It is whether the seek makes AVPlayer rebuild its timeline. That is also what AE#481 concluded from the other direction ("a seek INSIDE the run keeps the axis"), and both arms above agree with it. The size test fits the arms round 2 measured because those all left the buffer; it is a proxy that happens to correlate.

Second half, the same conflation PR #533 was about

The test is applied to the published axis, which is AVPlayer's displacement PLUS the source-to-item normalization the bytes carry. On a source whose timestamps begin at 600 s the standing axis is 599.625 for the same 0.375 s displacement, so the rule can never fire at all. Measured on the same fixture remuxed with -output_ts_offset 600: no discarded line, the axis stays 599.625, and capErr reads -599.983, i.e. correct, because the run really had kept its displacement. The two geometries also diverge behaviourally from there: the seek target conversion differs by 0.375 s, which changed which segment the next seek landed in (1 of 3 runs against 3 of 3 on the zero-origin twin).

Fix direction

Ask whether the landing is inside a loaded range before discarding anything, and express the test on the displacement rather than on the axis so both geometries answer the same. The first half needs loadedTimeRanges at seek time, which today is an off-main read (avPlayerLoadedRanges(), AE#422) in a path that currently issues the seek without awaiting anything, so it wants a seek-latency measurement before it goes in. That is why PR #533's follow-up left the rule alone and deliberately kept it inert on offset sources: on the one arm that separates the two, inert was the right answer.

[superuser404notfound]

The read is affordable: 0.1 ms median, 0.7 ms worst of 215 seeks

Measured before relying on it, since that was the stated blocker. Harness: seektest's #38 ledger
now reports seek latency (.began to its first terminal event) in 44272324, plus a temporary
env-gated probe on the seek path that timed avPlayerLoadedRanges() exactly where the fix would
call it, immediately before snapAxisAfterSeek. Fixture tc-cues-lie.mkv (Scripts/timecode-fixture.sh

• Scripts/mkv-cue-fixture.py) over Scripts/slowrange.py, macOS, M-series.

loadedTimeRanges at seek issue

arm	n	min	median	p90	max
idle box, 600 kbps / 300 ms origin	65	0.00	0.10	0.20	0.70
loaded box, same origin	65	0.10	0.10	0.10	0.20
loaded box, second read behind the first	65	0.10	0.10	0.10	0.20
150 kbps origin, seeks issued on top of unsettled ones	20	0.10	0.20	0.30	0.30

Load spanned vm.loadavg 1.5 to 21.8 across the matrix. The warm reading taken straight behind the
cold one reads 0.00 median against 0.10, so nothing is queueing on offMainReadQueue at that moment:
the call is simply cheap there, rather than cheap because the queue happened to be free.

Against the hop that is already on that path

The premise "a path that currently issues the seek without awaiting anything" does not hold for
this branch. prepareSeekLanding sits between snapAxisAfterSeek and the host seek and is an
unconditional await Task.detached(priority: .userInitiated) on every native VOD seek. It measured
0.0 to 0.2 ms on the same log lines, i.e. the same size as the read in question. So the fix adds a
second hop of the size of one this path already takes, not a first one.

End to end

Seek latency, .began to terminal, 60 seeks per arm, excluding each run's cold first seek:

arm	median	p90	max
baseline, idle	97.3	127.9	2068
with the read, idle	98.6	130.2	2175
baseline, loaded	88.6	314.2	2232
with the read, loaded	92.3	256.1	2118

The two baselines differ from each other by 8.7 ms, which is larger than either baseline-to-read
difference, so the read is not separable from run-to-run noise. The discarded first seek cost 28.2
to 28.7 s in every arm including both baselines: that tail is the cold origin, not the change.

What this does not say

• The moment measured is seek ISSUE. AE#422's 13.3 s blocked read was in the seek-DEADLINE loop,
  which runs while a seek is failing to land, and that is a different moment on the same serial
  queue. Nothing here says that one is cheap.
• macOS is not tvOS. Display criteria, Jetsam pressure and mediaserverd behaviour differ, so this
  bounds the cost, it does not prove it on an Apple TV.
• The overlap arm reached the interesting state (9 supersedes, phase=seeking held across the run),
  but it reached it on one origin shape only.

Where that leaves the fix

The first half of the fix direction, ask whether the landing is inside a loaded range before
discarding anything, is unblocked on cost. The second half, expressing the test on the displacement
rather than on the axis so both geometries answer the same, never depended on this measurement.

[superuser404notfound]

First half built and verified: the gate is the placement, not the size

922dfea2 on measure/534-seek-latency. axisShiftAfterSeek now takes landingIsPlaced and keeps
the axis when AVPlayer already holds the landing; everything else about the rule is untouched.

The two arms, 3 runs each

arm	#418 discarded	#534 kept	capErr before	capErr after
73 → 78, landing held	0	1	-0.400	-0.025
73 → 80, landing not held	1	0	-0.025	-0.025

The reported case now reads what the healthy arm reads, and the arm that was already right is
byte-for-byte unchanged.

The 600 s twin does not move

2 of 2: discarded=0 kept=0, capErr -599.983, the same healthy reading as before. It is inert
there for the right reason now rather than because the rule could not reach it, which is what the
displacement half needed before it can move.

One assumption that turned out not to hold

The table in the first post reads "buffered to" off the producer's own frontier. The fix asks
AVPlayerItem.loadedTimeRanges, and on these very arms the two are different numbers in opposite
directions:

arm	producer frontier	placed range	landing
73 → 78	95.62	72.000-84.337	78.375, inside
73 → 80	75.62	72.000-80.343	80.375, outside by 0.032

So the discriminator does separate the arms, but not on the number the table suggested. A fetch is
not a placement (AE#418), and only the placement says whether there is a timeline to rebuild. Worth
noting for anyone re-running: the second arm separates by 32 ms of placement on this fixture, so a
faster origin can move that boundary.

Cost

0.10 ms median, 0.70 ms worst over 215 seeks (previous comment). An item that answers nothing reads
as not placed, which is the behaviour the rule had before, so a failed read costs the axis and never
the session.

Tests: 2962 swift-testing in 399 suites and 631 XCTest, 0 failures, no new warnings.

Still open

The second half, expressing the test on the displacement rather than on the axis so both geometries
answer the same. It needs an arm that does not exist yet: an offset source whose landing is NOT held.
Today the rule cannot fire there at all, and with the gate above in place that arm is the only one
where the two geometries can still disagree.

[superuser404notfound]

The first half is released in 6.87.0 (922dfea2, merged as 1f9a654c). Both consumers are pinned to it. The second half, expressing the test on the displacement rather than on the axis, still needs an arm that does not exist yet: an offset source whose landing is NOT held. This issue stays open for it.