A 5.000 s fastZap live join reaches readyToPlay and then places nothing: the item holds no loaded range at all, sustained

[superuser404notfound]

Split out of #447, which stays closed: the seal in that report is correct, as @AttiK22 says
in #447 (comment),
and none of the four terms #447 fixed can reach this. The failure is one step past every
gate that issue is about, so it gets its own thread.

Reported by @AttiK22 on 6.66.0, identical on iOS 26.6.1 and tvOS 26.5. Xtream raw
MPEG-TS over HTTP, h264 1080p50 + AAC, dispatch: codec=27 -> native (loopback),
liveJoinProfile = .fastZap, liveJoinStartsImmediately = true,
maxConcurrentSourceRequests = 1. A channel cutting 5.000 s segments reaches readyToPlay
and then never presents. The playhead does not move for the whole session.

What the capture already says, and it is sharper than it reads

Three of those fields are engine-internal and worth stating exactly, because two of them
were doing more work in that report than they can carry.

[LagDiag] clk=95258.48 dclk=0.00 tcs=waiting rate=1.00 wait=AVPlayerWaitingToMinimizeStallsReason
          fwd=- keepUp=n empty=n drop=0+0 stall=0 ready=n thermal=nominal net=6.3 restarts=0

• fwd=- is the finding. It is item.loadedTimeRanges.last?.timeRangeValue, and the
  only way it prints - is an EMPTY array. So this is not a thin buffer or a starved one.
  Twenty seconds in, the item holds no loaded range at all.
• empty=n does not contradict that. isPlaybackBufferEmpty is AVPlayer's answer about
  the ITEM, and an item that has fetched but placed nothing reads exactly this way (AE#418:
  a fetch is not a placement). The AE#440 line's ahead 0.00s, empty=false is the same pair
  seen from the other sampler.
• ready=n is playerLayer.isReadyForDisplay, not the item status, so it agrees:
  nothing has been placed to display.
• net=6.3 means an access-log entry exists, i.e. bytes did transfer. Whatever is wrong
  is not that AVPlayer asked for nothing.
• One correction to the report: size=1920x1080 fps=50.0 decoder=VideoToolbox H264 (HW) is
  published by the engine's own probe of the upstream TS (AetherEngine+Probe
activeVideoDecoderLabel), not by AVPlayer. It is not evidence that AVPlayer parsed a
  segment.

Put together: the item fetched, and placed nothing on its axis, and kept doing that for
twenty seconds while the loopback answered. That is a much narrower shape than "the join
starts late", and it is not a shape any depth gate can produce.

The first-serve path is not the discriminator

The reported correlation is over two channels: the one served AT the holdback takes the
plain path and wedges, the one served BELOW it takes the fastZap bounded start grace and
plays. Downstream of waitForFirstLiveSegment those two paths differ in the log note and in
nothing else. Both call sealLiveTargetDuration on the same value, and every playlist after
the first is built the same way.

Measured rather than argued. Synthetic 1080p50 H.264 at 6 Mbps + AAC, GOP 250 (so 5.000 s
segments), --fast-zap, liveJoinStartsImmediately on by default, five arms:

arm	origin	first serve	outcome
A	1x after a 15 s backlog	3 segments / 15.000s >= 15.000s holdback (TARGETDURATION 5s)	plays, timeControlStatus=playing t+2.53s
C	150 s backlog, then 1x	same line, served after 0.058 s	plays at t+0.24s
BIG	as A, item axis at 95258.00 s	same line	plays at t+0.24s
R18	sustained 1.8x, 60 s	same line	plays, ends 49 s behind live, never holds
COMBO	sustained 1.6x + axis 95258.00	same line	plays through 60 s

So the exact first-serve line quoted in the report, 3 segments / 15.000s >= 15.000s holdback (TARGETDURATION 5s), is reproducible here five ways and joins every time. Serving
at exactly 3 x TARGETDURATION is a boundary, but it is not this.

Two suspects that arm R18 and arm BIG exist to kill, because both were worth taking
seriously:

• A live edge that outruns wall clock. The report's own intermittency points at a race
  (startup routed +946ms wedges, +11182ms plays), and the producer really is running
  ahead: 1820 written packets over 20.07 s is about 1.59x realtime measured against a
  paced arm here. aetherctl live could not drive that shape at all, since --realtime is
  exactly 1x and an unpaced fixture hands over one burst and stops, so --realtime-rate X
  now holds the origin at X times wall clock for the whole run (f3775c1). At 1.6x and 1.8x
  sustained the join is fine. The viewer falls further and further behind live, which is its
  own honesty question, but the rate rolls and stays rolled.
• The item axis near the 33-bit PTS wrap. clk=95258.48 is 185 s below 2^33 / 90000 = 95443.72 s, and at 90 kHz that is 8.573e9 ticks, past UINT32_MAX. A 32-bit tfdt would
  have explained every observable in this report exactly. Arm BIG and arm COMBO put the
  fixture's own axis there (prodShift=95258.00s) and both play, so the axis survives that
  value end to end.
• The pump is healthy on the reported numbers too: packetsRead=3501 packetsWritten=1820 is
  a ratio of 1.923, against 1.937 / 1.937 / 1.938 in three healthy runs here.

What ships now, because the next capture should not need this thread

ahead 0.00s is two different facts and the line printed one word for both.
contiguousBufferedEnd returns the playhead itself whenever no range touches it, so an item
that has placed NOTHING and an item holding media somewhere ELSE collapse onto the same
number, with empty=false true in both. Those need opposite investigations. The
discriminating fact was already in the capture, in a 1 Hz verbose line from a different log
that nobody reads against this one.

The refusal and the witness account now name which zero they measured (1ad185c):

AE#440 live join: leaving the stall-avoidance wait alone (buffer ahead 0.00s, empty=true,
  floor 1.50s); the item holds no loaded range at all, so nothing has been placed on its
  axis since it was mounted (playhead 0.00s)

and, where a range exists but not at the playhead, the count and the signed distance to the
nearest one, which is the reading that separates "the fetch never landed" from "the item and
the playlist disagree about where the media is". Only when the cushion reads zero; a real
depth still leads with the number the decision is taken on.

What would decide it

Not released yet. Three things from a failing session, all of which the existing build
already produces:

1. Every [HLSLocalServer] line, with timestamps. The report quotes one 200 for
   /seg6.mp4. What matters is the whole sequence: whether init.mp4 was fetched, which
   segment indices were asked for in what order, and whether any request was held rather than
   answered. An item parked at the start of the window that only ever asks for the newest
   segment is a different bug from one that fetches seg0 and places nothing.
2. item.errorLog() and item.error at the moment the watchdog fires. restarts=0 and
   stall=0 say the engine saw nothing; AVFoundation may have.
3. One A/B with LoadOptions.liveBlockingReload = false. That is the arm that separates
   "AVPlayer stopped fetching because it is in low-latency blocking-reload mode" from
   everything else, and it is a one-line change on the host side.

And if the #EXT-X-MAP line in a failing session ever names init1.mp4 rather than
init.mp4, say so: an init version change inside the first window would be a third mechanism
again and is worth ruling in or out before anything else.

Thanks for the capture. The three logs in it are what made the first pass possible at all,
and the correction above about size= / decoder= is the only thing in it that was reading
further than it can.

[AttiK22]

All three points captured. Short version: AVPlayer fetches the window exactly as it
should — init first, then every segment in order, all answered 200 — and places none of
it, with no error anywhere and item.status never leaving .unknown.

6.66.0, iOS 26.6.1, channel 394617, three consecutive failing joins.

1. The item, at the moment our stall watchdog ends the session

KIPDIAG AVDIAG stop playhead=95173.75 ranges=[NONE (nothing placed)] bufferEmpty=false likelyToKeepUp=false status=0 err=-
KIPDIAG AVDIAG accessLog segsDownloaded=8 bytes=25624062 stalls=0 durationWatched=0.00

KIPDIAG AVDIAG stop playhead=95181.57 ranges=[NONE (nothing placed)] bufferEmpty=false likelyToKeepUp=false status=0 err=-
KIPDIAG AVDIAG accessLog segsDownloaded=5 bytes=12928580 stalls=0 durationWatched=0.00

ranges is item.loadedTimeRanges printed directly: empty array, as you read off
fwd=-. bufferEmpty=false beside it is the pair you described — a fetch is not a
placement.

What the access log adds:

• 8 segments / 25.6 MB transferred on the first join, 5 / 12.9 MB on the second. So
  AVPlayer pulled the whole served window, not a token first fetch.
• durationWatched=0.00 against those 25 MB.
• numberOfStalls=0, from AVPlayer's own accounting rather than the engine's.

And nothing anywhere reports a failure:

• item.status = 0 (.unknown) — the item never reaches readyToPlay at all, for the
  whole 20 s. It is not failing to place media after becoming ready; it never becomes ready.
• item.error = nil.
• item.errorLog() = empty, no events (the dump prints the last 5 when present).

2. Every [HLSLocalServer] request, and it is textbook

Same shape on all three sessions:

GET /master.m3u8              -> 200 (235 B)
GET /media.m3u8               -> 200
GET /media.m3u8?_HLS_msn=3    (blocking reload, on its own connection)
GET /init.mp4                 -> 200 (1283 B)
GET /seg0.mp4                 -> 200 (3794485 B)
GET /seg1.mp4                 -> 200 (3898598 B)
GET /seg2.mp4                 -> 200 (3491298 B)
GET /seg3.mp4 … /seg7.mp4     -> 200, each as the playlist grows
-> 503 /media.m3u8 reason=blocking reload msn=8 unsatisfiable    <- only after our watchdog tore the session down

Against the three things you wanted ruled in or out:

• init.mp4 is always fetched, and always before any segment. This is not an item
  that only asks for the newest segment.
• Sequential from seg0, no gaps, no repeats, no reordering.
• No request was held rather than answered. Every GET has its 200, and AVPlayer opens
  a separate connection for the blocking reload (fd=40) from the one it fetches media on
  (fd=41), so the reload is never behind a segment.
• #EXT-X-MAP:URI="init.mp4" on every playlist — never init1.mp4. No init version
  change inside the first window.

The only non-200s in the whole capture are the 503 blocking reload … unsatisfiable that
lands at the msn after the last segment, and it arrives after our watchdog has already
stopped the session, so it is downstream of the failure rather than part of it.

The served playlist, in case the shape matters

#EXTM3U
#EXT-X-VERSION:7
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,HOLD-BACK=15.000
#EXT-X-TARGETDURATION:5
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-DISCONTINUITY-SEQUENCE:0
#EXT-X-SODALITE-REFRESH:1
#EXT-X-MAP:URI="init.mp4"
#EXTINF:5.000,
seg0.mp4
…

Master advertises avc1.64002A,mp4a.40.2, 1920x1080, FRAME-RATE=50.000, VIDEO-RANGE=SDR.

One observation I cannot evaluate from here: init.mp4 is 1283 bytes, byte-identical
across all three failing sessions and the same size as on the channel that plays. I have
no way to tell whether that is a correct init for this track combination, so I mention it
as a number rather than a suspicion — but since the item never leaves .unknown and the
init is the one thing it parses before any segment, it seemed worth stating.

3. liveBlockingReload = false

Wired behind a host flag but not run yet — I wanted these two captures clean first, and
the A/B is one build away. Say the word and I will take it. Given that the 503 only
appears after teardown, I would not expect blocking-reload mode to be the mechanism, but
it is your arm and it costs me nothing to run.

Two smaller things

The playhead reads 95173.75 and 95181.57 on two different sessions, so the item mounts
already parked around 26 h in, consistent with the original clk=95258.48. I take your
point that arms BIG and COMBO put the fixture's axis at 95258.00 and played through; I
note it only because here the value arrives from the real source rather than being imposed
on the fixture.

Provider is an Xtream panel behind a redirect chain (beyg7x.msyaa.com folding to
1_47x.aveta.top:8080). Segments are cut here at 5.000 s; the TS is h264 1080p50 + AAC
with a third dvb_teletext stream that is never selected.

Reproduces on demand, several times in a row — happy to run a patched build.

[AttiK22]

One more data point, from outside my own app: the same channel fails on a second,
unrelated Aether host.

I loaded the same Xtream playlist into a different app that integrates
AetherEngine (not mine, so I have no logs from it and no way to see its engine version)
and tried the same two channels:

• 394617 — spinner, never plays, and eventually surfaces an error.
• 253394 — plays normally, same as in my app.

So the failing/working pair reproduces on an integration I did not write. Whatever this
is, it is not in my host code.

Two honest limits on that: it is the same source and the same provider, so it does not
separate "the engine mishandles this stream" from "this stream is malformed in a way the
engine trips on" — and I could not capture anything from that app, so this is a visual
reproduction only.

One difference worth noting: the other app ends up showing an error, where my app just hangs until
my own 20 s stall watchdog reloads. Same engine, same source, different visible outcome —
presumably whatever load timeout that host applies. The engine-side failure looks
identical from the user's side up to that point.

For completeness on the other direction: KSPlayer plays 394617 without trouble (it is
the next engine in my fallback chain), so the TS itself is decodable — the sources in
question are not broken beyond use.

[superuser404notfound]

Three answers, and they reframe the thread. In the order that matters.

Do not run the liveBlockingReload = false arm. Your instinct was right and now the log says it too: init first, every segment in order, every request answered, and the only 503 arriving after teardown. Nothing in that shape is about how the playlist is reloaded. Keep the build for something better, below.

The one that changes everything is item.status = 0. Round one had this at readyToPlay, so I spent it looking for a placement problem on a ready item. An item that never leaves .unknown while 25 MB lands is a different question, and the four hypotheses I killed last round were answering the wrong one.

What I found, and reproduced here

tfdt carries unsigned int(64) (ISO/IEC 14496-12), and the loopback muxer deliberately runs with avoid_negative_ts=disabled so that tfdt carries absolute output timestamps across producer restarts. So a negative output axis is not merely unusual for us, it has no representation at all: movenc writes the bits, AVPlayer reads baseMediaDecodeTime = 2^64 - |dts|, and against a playlist that starts at 0 that lands about six million years away.

The producer had exactly one path that could publish that. A gate that opens BELOW a segment's advertised start keeps its own timestamp rather than the advertised one (an overlap is what AVPlayer absorbs, a hole is what it waits on forever), and that comparison was free to go below zero. The audio side of the pump already knew this was fatal and dropped any packet whose output DTS went negative, with a comment naming the unsigned tfdt as the reason. Video was assumed non-negative, because the shift is normally what makes it so.

Negative timestamps out of an MPEG-TS are not corruption, they are libavformat working as designed. A stream whose first DTS sits within 60 s of the 33-bit PTS wrap (2^33 / 90000 = 95443.72 s) is classified AV_PTS_WRAP_SUB_OFFSET in update_wrap_reference, after which every timestamp comes out 2^33 ticks low. demux.c says it in as many words, "correct first time stamps to negative values". One ffmpeg flag reproduces it: -output_ts_offset 95390 reads back as pts_time=-53.717689.

Driven through the live path on a 1080p50 H.264 + AAC fixture cut at 5 s, joined with fastZap, the playlist coming out byte-shaped like yours (VERSION:7, HOLD-BACK=15.000, TARGETDURATION:5, MEDIA-SEQUENCE:0):

before

video gate open: actual=-4834592 desired=0 pinnedTo=-4834592 shift=0
seg0: tfdt baseMediaDecodeTime=18446744073704717024   (video traf only, audio dropped)
VERDICT: live FAIL (t=-53.72s, edge=0.00s)

The clock never moved off the join point for the whole session, and the item held no loaded range at all while the window was fetched. That is your capture, line for line.

after (3f31aaed on main, not released)

video gate open: actual=-4834592 desired=0 shift=-4834592
seg0: tfdt baseMediaDecodeTime=0 on both trafs, audio back in seg0
clock runs -53.02s to -28.32s over 25 s, 0 stalls

What I cannot claim

That this is your session. Your three clocks (95173.75, 95181.57, 95258.48) sit 185 to 270 s below the wrap, and the window libavformat classifies on is the last 60 s. By your own numbers your stream is on the other side of that line.

What stands on its own is that all three sit in the top 0.3% of a 26.5 hour cycle, in two captures days apart. That is not where a free-running clock lands twice by chance, and it is the one structural property your two channels can differ on.

Three things, all small, any one of which settles it

1. The gate line from a failing session. 6.66.0 already prints it: [HLSSegmentProducer] video gate open: actual=... desired=... shift=.... If this is the mechanism it reads pinnedTo=<negative> with shift=0. That field prints only when it differs from desired, so its bare presence on a fresh join is the whole answer.

2. The first 4 KB of a failing seg0.mp4, straight off your own loopback server. The tfdt in there is the question: 0 says the axis is fine and I am looking in the wrong place, 18446744073... says it is this.

3. A 30 s raw capture of the upstream TS for 394617 and for 253394 (the files, not the URL, so no credentials leave your side). aetherctl live --seed <ts> replays a real capture through this same live path here, which would take the whole thing off your device.

On the init byte count: mine for the same track pair is 1231 bytes, so your 1283 is an ordinary two-track moov. A third trak costs several hundred bytes, not 52, so the teletext PID is not in the container and that number is not a suspicion worth carrying.

The second host reproducing it was worth going and getting, and KSPlayer playing the same TS is the other half of it: the source is decodable, so the finger points at what we hand AVPlayer rather than at what the provider sends.

[AttiK22]

Point 1 answered straight away, and I think it says no — the gate line was already in
the captures I had.

Skipping the liveBlockingReload arm as instructed.

The gate line, three failing joins, three different sessions

video gate open: actual=1973700001 anchorPts=1973700001 target=-9223372036854775808 desired=0 shift=1973700001 videoPID=0 reconstructed=false
video gate open: actual=2357100001 anchorPts=2357100001 target=-9223372036854775808 desired=0 shift=2357100001 videoPID=0 reconstructed=false
video gate open: actual=2203200001 anchorPts=2203200001 target=-9223372036854775808 desired=0 shift=2203200001 videoPID=0 reconstructed=false

No pinnedTo field on any of them, and actual is positive on all three. Since that
field prints only when it differs from desired, its absence is the answer you described:
on these sessions the gate did not pin below zero.

For the arithmetic: actual=2203200001 at 90 kHz is about 24 480 s, positive and nowhere
near a negative axis. The shift equals actual on every one, which is the ordinary
case where the shift is exactly what makes the output axis start at zero.

So unless the mechanism can reach the tfdt by some path that does not go through this
line, my sessions are not the negative-tfdt case. Which matches your own caveat about the
wrap window: my clocks sit 185–270 s below it, outside the 60 s libavformat classifies on.

Points 2 and 3

I will get both, since point 1 came back negative and that makes them the deciding
evidence rather than a confirmation:

• First 4 KB of a failing seg0.mp4 off my own loopback server.
• 30 s raw TS capture of 394617 and 253394, as files.

Give me a little time on the raw captures — I want to take them cleanly and check they
carry no account identifiers before they leave here.

One thing your reframing makes me want to state precisely

You noted the three clocks land in the top 0.3% of the 26.5 h cycle across captures days
apart, which is not chance. I cannot explain that either, but I can add a fourth and fifth
reading now, from today's captures, both from the AVDIAG dump rather than from LagDiag:

playhead=95173.75
playhead=95181.57

Same neighbourhood again, third capture on a different day. And the working channel
(253394) is on the same provider and the same panel, so whatever puts 394617 there is a
property of that channel rather than of the account or the edge.

I will post the segment header and the TS captures as soon as I have them.

[AttiK22]

Two things, one awkward and one useful.

The awkward one: 394617 plays now

As of a few minutes ago it joins on Aether, first try, perfectly. No change on my side, no
rebuild, same playlist. The last few hours in order:

1. Yesterday and this morning: fails on Aether every time, plays on KSPlayer.
2. A couple of hours ago: stopped playing on everything — Aether, KSPlayer, VLC and
   mpv all failed. Taking the raw capture at that moment, the panel answered 407 for
   that channel specifically, while the same run against 253394 succeeded and pulled 17 MB.
   So it was that one channel being refused, not my connection cap or my network.
3. Now: plays fine.

So the channel went through an outage and came back, and I cannot produce a failing session
on demand any more. I would rather tell you that than let you keep working against it.

I do not think this explains away yesterday, because two things from those captures are not
what a dead channel looks like: AVPlayer transferred 25.6 MB across 8 segments, all 200,
and placed none of it; and KSPlayer played the same channel at the same time, repeatedly,
over two days. But I cannot prove the outage was not already contributing, so treat
yesterday's numbers with that caveat.

The useful one: I have both raw captures, and they differ structurally

I got 30 s of each before the outage cleared — including 394617, which I did manage after
all (33 MB; the 407 was transient).

The GOP is 5x different, which is where your holdback comes from:

394617 (fails):  keyframes every 5.00 s  ->  TARGETDURATION 5  ->  holdback 15.000 s
253394 (works):  keyframes every 1.00 s  ->  TARGETDURATION 1  ->  holdback  3.000 s

Measured off the captures with ffprobe -select_streams v:0 -show_entries packet=pts_time,flags:
394617 gives 5.00 s between every keyframe (9 in 30 s), 253394 gives 1.00 s (47 in 30 s).

That is the actual difference between my two channels, and it explains the correlation I
reported in #447 without needing the "served AT vs BELOW the holdback" reading you already
disproved: the two channels were never comparable on that axis, they seal five TARGETDURATION
units apart. It also means my failing case has the longest GOP anyone has brought to this
thread — @tschuegy's were 2.000 s and 0.960 s, and your own fixture cuts at 5 s.

The rest of the comparison:

394617 (fails):  h264 High@4.2  1920x1080  50 fps  progressive  yuv420p  + AAC-LC 48k stereo + dvb_teletext
253394 (works):  h264 Main@3.2  1280x720   50 fps  progressive  yuv420p  + AAC-LC 48k stereo

On your negative-timestamp question, for whatever it is worth on a healthy capture: neither
is anywhere near the wrap. First video PTS is 942300000 (10470.00 s) on 394617 and
559805400 (6220.06 s) on 253394, against 2^33/90000 = 95443.72 s. But these were taken now,
not during a failing session, so they say nothing about where the clock sat when the item
was mounting at ~95200 s.

What you can have

Both .ts files, 30 s each, straight off the origin with no re-encoding: 394617 (33 MB)
and 253394 (17 MB). Tell me where to put them and they are yours — they carry no
credentials, just the streams. aetherctl live --seed on the 5 s one is presumably the
fastest way to find out whether this reproduces off my device entirely.

The seg0.mp4 header dump is wired into my build now and fires automatically on a failing
teardown, so if this channel goes bad again, or another one does, I will have it without
another round trip.

[superuser404notfound]

Point 1 is answered, and it says more than "not the negative case". I built the twin and it
changes where the evidence lives.

Your gate line is not merely free of pinnedTo, it is the shape of a session that works

Fixture cut to your channel's structure: 1080p50 H.264 High@4.2 at 6 Mbps, keyframes every
5.000 s, AAC-LC 48 kHz stereo, no B-frames (which is what makes your line carry no lead=
field and anchorPts equal to actual), and the whole thing offset onto your axis with
-output_ts_offset 21930. Joined with fastZap through the same live path.

yours   actual=1973700001 anchorPts=1973700001 target=-9223372036854775808 desired=0 shift=1973700001 videoPID=0 reconstructed=false
mine    actual=1973700000 anchorPts=1973700000 target=-9223372036854775808 desired=0 shift=1973700000 videoPID=0 reconstructed=false

One 90 kHz tick apart, field for field. The rest of that run:

live TARGETDURATION sealed at 5s (holdback 15.000s)
first live manifest served after 0.000s: 3 segments / 15.000s >= 15.000s holdback (TARGETDURATION 5s)
init.mp4 captured (1232 B)
JOIN: sustained clock advance from 1.1s after load start
VERDICT: live playing (t=21957.30s, edge=21955.03s)
prodShift=21930.00s hostShift=21930.00s

So every number the producer publishes about your failing joins is indistinguishable from a
session that plays through. Whatever is wrong is not in the axis, the shift, the seal, the
holdback or the first serve. It is in the bytes of the segments, or in what AVPlayer does
with them. That is a narrower place than this thread has had so far, and it makes your
points 2 and 3 the entire remaining evidence rather than a confirmation of anything.

Your gate lines also close the wrap question from the other side

1973700001 / 90000 = 21930.00 s
2357100001 / 90000 = 26190.00 s
2203200001 / 90000 = 24480.00 s

Six to seven hours into the encoder's clock, positive, and 2^33 / 90000 = 95443.72. So the
source axis of your three failing sessions was never anywhere near the wrap, which my arms
BIG and COMBO were built to test and which your own logs had already settled. Good, that
retires it.

Which makes playhead=95173.75 the sharpest thing in the thread

With shift=1973700001 the engine publishes AVPlayer item time + 21930.00, and the item's
first tfdt is 0 against a playlist starting at MEDIA-SEQUENCE:0. So on that session the
published clock should read 21930.00 while nothing is placed, and mine does exactly that
(t=21930.74s on the first tick). For playhead to read 95173.75 in the same session,
AVPlayer's item clock would have to sit at 73243.75 s. If playhead is AVPlayer's own
currentTime() rather than the engine's, then it reads 95173.75 on an axis that starts at 0.
Either way, two numbers out of one session are describing different axes, and one of them is
not measuring what its name says.

There is a second reason to distrust it as a clock. Your five readings are 95173.75,
95181.57 and 95258.48, which is 26.437 h, 26.439 h and 26.461 h: all of them inside an
85 second span, in captures days apart, and each 185 to 270 s below 2^33 / 90000. A
free-running clock does not land twice in the same 85 seconds of a 26.5 hour cycle. Something
anchored does, and what it is anchored to is the wrap constant itself.

So the one question that costs you a grep in files you already have: which API does
playhead= read? Name it, and quote one capture where the gate line and the playhead
line come from the same session, side by side. If they disagree the way the arithmetic above
says they must, that disagreement is the defect and it is measurable from your existing logs.
Round one spent itself on readyToPlay taken from a report instead of a measurement, and I
would rather not do that twice with this field.

The GOP finding is a real correction, and it does not reproduce here

5.000 s against 1.000 s explains the correlation you reported in #447 better than the
"served AT versus BELOW the holdback" reading, and it retires that reading properly: the two
channels seal five TARGETDURATION units apart, so they were never comparable on that axis at
all. Worth having.

It is not by itself the mechanism. The fixture above cuts at exactly 5.000 s, seals
TARGETDURATION 5 with HOLD-BACK 15.000, serves the first manifest at `3 segments / 15.000s

= 15.000s`, and plays. Longest GOP in the thread, same first-serve line as yours, no wedge.

On the outage

Taken as stated, with your caveat. It does not read as a dead channel from here either:
25.6 MB across 8 segments, every one answered 200, durationWatched=0.00, and KSPlayer
playing the same channel repeatedly across two days. A refusal does not transfer 25 MB. The
407 sits after all of that, so I am treating it as a separate event rather than as the cause,
while accepting that I cannot prove it was not already building.

Telling me you can no longer reproduce it, rather than letting me keep working against it,
was the right call and it cost you something to make. Thank you.

The captures: yes, and one caution about where

Both files please, 30 s each, no re-encoding, exactly as you took them. Do not attach them
to this issue. That is not a privacy point, you have already checked the credentials: it is
that a public thread is the wrong place for 30 seconds of somebody's broadcast. Any transfer
service you like, link in the thread or wherever you prefer to put it, and I will pull them
straight down.

What they get run through, in this order:

1. aetherctl live --seed 394617.ts as taken, with 253394 as the control arm. That is the
   whole live path on this side, so a wedge here takes the case off your device entirely.
2. The same seed re-offset onto each of the three axis positions your gate lines report
   (21930, 26190, 24480 s). A capture taken now carries a different clock, and the axis is
   free to set.
3. A --realtime-rate 1.6 arm, since your producer measured about 1.59x realtime while
   failing, and a restreamer serving from a standing buffer is the shape that keeps handing
   over faster than the content happens.

Where the twin above stops, so you know what it does and does not cover: synthetic picture
rather than a broadcast encoder's SPS (your init at 1283 B against my 1232 B is consistent
with a real VUI and HRD block, nothing more), no dvb_teletext PID in the PMT, and loopback
has no latency. Your captures carry all three of those, which is exactly why they are worth
having.

The seg0.mp4 header firing automatically on a failing teardown is the best thing in your
last message. When the next channel goes bad, that plus the paired gate line settles it in
one round.

[superuser404notfound]

Unrelated to your own capture, but it came out of the same investigation and it is in 6.74.0 (3f31aaed): a live join whose first DTS falls within 60 s of the 33-bit PTS wrap was publishing a negative axis, which tfdt cannot represent, so movenc wrote 2^64 - |dts| and AVPlayer placed nothing. That is the same outcome as your report, and it is worth ruling out on your source even though your gate lines sit at 21930, 26190 and 24480 s, well clear of the wrap.

The rest of the thread stands as it was: the healthy twin at your axis plays, so the defect is in the segment bytes, and the two 30 s raw captures plus the API behind playhead=95173.75 are still what would move it.

[AttiK22]

Noted on 6.74.0 / 3f31aaed, and understood that it is unrelated to my capture —
my gate lines at 21930, 26190 and 24480 s are hours clear of the wrap, as you say.
I will move to it anyway and confirm whether anything changes on my source, though
I am not expecting it to.

Now the two things you actually asked for.

playhead= is AVPlayerItem.currentTime().seconds, read directly off the item, with
no engine value anywhere near it. Here is the whole function that prints it:

guard let item = host?.avPlayer?.currentItem else { … }
let ranges = item.loadedTimeRanges.map { $0.timeRangeValue }
let playhead = item.currentTime().seconds
print("KIPDIAG AVDIAG \(reason) playhead=\(String(format: "%.2f", playhead)) ranges=[\(rangeDesc)] …")

ranges on the same line is item.loadedTimeRanges from the same item, one statement
earlier, so the two fields cannot be describing different objects. That is the second half
of your arithmetic: AVPlayer's own item clock, on an item whose first tfdt is 0 against
MEDIA-SEQUENCE:0, reading 95173.75.

Which is your point, and I had not seen it. On a session where the engine publishes
shift=1973700001 (21930.00 s), the item's own axis should start at 0 and your twin reads
t=21930.74 on the first tick. Mine reads 95173.75 out of currentTime() on an axis that
should start at zero.

The honest limit on that

I have to flag it rather than let it stand: the gate lines and the playhead readings come
from different captures. The three video gate open lines are from the run I posted
first; playhead=95173.75 and 95181.57 are from the AVDIAG dump I added afterwards, a day
later. So I cannot hand you the side-by-side you asked for from what I already have, and I
am not going to imply I can — that is exactly the round-one mistake you named.

Both lines are in the build now and both fire on every session, so a single capture with
the two together is one reproduction away. The channel currently plays, so I need it to go
bad again, or another channel to do it.

What I can rule out about the field right now

• It is not the engine's clock: no AetherHost or AetherEngine value is read in that
  function. Only host?.avPlayer?.currentItem, then item.* throughout.
• It is not a stale item from a previous session: the dump runs inside stop(), before
  anything is torn down, on whatever item the player currently holds.
• It is not our own offsetting: nothing in that path adds a shift, a start position or a
  presentation origin. The value is printed exactly as currentTime() returned it.

The 85-second clustering across captures days apart is yours to interpret better than mine,
but I take the point that a free-running clock does not do that and an anchored one does.

The twin

That you reproduced the gate line to within one 90 kHz tick, on a fixture cut to the same
structure and offset onto the same axis, and it plays — that is the most useful thing anyone
has put in this thread, mine included. It narrows it to the segment bytes or to what
AVPlayer does with them, which is where points 2 and 3 now live.

The captures

Both files, as taken, no re-encoding: 394617 (33 MB) and 253394 (17 MB), 30 s each.
Understood about not attaching them here, and I agree with the reasoning. Here's the WeTransfer URL: https://we.tl/t-Gz8AYHtw52BKVKO3

The seg0.mp4 header dump is armed and fires automatically on a failing teardown, so the
next reproduction gives you the tfdt, the gate line and the playhead in one capture.

[superuser404notfound]

Both captures pulled and run. The short version: your bytes do not wedge here in eight arms,
your playhead field is fine and measures exactly what its name says, and the pairing you
flagged as missing was carrying more of my last message than it could. What did come out of it
is one arm that reproduces two of your three fields exactly, on your own bytes.

What the captures are

394617: H.264 High@4.2 1920x1080 50 fps progressive (PID 0x100), has_b_frames=0, AAC-LC
48 kHz stereo (0x101), dvb_teletext (0x102), 6.03 Mbps, source axis 10470.000 s, 44.28 s.
253394: Main@3.2 1280x720 50 fps, has_b_frames=2, AAC-LC, axis 6220.06 s, 46.63 s.
Both end on a partial TS packet (52 and 36 bytes), harmless, trimmed before use.

Worth noting that 394617 really does carry no B-frames while the control channel does. That is
the same fact your gate line carried by not printing a lead= field, now read off the stream
itself rather than inferred from the log.

Eight arms, all play

Your seed as taken, 253394 as the control, your seed re-offset onto each of your three gate-line
axes (21930 / 26190 / 24480 s), onto both of your playhead values (95173 / 95258 s), and at
--realtime-rate 1.6. Every one joins and plays through. So the real broadcast SPS, the real
teletext PID and the real 5.000 s GOP, the three things my synthetic twin could not carry, do not
change the outcome. The captures were taken healthy and they are healthy here.

One thing they do settle: the init.mp4 the engine builds from your bytes is 1271 B, against
your 1283 B in the field and my synthetic 1232 B. So the real parameter sets account for 39 of the
51 bytes you could not evaluate, and the remaining 12 is a parameter-set difference, not a track.
Your init is a normal two-track init.

Your answer exposed a gap on my side, and it was mine

playhead reads the ITEM clock. This harness prints the engine's PUBLISHED clock, which is
item + playlistShiftSeconds. On your axis those two are 95173 seconds apart in a session that is
working perfectly, so your number and mine were never comparable. Both print now (16be4b56, not
released), and here is a healthy join on your bytes at your axis:

state=playing isLive=true t=95173.70s edge=95178.00s item=0.75s ranges=1 status=1

Against your capture: playhead=95173.75 ranges=[NONE] status=0. Same published position, and the
item is 95173 seconds away from where a healthy one sits.

The arm that matters

I put your bytes on an axis inside the wrap window (-output_ts_offset 95390, which libavformat
corrects to -53.717689) and restored the pre-3f31aaed behaviour, which is the 6.66.0 you
reported on:

video gate open: actual=-4834592 anchorPts=-4834592 desired=0 pinnedTo=-4834592 shift=0
state=playing isLive=true t=-53.72s edge=0.00s origin=9.3MB  item=0.00s ranges=0 status=0
state=playing isLive=true t=-53.72s edge=0.00s origin=24.0MB item=0.00s ranges=0 status=0

ranges=0 and status=0 for the whole run while the origin byte count climbs. That is your
ranges=[NONE (nothing placed)], your item.status never leaving .unknown, and your 25.6 MB
across 8 segments, on your own stream. The same arm on current main plays.

The one field it does not produce is playhead, which reads 0.00 rather than a large number. So
the wedge SHAPE is a defect that is found, reproduced and fixed in 6.74.0; the VALUE of your
playhead is not explained by it. I also forced a positive raw axis into the tfdt and the item
stayed 0-based and played, so that is not the other half either.

Two corrections to my own last message

The arithmetic I built on playhead versus the gate line needed them to be one session, and you
were right to say they are not. With the pairing gone, playhead measures exactly what its name
says and nothing about it is suspect.

The clustering claim was also weaker than I put it. Two of the three readings (95173.75 and
95181.57) are consecutive joins seconds apart in one sitting, so they are one sample, not two.
That leaves two independent readings in the top 0.3% of the cycle, which is worth noticing and is
not what I described.

I also drove the mount seek with a wrong-axis anchor (--start-position 95178 on a 15 s item) since
it was the remaining way to put an item somewhere it cannot reach. AVPlayer clamps it and joins
normally, so that is dead too. It is logged now either way.

The one line that would settle it

The video gate open: line of a FAILING session. If it reads pinnedTo=<negative> shift=0 the way
the arm above does, then 6.74.0 is your fix and the move you have already made is the whole answer.
If it reads a positive shift like your healthy captures do, this is a second mechanism and the
seg0.mp4 tfdt you have armed is the next thing to look at.

Thanks for the captures, and for flagging the capture boundary yourself. That correction cost you
the strongest-looking point in the thread and it was the right call.

[superuser404notfound]

Released in 6.75.0 (f436d89). The harness half of this is in the tag: aetherctl live now prints item=<s> ranges=<n> status=<n> next to t= and edge=, so a capture from here can be compared field for field against a host's own numbers, and live --start-position S drives a join with a resume anchor. ranges=0 is the field that separates a fetch from a placement.

[AttiK22]

Both messages read. Three things from my side, one of which limits what I can still give
you.

I am on 6.74.0, and now 6.75.0

I moved to 6.74.0 before your last two comments landed, and to 6.75.0 this morning. Which
creates the awkward part: the video gate open: line of a failing session on 6.66.0 is
no longer something I can produce. The channel plays, and the build that would have shown
the pre-3f31aaed behaviour is gone from my side.

If 394617 wedges again on 6.75.0, that is by itself the answer to your question — it would
mean a positive shift and a second mechanism, since the negative-axis case is fixed in
the build it would be running on. I will capture the gate line, the seg0.mp4 tfdt and the
AVDIAG dump together if it happens.

The arm on my own bytes is the strongest result in this thread

video gate open: actual=-4834592 anchorPts=-4834592 desired=0 pinnedTo=-4834592 shift=0
state=playing isLive=true t=-53.72s edge=0.00s origin=9.3MB  item=0.00s ranges=0 status=0
state=playing isLive=true t=-53.72s edge=0.00s origin=24.0MB item=0.00s ranges=0 status=0

ranges=0 and status=0 while the origin byte count climbs, on my stream, is my capture
line for line — including the 25.6 MB that never became a placement. That it plays on
current main is the part I care about.

I take your point that the playhead value is not explained by it. Noted rather than
argued: I have no theory for 95173.75 either, and with the pairing gone I have nothing to
build one on.

What 6.75.0 makes possible from here

item=<s> ranges=<n> status=<n> next to t= and edge= is exactly the pairing my own dump
already prints:

KIPDIAG AVDIAG stop playhead=<item clock> ranges=[…] bufferEmpty=… status=…

So a future capture of mine and an aetherctl live run of yours are now directly
comparable field for field, without either of us having to explain which clock we meant.
That was the thing that cost this thread a round, and it is closed.

On the corrections

You withdrew the playhead-versus-gate-line arithmetic and softened the clustering claim
without being pushed on either. I would rather say plainly that I noticed: it is the same
discipline you applied to my readyToPlay in round one, turned inward, and it is why the
evidence in this thread has held up.

Where I am: running 6.75.0, watching for a recurrence, instrumented to capture the gate
line, the segment header and the item state in one shot if it comes back. If it does not
come back at all, then as far as my source is concerned this was the negative-axis case and
3f31aaed was the fix.

[superuser404notfound]

Understood on 6.66.0 being gone, and it is not worth chasing. The arm on your own bytes already
produces the shape that line would have shown, so capturing it now would confirm something that
is already reproduced rather than decide anything. What neither of us gets from it is the
playhead value, and I would rather leave that recorded as unexplained than attach it to a
mechanism it does not follow from.

What your last two messages did change here is one thing on this side, and it is the gap that
cost this thread the most.

item.status was never in an engine line

The engine carries item.status on a KVO observer, which fires on a CHANGE. An item that comes
up .unknown and never leaves it therefore produces no status line at all: the engine is silent
about the item in exactly the state where the item is the question. That is why the
discriminating field in your capture came out of your own KIPDIAG AVDIAG dump and not out of
anything we print, and it is why round one ran on readyToPlay from the report instead of
.unknown from a measurement.

The live-join account already takes one batched off-main reading of the item (AE#422), so the
status now rides along in it and both accounts carry it. Measured on the reproduced defect, with
the pre-3f31aaed behaviour restored locally and a seed at -output_ts_offset 95390:

AE#440 live join: leaving the stall-avoidance wait alone (buffer ahead 0.00s, empty=true,
floor 1.50s); the item holds no loaded range at all, so nothing has been placed on its axis
since it was mounted (playhead 0.00s), and the item's own status has not left unknown, so
AVPlayer has not accepted the media at all

The two values point opposite ways, which is the reason to print it: .unknown is AVPlayer never
accepting the media, so the segment bytes are the place to look, while .readyToPlay is an
accepted item that places nothing, which points at the fetch. A healthy join carries no clause at
all, as before.

16ff9ad3 on main, not released, it rides the next tag. Nothing for you to do with it, since
your own dump already prints the field. What it buys is that the next host to hit this, yours or
anyone's, hands over the placement and the item's own verdict in one engine line, with the gate
line already in the same log.

Where that leaves it

Open, waiting on a recurrence, and nothing outstanding from your side. If 394617 wedges on 6.75.0
the gate line decides it as described. If it never comes back, the negative-axis case is the
answer and 3f31aaed was the fix, and I would rather leave it recorded that way than close it on
a stronger claim than the evidence carries.

On the corrections: they cost less than carrying an argument that needed a pairing which did not
exist. Flagging the capture boundary yourself is what made that cheap.