Live join: hasFirstFrameReadyForDisplay and .playing fire 1.5–2.8 s before the rate rolls (MinimizeStalls), and no join option covers the wait

[cmcpherson274]

What happened?

On a live loopback session, hasFirstFrameReadyForDisplay and state == .playing both go true while AVPlayer is still in waitingToPlay(.toMinimizeStalls) — the presented first frame then HOLDS STATIC for 1.55–2.81 s before rate rolls, and the host has no lever over that wait.

Measured on real hardware across 11 consecutive live tunes (raw-TS /stream.ts from Jellyfin
10.11, h264 1080p59.94 + AAC, loopback route, liveJoinProfile = .fastZap), millisecond
logs + HDMI capture at 10 fps:

• Your own host log shows the shape on every tune, e.g.:
  #3 layer.isReadyForDisplay=true t+1.10s →
  #3 timeControlStatus=waitingToPlay reason=AVPlayerWaitingWhileEvaluatingBufferingRateReason →
  #3 timeControlStatus=waitingToPlay reason=AVPlayerWaitingToMinimizeStallsReason →
  #3 timeControlStatus=playing reason=- t+3.91s — 2.54 s between first frame and rate roll.
• 9 of the 11 tunes held 1.55–2.81 s; on glass the frame is bit-static through the window
  (max per-pixel delta ≤ 1 at 10 fps on 192×108 gray), i.e. a real user-visible freeze, not
  a reporting artifact.
• The engine's clock advances through the window and state reads .playing, so every
  start signal a host can key chrome on fires seconds before motion. We shipped a
  host-side hold keyed on currentAVPlayerItem.timebase rate (works), but the WAIT itself
  stands: warm channel-change press-to-motion measures 6.4–6.6 s against our 5–7 s product
  bar — at the ceiling, and the wait is the largest single share we cannot touch.
• Not a fix: preferredForwardBufferDuration = 2.0 on the published item, applied before
  the roll — measured inert (A/B on device, five warm zaps each way; identical
  press-to-motion distributions). The wait is rate evaluation, not buffer-target-bound.

The engine sets neither automaticallyWaitsToMinimizeStalls nor uses
playImmediately(atRate:) anywhere (checked at both 6.21.0 and cb3baaf/6.50.1), so
AVPlayer's default policy decides the join tail on a path whose whole point
(.fastZap) is join latency.

Two asks, either resolves it (both would be better):

1. A join option to shorten/skip the wait on live loopback — playImmediately-class, or
   exposure of automaticallyWaitsToMinimizeStalls scoped to the live join (the
   .fastZap doc already prices "one early -16832 or a short rebuffer" as an acceptable
   trade; this is the same trade's other half).
2. Roll-aligned signaling: a published edge for "rate actually rolling" (we derive it from
   the item timebase today; a first-class signal would let hosts key chrome honestly
   without reaching into the item).

Steps to reproduce

1. Serve a live MPEG-TS stream (Jellyfin /Videos/<id>/stream.ts, h264 + AAC) and load it
   with isLive: true, liveJoinProfile: .fastZap, native/loopback route.
2. Watch the NativeAVPlayerHost transitions: layer.isReadyForDisplay=true →
   waitingToPlay(EvaluatingBufferingRate) → waitingToPlay(ToMinimizeStalls) →
   playing 1.5–2.8 s later. The presented frame is static for that whole span.
3. Optionally point an external capture at the output: the frame freeze is on-glass, with
   every host-visible start signal already fired.

AetherEngine version or commit SHA

Measured at 6.21.0 (87868c1); code re-checked at 6.50.1 (cb3baaf) — no
waits/playImmediately handling exists there either, so the mechanism is presumed
unchanged (the measurement itself is 6.21.0).

Host app

Custom / my own integration

Platform

tvOS

OS version

tvOS 26.5

Device / chip

Apple TV 4K (3rd generation), AppleTV14,1 — real hardware, not simulator. HDMI capture
(Elgato 4K X) used for the on-glass verification.

Playback path

Native AVPlayer

Source media (for playback bugs)

Live TV channel via Jellyfin 10.11 raw MPEG-TS (/stream.ts): h264 High 1920×1080
59.94fps progressive + AAC-LC stereo. Reproduces on every channel of this shape we
tried (7 distinct channels, 11 tunes).

Error codes / log lines

No errors — that is the point: the hold is silent. Representative sequence quoted above;
full millisecond logs of all 11 tunes plus the 10 fps frame-difference tables available
on request.

Anything else

The freeze cost us a P1 in our own device battery: our chrome dropped its spinner on
your start signals ~2.7 s before motion, which read as "stuck" to a viewer. We work
around it host-side now, but every AetherEngine host keying on
hasFirstFrameReadyForDisplay/.playing for live will inherit the same trap.

[superuser404notfound]

Thanks for this one. The measurement carried it: millisecond logs, 11 tunes, and an HDMI capture to
separate a reporting artefact from a real freeze is exactly what makes a policy question answerable
instead of arguable. Both asks are addressed on feat/ae440-live-join-roll (24f43e00), but the two
halves have very different answers, so it is worth being precise about which is which.

Ask 2 first, because half of it was a real defect on this side

There already is a published edge for "the rate is actually rolling": $playbackPhase. It is documented
as the single source of truth for what playback is doing, and it folds the transport status the host
mirrors. It was also broken in precisely the way reported, one level down.

state is transport INTENT. Every autostart writes .playing the moment play() has been called, which
is the documented behaviour and is why the startup ladder deliberately ends at .presenting rather than
at .playing. The phase simply followed state, so it inherited the same gap, and AVPlayer's pre-play
.paused status arriving after the autostart added a millisecond of .paused on top of it. Measured on
the loopback harness before the change:

PHASE loading      t+0.00s
PHASE playing      t+0.07s     <- 2.5 s before anything moved
PHASE paused       t+0.08s
PHASE rebuffering  t+0.08s
PHASE playing      t+2.56s     <- the rate roll

So keying on the phase would have dropped the spinner at 70 ms rather than at 2.7 s. Different number,
same trap.

The phase now folds a fourth axis, whether this load's transport has rolled once, and reports .loading
until it has. After:

PHASE loading      t+0.00s
PHASE playing      t+2.60s     <- rate roll at t+2.52s, plus the Combine hop

Two edges, no flicker, on both AVPlayer-backed paths. state is unchanged, so nothing that keys on it
moves. A paused mount stays .paused rather than looking like a session still arriving, and the paths
that publish no transport status credit the roll with their host, so their phase is bit-identical to
before.

That means no new API for this half: observe $playbackPhase and it is honest about motion.
hasFirstFrameReadyForDisplay keeps meaning what it says, that a picture exists rather than that it is
moving, and it and state now both carry that warning in docs/api.md. Deriving it from the item timebase, as done
downstream today, was the correct read of a broken signal.

Ask 1: a lever, not a fix, and deliberately off

LoadOptions.liveJoinStartsImmediately cuts the first such hold of a live session short with
playImmediately(atRate:). Four guards, each of which is a way this is otherwise the wrong call:

• Opt-in per load, and never on a VOD session.
• Only while the host still wants to play, so a pause during the join is not overridden into motion.
• Only for AVPlayerWaitingToMinimizeStallsReason, never for EvaluatingBufferingRate, which
  AVPlayer.h describes as a brief monitoring period and explicitly says not to show waiting UI for.
  Firing there would preempt an evaluation that was about to start playback by itself.
• Only while the item's buffer is non-empty. This is the documented precondition: over an empty buffer
  AVPlayer.h says the call "will act as if the buffer became empty during playback", and a stall with
  the player not waiting to minimize stalls is the shape that resets rate to 0 and never resumes. That is
  not hypothetical here. Setting automaticallyWaitsToMinimizeStalling = false on the shared player was
  tried in May 2026 and reverted the same day (35fa16d0): rate dropped to 0 right after asset.load
  and never came back. Hence a one-shot over a proven buffer rather than a policy on the player, which
  also answers the "expose the property" half of the ask, in the safer shape.

It is spent once the join has either been started by hand or rolled on its own, so every later hold in
the session keeps AVPlayer's own policy and a mid-stream rebuffer is untouched.

Why it ships off by default, and what would settle that

The hold does not reproduce here at all. Six window geometries against the raw-TS fixture at
--realtime --preroll 0/3/6/12/30, from a first window shallower than its own holdback to one entered on
a full backlog, 1 s and 5 s source GOPs:

window at first serve	first frame	rate roll	gap
2 seg / 10.0 s, TARGETDURATION 5	12.36 s	12.37 s	10 ms
3 seg / 3.0 s under a 6.0 s holdback	2.52 s	2.58 s	60 ms
5 seg / 5.0 s under a 6.0 s holdback	1.39 s	1.42 s	30 ms
6 seg / 6.0 s, holdback satisfied	0.11 s	0.15 s	40 ms
7 seg / 7.0 s, holdback satisfied	0.11 s	0.15 s	40 ms
6 seg / 6.0 s from a 30 s backlog	0.12 s	0.16 s	40 ms

Loopback answers at memory speed, so the buffering-rate evaluation concludes immediately and there is
nothing to cut short. That is a limit of this harness rather than a counter-measurement, and it is the
reason this is an opt-in: a policy change nobody on this side can observe has no business being on for
every host. If the A/B on real hardware says it is strictly better, making it the default (or an internal
policy for live joins, with no flag at all) is the obvious next step and the numbers would decide it.

aetherctl play --live --fast-zap --live-start-immediately drives the engine end, and play now prints
a PHASE <phase> t+Ns line on every phase edge, stamped on the same clock as the first-frame line, so
the two are readable against each other at millisecond resolution.

One measurement that would sharpen this, and one question

The lever only fires while AVPlayer reports the item's buffer as non-empty. Sampling
currentItem.isPlaybackBufferEmpty and currentItem.loadedTimeRanges across the hold would therefore
say in advance whether it can fire at all, and it also discriminates the two candidate mechanisms:
a forward buffer that keeps growing through the hold means AVPlayer has the data and is waiting on its
own estimate, which is what this addresses; a forward buffer pinned near zero means it is genuinely
starved at the edge, and cutting the wait short would trade a frozen frame for an immediate stall. Worth
knowing before the A/B rather than after it.

The other question is about the rest of the budget. Warm channel-change press-to-motion of 6.4 to 6.6 s
with 1.5 to 2.8 s of it in this hold leaves roughly 4 s elsewhere, and on a Jellyfin /stream.ts route a
good part of that is usually the server opening the upstream before the engine ever connects. The
first live manifest served after ... line prints what the join gate itself held, and
startupProgress.checkpoint separates the demux probe (streamsProbed) from the display handshake
(routed) from that gate (sessionConstructed). If most of the remaining 4 s sits before the engine's
first byte, there may be more to win there than in this tail.

[superuser404notfound]

Released in 6.52.0. playbackPhase is the roll-aligned signal now (.loading until the transport has moved once, .playing on the roll), and LoadOptions.liveJoinStartsImmediately is the opt-in lever. Leaving this open for the device A/B: the buffer sampling across the hold is what says in advance whether the lever can fire at all.

[cmcpherson274]

Device A/B done on 6.53.0, and the lever earns its keep.

Setup. Same tvOS device (AppleTV14,1), Jellyfin stream.ts route, the D-3 chain shape from the original report: launch, five channel-changes down across different channels, four back up — the up-legs and mid-chain revisits are the warm zaps (origin open ≈15 ms, source first byte ≈1.1 s). Two runs, identical shape, ~10 min apart: control, then liveJoinStartsImmediately: true on every live load. HDMI capture rolling both runs; press epochs stamped; frame analysis at 10 fps.

Control (defaults). Every warm zap reproduced the report's shape: first frame at ~2.3–2.6 s after load, then the transport sat in AVPlayerWaitingToMinimizeStallsReason for 2.6–2.9 s before the rate rolled (our timebase watcher's hold numbers). Camera-measured press→moving-picture on the clean warm zaps: 6.4 / 6.5 / 7.2 s.

Lever. On three of the five warm zaps the hold never arms at all — the timebase is already rolling by the time our first-frame predicate passes — and on the rest it releases in 0.3–0.5 s. Camera-measured warm press→moving-picture: 4.3 / 4.8 / 5.1 / 5.6 s. First-PICTURE latency is unchanged (~3.4–3.9 s both runs) — the lever removes exactly the frozen-frame tail, which is what the original issue was about.

The trade did not materialize. Per-channel session stats: dropped 0, stalls 0, on 10/10 zaps in BOTH runs; no reopen ladder, no errors. Cold zaps (tuner spin-up inside the first byte, ~6.5 s) are identical in both runs — the guards keep the lever out of the starved case, as designed.

Your buffer question, answered on hardware. We now sample isPlaybackBufferEmpty + the forward loadedTimeRanges span at ~1 Hz while our roll-hold stands. Every hold in the control run reads empty=false, ahead=3.7–4.9s for its whole duration — AVPlayer holds ~4 s of data while it waits on its own estimate. On this stack the hold is always your first mechanism (waiting on the rate evaluation), never edge starvation, which is presumably why cutting it cost nothing.

Whether we ship it on is our owner's call (the evidence above is the case for it); from the engine side this measurement is what the opt-in was waiting for, so closing from our end unless you want the raw bundles.

[tschuegy]

Field data from a second host: on our loopback live joins the new option cannot fire, because the hold lands before the first manifest exists.

Setup: Syravo on tvOS, AetherEngine 6.54.0, Apple TV 4K (3rd gen) / tvOS 26.6. Sources are Xtream raw MPEG-TS behind a redirect chain (720p50 h264 + AAC on the channels below), liveJoinProfile = .fastZap, liveBlockingReload = false, maxConcurrentSourceRequests = 1.

We put LoadOptions.liveJoinStartsImmediately behind a flag and ran a paired A/B on the device: 8 tunes, same channels, same order, one run per arm.

Result: the option never fired. Zero AE#440 live join: cutting the stall-avoidance wait short lines in the armed run, while our own controller logged the option as set on all 8 loads.

The timings show why. Per native tune, seconds after load start, both arms identical in shape:

channel	ToMinimizeStalls	first manifest served	first segment GET	rate roll
A	2.97	3.87	3.91	4.00
B	2.55	3.66	3.69	3.75
C	2.52	4.09	4.12	4.19

AVPlayer reports the hold roughly a second before the engine serves a playable manifest, so at that instant the item has fetched nothing. playIntent is set (#1 rate=1.0 precedes the hold) and the reason string matches, which leaves !playbackBufferEmpty as the only guard that can refuse — and it refuses correctly: that is exactly the empty-buffer shape AVPlayer.h warns about. Nothing to fix in the guard.

What differs from the original report is where the first frame sits. There, layer.isReadyForDisplay=true at t+1.10 s with the roll at t+3.91 s — a bit-static picture for 2.5 s. On our sessions the layer goes ready at t+3.70–4.13 s and the roll follows 50–110 ms later, so there is no static tail to cut. Same option, same loopback path, but our join never opens a window in which the lever may legally fire. Reported not as a defect, but so the option's reach is on record: it covers a join that is holding on buffered media, and a join can also be waiting for the playlist itself.

Where our join time actually goes (native path, 3 channels × 2 runs): ~0.8 s to open the origin (redirect chain, first data after ~650 ms), then 2.2–3.5 s producing the initial playlist, then ~0.1 s for AVPlayer. The gating line is always this one:

first live manifest served after 2.940s: 5 segments / 10.000s >= 9.000s holdback (TARGETDURATION 3s)

Which raises a question I would rather ask than assume: the producer cuts 2.000 s segments on these sources (61 of 63 finalized segments in the run; the first of each session is 0.500 s, from the targetDur=0.500s init), yet the served TARGETDURATION is 3 s, so the holdback is 3 × 3 = 9 s and we wait for 5 segments / 10 s of media before anything is served at all. At TARGETDURATION 2 the same rule would ask for 6 s. Is the 3 s a floor, or does it carry over from the 0.5 s init value somewhere? For us that holdback is the zap budget on this path — .fastZap already brought it from 18 s down to 9 s, and the remaining 9 s of media is what the viewer sits through.

One more data point from the same run, in case it helps place the path: 5 of the 8 channels are 1080i25 and route dispatch → software. Those reach motion in 0.67–1.01 s. On our hardware the loopback/native path is the slow join, not the software one.

Happy to run a patched build or dump full per-tune logs if either of those would help.

[superuser404notfound]

Shipped in 6.55.0: LoadOptions.liveJoinStartsImmediately defaults to true now, on the strength of the device A/B (press to moving picture 6.4 / 6.5 / 7.2 s to 4.3 / 4.8 / 5.1 / 5.6 s, press to first picture unchanged, stalls and dropped frames zero in both arms).

Three guards moved with the default: the lever requires 1.5 s of contiguous buffer ahead of the playhead rather than a merely non-empty one, it is evaluated when the waiting REASON changes rather than only on a transport-status change, and the readings behind the decision are one batched off-main read. Hosts that want AVPlayer's own join policy set the option false.

[superuser404notfound]

Recorded, and the reach is exactly as described: the option covers a join that is holding on buffered media, and this one is waiting for the playlist itself. Three things worth adding.

The guard got stricter in 6.55.0, not looser. With the default flip the lever now requires 1.5 s of contiguous buffer ahead of the playhead rather than a merely non-empty one, and it is evaluated when the waiting REASON changes rather than only on a transport-status change. On these timings (ToMinimizeStalls at 2.52 to 2.97 s, first manifest served at 3.66 to 4.09 s) it will keep refusing, and that is the right answer rather than a gap to close: over an empty buffer playImmediately(atRate:) is documented to act as if the buffer had emptied during playback, which is the shape that drops rate to 0 and does not recover.

The half of that join which is actually payable has moved. The gating line quoted here, first live manifest served after 2.940s: 5 segments / 10.000s >= 9.000s holdback (TARGETDURATION 3s), is #447, and the answer there turned out to be four separate reasons why a 2.000 s source ends up serving TARGETDURATION 3, two of which were the engine measuring its own wait rather than the origin's cadence. Fixed on main, details in that issue. Against the other numbers in this report (about 0.8 s to open the origin, 2.2 to 3.5 s producing the initial playlist), that gate is most of what a warm zap costs on this path, so it is the right place for the next second to come from.

One data point here is worth more than it looks. 1080i25 channels routing dispatch -> software reaching motion in 0.67 to 1.01 s while the loopback path is the slow join inverts the usual assumption, and it is not something that can be seen from this side. If the software path keeps winning on that hardware across more channels, that is its own issue and a welcome one.

Thanks for running a paired A/B and reporting a negative result. A measurement that says "the option cannot fire here, and here is the window in which it may legally fire" is worth more than one that says it did.

[tschuegy]

Re-ran the A/B on origin/main (5d35d58) with liveJoinStartsImmediately at its new true default, Apple TV 4K, 8 channels, two runs. My earlier "ineffective on this stack" verdict was measured against 6.54.0's guards, so it needed re-taking. It survives, and the new line says why on each tune:

#1 AE#440 live join: leaving the stall-avoidance wait alone (buffer ahead 0.00s, empty=true, floor 1.50s)
#2 AE#440 live join: leaving the stall-avoidance wait alone (buffer ahead 0.00s, empty=true, floor 1.50s)
#3 AE#440 live join: leaving the stall-avoidance wait alone (buffer ahead 0.00s, empty=true, floor 1.50s)
#4 AE#440 live join: leaving the stall-avoidance wait alone (buffer ahead 0.76s, empty=false, floor 1.50s)

Two different reasons, and both look correct to me:

• On the 2.000 s channels the buffer is genuinely empty at the decision point. The first-serve gate hands AVPlayer a 10 s manifest and AVPlayer has fetched nothing yet, so there is no cushion to start on. The guard is right to refuse.
• Tune Codec profile optimisation for Aether (AVPlayer) #4 (0.960 s segments) has 0.76 s ahead, non-empty but under the new 1.50 s floor. Worth recording that this is the one case that would have fired under 6.52.0's "merely non-empty" rule and no longer does. I have no evidence the old rule would have been better here, only that the raised floor is what decides it.

The frozen tail you measured is real, but on this stack it is not where the join time goes. Press to first picture and press to motion sit within ~50-110 ms of each other on every native tune:

tune	first picture	motion
1	t+3.39 s	t+3.50 s
2	t+2.82 s	t+2.87 s
3	t+2.48 s	t+2.53 s

Both numbers are downstream of the first-serve gate, which opened at 3.335 / 2.792 / 2.450 s. So the join cost here is the manifest hold, which is #447 — and that one did not move, for a reason I have written up there (ceil over an accumulated float lands maxEXTINF one ulp above 2.0). Nothing here argues against the default; it just does not reach this shape of source.

[superuser404notfound]

Re-taking an A/B against a changed guard and reporting that it now refuses is exactly what the new line was added for, so thanks for going back for it. Both refusals read correctly from here, and only one of them is interesting.

The empty ones are the reach, and they are unchanged

ToMinimizeStalls at 2.5 to 3.0 s against a first serve at 3.3 to 4.1 s means the item has fetched nothing at the instant the decision is taken, so ahead 0.00s, empty=true is the honest reading of that join and playImmediately(atRate:) there is the documented way to set rate 0 and not get it back. That half is the same conclusion as the last round, now with the number printed instead of inferred.

Tune #4 is the only case in either host's data where the lever met its own mechanism and still refused

0.76 s ahead on a 0.960 s cut, on the one channel whose gate opens early (sealed at 1s, served after 1.033 s under the fastZap bounded start). Media had been served and some of it was down, so that hold is the buffered mechanism rather than edge starvation, and the floor is the only thing that turned it away.

What I would keep, and why the floor rather than the number:

• The 1.5 s is a separator, not a model of anything. Its lower end is fixed by the fact that one served fragment reads empty=false exactly as a four second cushion does, its upper end by the cushion the admitting case actually measured, 3.7 to 4.9 s throughout every hold. 0.76 s is a fifth of that, and below one arrival interval on that source. Nothing in either data set constrains the value between those two ends, so defending 1.5 specifically would be inventing precision.
• A cushion that is still climbing can outrun a 1x playhead, so it is genuinely unknown whether firing at 0.76 s would have stalled. The raised floor buys a shorter still picture for not taking that bet, on a channel that has almost no still picture to cut in the first place.

So the old rule was not better there, it was only luckier if it happened not to stall. Worth having on record either way.

One limit worth naming while it is on the table

The decision is re-taken when the transport status changes and when the waiting reason changes, and nothing else re-reads the buffer. A refusal does not spend the one-shot, so a later edge can still fire and would print its own line, but a hold that begins below the floor and crosses it while the reason stands still gets no second look.

Nothing in either report shows that shape yet. On this stack the rate rolls 50 to 110 ms after the first data, so there is no window to look into, and on the original one the cushion reads 3.7 s and up from the first edge. If a tune ever shows ToMinimizeStalls standing for several hundred ms while the forward buffer climbs past 1.5 s, that is the case for re-reading during the hold rather than only at its edges, and I would build it on that evidence.

The one number that would sharpen tune #4

Its press to first picture and press to motion, the way tunes 1 to 3 are tabled. If that gap is also 50 to 110 ms, the refusal cost nothing measurable and the floor never has to be argued again on this source. If it is a second or more, the crossing-during-the-hold case above just acquired its first real example.

And agreed on where the join time is: everything in that table is downstream of the first-serve gate, which is #447, answered there this morning.

[tschuegy]

Retested on 6.56.0 on the device, and the answer here changed as a side effect of #447 rather than of anything in this issue. Reporting it because "the lever is out of reach on this source" was my conclusion twice, and it no longer holds.

The lever fires now

Two of the four native tunes of the run:

08:43:36.304  timeControlStatus=waitingToPlay reason=AVPlayerWaitingToMinimizeStallsReason t+2.06s
08:43:36.304  AE#440 live join: cutting the stall-avoidance wait short at rate 1.0 (buffer ahead 5.97s)
08:43:36.358  timeControlStatus=playing reason=- t+2.12s

Under 6.55.0 this path fired 0 of 8, always ahead 0.00s, empty=true. The mechanism is exactly the one both of us named: the decision is taken at ToMinimizeStalls, and whether the item holds anything by then is decided by the first-serve gate. A 9 s holdback served at 3.3 to 4.1 s, after the decision; a 6 s holdback serves at 1.2 s, before it, and the item then holds 5.97 s. So the empty refusals were never a property of this source, they were the holdback.

The other two tunes of the same run still read buffer ahead 0.00s, empty=true, floor 1.50s and still refuse. Their gate served at 2.4 and 2.5 s, which is still after the decision. Same source, same session, both readings within four minutes of each other, which is the cleanest evidence I have that the guard is reading the item correctly and not the source.

The number you asked for, and why it is not here

Press to first picture and press to motion on the 0.960 s channel, tabled like the others. I could not take it: that session never rolled at all.

08:49:22.298  first live manifest served after 0.151s: 4 segments / 3.840s >= 3.000s holdback (TARGETDURATION 1s)
08:49:23.964  [DisplayCriteria] switch settled via modeSwitchEnd (... total 1834ms)
08:49:23.964  #8 rate=1.0
08:49:23.977  #8 timeControlStatus=waitingToPlay reason=AVPlayerWaitingToMinimizeStallsReason t+1.85s
08:49:23.977  #8 AE#440 live join: leaving the stall-avoidance wait alone (buffer ahead 0.00s, empty=false, floor 1.50s)
08:49:31.886  #446 source stopped delivering (no segment finalized for 1.6s, TARGETDURATION 1s)
08:49:31.894  #8 errorLog code=-12888 domain=CoreMediaErrorDomain uri=.../media.m3u8

No isReadyForDisplay=true, no item.audioTrack, no playing. Twelve seconds without a picture and I left the channel. Note the reading itself: ahead 0.00s, empty=false, where the run that produced the last round read ahead 0.76s, empty=false on the same channel. So this join was in a worse state than that one at the same point, and the origin then confirmed it.

The origin was poor throughout this session: fourteen [AVIOReader] slow read events in seven minutes, 2.8 s to 14.0 s. I will take that measurement again on a healthy run rather than argue the floor from a join whose source was already failing.

One thing that moved into view behind this

On the two tunes where the lever fired, it fired 17 ms before playing, and 0.8 s after the item had reached readyToPlay with its first frame on the panel. What held those 0.8 s was not AVPlayer but the engine's own display-criteria gate spending its full 2 s cap. So on this stack the wait this issue is about now sits behind a larger one; I have filed that as #449. It does not change anything here, but it does mean the lever's remaining headroom on this source is smaller than the raw refusal counts suggest.

[superuser404notfound]

That is the split I did not have a way to take: same source, same session, four minutes apart, and the only difference between the two readings is whether the gate had served before ToMinimizeStalls or after it. So the refusals were the holdback, and the guard was reading the item correctly the whole time. Good that it was re-taken against a changed gate rather than left standing.

The decision point is fixed relative to the join, which means the only lever on the two tunes that still refuse is the gate in front of it, not anything in this issue. ahead 0.00s, empty=false is the item holding a range with nothing ahead of the playhead, which is exactly the state the floor exists to refuse.

The 0.960 s numbers can wait for a healthy origin. That join was already failing when the reading was taken, and the source confirmed it eight seconds later, so a floor argued from it would be argued from the outage.

On #449, that one is fixed on main in 5b461b07: the gate reads the panel per tick now, so a rate-only write for a rate the display already runs settles instead of spending the cap. It does not move the gate this issue is about, but it does mean the remaining headroom here gets measured against a criteria gate that is no longer 2 s wide.

One correction that belongs on this thread too, since the reasoning here leaned on it: the measured floor none yet in those seal lines meant there is no cadence meter on that source at all, not that the meter had nothing yet. The meter is built only for ingest sources that hand over finished segments; raw MPEG-TS is cut inside the engine. The line says so on main now (44f5dbd7).

[superuser404notfound]

Going back for the second half of this: the retest holds up, and reading it against what shipped alongside it turns the open question here into a prediction that can be measured rather than argued.

The reading that is already in those logs

The two tunes that still refuse are the interesting half now. Their gate served at 2.4 and 2.5 s, after the decision, so the refusal is correct at the instant it was taken. What is not in the tables is what the hold did next, and three timestamps per tune settle it, all of them already captured:

• waitingToPlay reason=ToMinimizeStalls
• first live manifest served after ...
• timeControlStatus=playing

If playing lands 50 to 110 ms after the serve, the way it does on the tunes that never held, then AVPlayer re-evaluates by itself the moment media arrives and there is nothing here left to cut. If it stands several hundred ms past the point where the buffer must have crossed 1.5 s, that is the shape I said I would build on, and it now has its first candidate.

Why the counts in the next run will look worse, and should

Worth saying before that run rather than after it. The lever fired on those two tunes for a reason that is about to disappear: the display-criteria gate was spending its full 2 s cap in front of play(). Tune 1 has the whole chain visible.

08:43:35.428  first manifest served (t+1.17s)
08:43:35.475  item.status=readyToPlay
08:43:36.287  [DisplayCriteria] proceed after cap (total 2038ms)  ->  rate=1.0
08:43:36.304  waitingToPlay reason=ToMinimizeStalls  ->  AE#440 ... buffer ahead 5.97s

The 5.97 s was bought by that cap. The criteria gate held play() for 0.86 s past the first serve, and the item spent that time fetching. With #449 settling a rate-only write at once, rate=1.0 moves to roughly readyToPlay, which on a 1.2 s gate is about a second BEFORE the media the guard measures. So the same joins should start reading empty=true and refusing, while press to motion stays the same or improves, because the second that gate no longer spends in front of the picture is a second the item spends fetching either way.

That is the same mechanism this thread already established, seen from the other side: the reading is decided by where the rate write falls relative to the first serve, and both gates in front of it just moved.

What is on main for it

bc20a309, observation only. A refused hold is now sampled every 250 ms for up to 5 s, which outlives both measured holds (1.55 to 2.81 s) and resolves inside the shortest, and exactly one line reports which of three things happened:

AE#440 live join: the wait was still standing 0.62s after the refusal when the buffer reached
  the floor (ahead 2.34s, floor 1.50s); observed only, the decision is still taken at the edges
AE#440 live join: the wait ended 1.81s after the refusal without the buffer reaching the floor
  (last reading ahead 0.42s, empty=false, floor 1.50s)
AE#440 live join: the wait was still standing after 5.00s of sampling and the buffer had not
  reached the floor (last reading ahead 0.00s, empty=true, floor 1.50s)

All three speak, including both negatives, because a witness that is silent when it finds nothing cannot be told from one that never ran. The sample it reports as a crossing is the guard's own verdict, asked through the same function, so the witness cannot drift away from the decision it is evidence for.

It deliberately does not start playback on that crossing. A cushion that has just passed 1.5 s and is still climbing can be outrun by a 1x playhead, which is exactly what the floor is there to refuse, and I would rather have the measurement than the bet. If the line shows holds standing well past the crossing, deciding during the hold instead of only at its edges is a small change and the evidence for it will be in hand.

Not released. On the next build, that line per refused tune is the one thing worth capturing here, and the three timestamps above can come from the run that is already on disk.

[superuser404notfound]

Shipped in 6.56.1 (bc20a309), the witness for a refused hold.

Per refused tune it emits exactly one line, and all three outcomes speak, so the absence of a crossing is reported rather than inferred from silence. That plus the three timestamps already in this morning's logs (ToMinimizeStalls, first live manifest served, timeControlStatus=playing on the two refusing tunes) is what decides whether deciding during a hold is worth building.

The same release carries the #449 fix, so the prediction in the comment above applies to the next run: rate=1.0 moves to roughly readyToPlay, ahead of the first manifest on a fast gate, and the lever should start refusing where it fired on 6.56.0, at the same or better press to motion. A drop in the fire count there is the mechanism working, not a regression.