Live: item reload on a starving origin tears down the audio output and drops EAC3+JOC Atmos passthrough on the receiver

[Simpendaal]

What happened?

On a live 4K50 HEVC / EAC3+JOC (Atmos) channel, the Atmos stream-copy path itself is set up correctly (stream-copy as ec-3 [JOC=Atmos], no decode). The bug is the recovery path when the origin starves the reader: the producer seals the window with ENDLIST, AVPlayer fires didPlayToEndTime, the nudge fails to revive, and the engine reloads the item via replaceCurrentItemWithPlayerItem:. Each item swap re-initialises the AVPlayer audio output, and for an EAC3+JOC passthrough track that forces the AVR/soundbar to renegotiate and lose the Atmos lock for ~1-2s every time.

In one ~90s session this happened across 3 successive AVPlayer items (2 mid-session reloads). The user hears it as "Atmos keeps dropping on Live TV". Nothing on the host side restarts playback here — the host's own live-recovery layer never fired; every reload originates inside AetherEngine.

Steps to reproduce

Load a live EAC3+JOC channel (native path) whose origin delivers slower than real time — here a single h2 connection that trickles bytes, producing chronic multi-second AVIOReader slow read events with reconnects=0 connect=0ms (healthy connection, just slow).
Let it run. The producer keeps hitting "source stopped delivering … under the 6.0s floor" and serves ENDLIST.
AVPlayer reaches didPlayToEndTime; the nudge fails; the engine logs reloading item … (same URL, same host) and swaps in a fresh AVPlayerItem.
On an HDMI AVR/soundbar doing EAC3+JOC passthrough, each swap is an audible drop-and-relock of Atmos. Repeats for as long as the origin stays slow (3 items in ~90s here).

AetherEngine version or commit SHA

6.68.0

Host app

Custom / my own integration

Platform

tvOS

OS version

tvOS 26.6

Device / chip

Apple TV 4K

Playback path

Native AVPlayer

Source media (for playback bugs)

Live HLS (loopback) from an MPEG-TS origin. Video HEVC Main 10, hvc1.2.4.L153, 3840x2160 @ 50fps, HDR10 (PQ), DV=none. Audio eac3 with JOC, stream-copied as ec-3. Origin: single h2 (multiplexed) connection.

Error codes / log lines

21:13:18.949 [HLSVideoEngine] audio: codec=eac3 → stream-copy as `ec-3` [JOC=Atmos]
21:13:18.950 [HLSVideoEngine] EAC3+JOC Atmos: stream-copy engaged; DD+/JOC bitstream preserved
21:13:20.460 [NativeAVPlayerHost] #1 timeControlStatus=playing t+1.50s

# origin starves the reader for essentially the whole session (19 events, mean ~4.6s, max 7.96s)
21:13:22.042 [AVIOReader] slow read: 2910ms ... stallWaits=5 reconnects=0 backoff=0ms connect=0ms origin=1inflight
21:13:34.099 [AVIOReader] slow read: 7960ms ...
21:14:46.657 [AVIOReader] slow read: 5961ms ...
21:14:48.790 [AVIOReader] origin transport: h2 at https://021.galaxypulse.link (multiplexed)

# producer runs out of runway and seals with ENDLIST
21:14:12.247 [VideoSegmentProvider] #446 the source stopped delivering, consumer at 35 of 39
             (5.0s runway left, under the 6.0s floor) ... serving the rest of the window as a finished asset (ENDLIST)

# AVPlayer reaches end -> nudge fails -> item reload (the audible event)
21:14:23.039 [NativeAVPlayerHost] #1 didPlayToEndTime
21:14:23.040 [AetherEngine] #65 nudge did not revive the consumer; reloading item at 64517.69s (same URL, same host)
21:14:23.041 [NativeAVPlayerHost] #2 load url=http://127.0.0.1:49325/.../media.m3u8
21:14:23.043 AVPlayer replaceCurrentItemWithPlayerItem: I/BAT.01 -> I/VGC.01
21:14:23.051 AVPlayerItem dealloc I/BAT.01

# and again ~19s later
21:14:30.562 [VideoSegmentProvider] #446 ENDLIST, consumer at 45 of 49
21:14:42.020 [NativeAVPlayerHost] #2 didPlayToEndTime
21:14:42.020 [AetherEngine] #65 nudge did not revive the consumer; reloading item at 64535.89s
21:14:42.020 [NativeAVPlayerHost] #3 load ...  (I/VGC.01 -> I/UZR.01)

# session ended by the user zapping away
21:14:48.795 [HLSSegmentProducer] pump finished: reason=stopRequested elapsed=89845ms

Anything else

The core question: when the origin merely slows down (not a genuine EOS), is there a recovery path that keeps the same AVPlayerItem alive and rebuffers / bridges the gap, instead of ENDLIST → didPlayToEndTime → replaceCurrentItemWithPlayerItem:? The item swap is what tears down and re-establishes the audio output, and for bitstream passthrough (EAC3+JOC, and likely AC-3/DD+ 5.1) every teardown is an audible drop-and-relock on the receiver — unlike a decoded/PCM path where a silent rebuffer would be invisible.

Two directions that would help, either or both:

Prefer holding the current item and rebuffering over sealing+reloading when the stall is "out of content but the connection is healthy". This looks related to the #446 ENDLIST/holdback tuning — here the 6.0s runway floor vs 9.0s silence window trips the seal readily on a chronically slow origin.
If a reload is unavoidable, is there any way to preserve the audio output / passthrough across the swap so the AVR does not renegotiate?
Secondary observation (probably not the cause): the route settled at output=2 preferred=2 max=32 ports=[Apple TV[HDMIOutput, ch=2]] and the engine's own ec-3 6-channel track playing into a 2-channel route warning fired. Since the complaint is that Atmos drops (i.e. it works between reloads), I read the 2-channel route as the normal MAT carrier rather than the fault, but flagging it in case it is relevant.

Full unified log available on request.

[superuser404notfound]

Reproduced, and the cause is on our side of the line you drew. Your reading was right: nothing here is a genuine EOS, and the item swap is the whole of the damage.

What was wrong

AE#446 round 7 lifted the irreversible window close off the cheap 1.5 x TARGETDURATION threshold and gave it a 3 x TD deadline. But the wait has a second bound, the content still listed in front of the consumer, and that one was written as a constant: 2 x TD of runway, below which the window closed whatever the clock said.

That constant is unreachable in the direction that matters. A viewer at the live edge holds the holdback, which is 3 x TD, and is not asked about any of this until the source reads as late at 1.5 x TD. Half of it is spent by then, so the viewer stands at 1.5 x TD and already under a 2 x TD floor at the very first moment the question can be asked. The floor therefore decided every ordinary live session, the new deadline decided none of them, and the effective close threshold stayed the 1.5 x TD that round was written to remove. It looked correct at the time because that round's reporter happened to be sitting on 7 x TD of runway.

Your log is that in numbers: TARGETDURATION 3, so the deadline is 9.0 s and the floor 6.0 s, and you close at 5.0s of runway left, which is one target duration of drain away from where an edge viewer starts.

The premise behind the number was wrong too. It was sized on "several polls per target duration". Measured over three harness runs with the blocking-reload advert withdrawn, which is the state every close candidate is in, the client polls once per 0.81 x TD (31, 35 and 38 polls at mean gaps of 4.83, 4.85 and 4.86 s against TARGETDURATION 6). Two target durations is two and a half polls.

What changed

The runway is now compared against the clock rather than against a number: it ends the wait only when it will not carry it to the deadline. Both are seconds, and the deadline is already an argued bound.

Harness, same command line in both arms, arms alternated, three repeats each (aetherctl live --realtime --preroll 30 --freeze-after 60 --unfreeze-after 12 --rewind-before-freeze 8):

	ENDLIST	item swaps	playhead advance	largest step
before	3 of 3	3 of 3	89.20 / 89.30 / 89.40 s	1.10 s each
after	0 of 3	0 of 3	89.50 s all three	1.10 s each

Identical position, one fewer teardown of your audio output. The after arm is 0.1 to 0.3 s AHEAD, not behind. A 14 s gap on a shallower runway is absorbed as well.

To your first question directly: yes, the same item is now held and rebuffered where the gap is one the clock can absorb. What has not changed, deliberately, is a genuine outage. On a 30 s freeze the window still closes and the swap still happens, and it has to: with the close suppressed entirely, that leg comes back POSITION LOST, four segments skipped, item death plus a rejoin at the live edge. So the bound was mis-sized, not unnecessary.

The window staying open is now a line rather than an absence, which matters because a fix whose success is the non-occurrence of an event is otherwise indistinguishable from not having hit the case yet:

#446 the source has missed its cadence (quiet 10.07s, TARGETDURATION 6s); the consumer is at 17 of 22
     with 16.0s of runway, and the window stays live until 18.0s of silence, or sooner if that runway
     would not carry the wait that far (7.9s of it left)
#446 the source is cutting again and the window was never closed (silence stayed under 18.0s);
     no ENDLIST, no item swap, nothing for the viewer to see

Your second question, preserving the audio output across a swap: there is no lever. The swap is already the in-place path (AE#93 keeps the player, the transport intent and the clocks alive; the default teardown drops the item to nil first, which is worse). What renegotiates is the audio output AVPlayer builds per item, and there is no API to hand a fresh item the previous item's output. So the only real answer to this report is to not swap, which is what the above does.

Your secondary observation was a real defect, and thank you for flagging it rather than filtering it out. The ec-3 6-channel track playing into a 2-channel route warning fires on every EAC3+JOC session by construction: a 6-channel ec-3 tunnelling through a 2-channel MAT carrier is exactly what correct Atmos passthrough looks like. The exclusion existed only in the docstring and in the warning's own closing sentence, so the line warned and then told the reader it did not apply, and you had to reason it away yourself while chasing something else. The route cannot answer the question (a MAT carrier and a stereo LPCM route both report two channels); the session knows it engaged JOC stream-copy and now carries that fact to the host, so the warning stays quiet on Atmos.

Both are on main and not released yet. I will post here when there is a tag to test against. What I would like from a retest, on a channel that starves the same way, is the missed its cadence line followed by the window was never closed with no ENDLIST between them, next to a flat count of Atmos relocks.

[superuser404notfound]

Released in 6.79.0 (b4eac985), and both consumers are bumped, so a TestFlight build from either carries it.

The retest that would settle it is the positive form on a channel that starves the same way: #446 the source has missed its cadence followed by the window was never closed, with no ENDLIST between them, next to a flat count of Atmos relocks. A genuine outage still closes and still costs the swap, by design, so a relock during a real dropout is not a regression.