The engine cannot tell that the media server went away underneath it, and never recovers from it

[superuser404notfound]

The engine cannot tell that the media server went away underneath it, and after that it never recovers on its own.

Field report, Apple TV 4K 3rd gen (AppleTV14,1), tvOS 27.0 (24J361), engine 7.10.1, an H.264 title with E-AC-3 5.1 passthrough to an Atmos receiver. Playback was running when the television was switched off, and the box came back about an hour later. The session then failed, and afterwards nothing on the whole box would play until it was rebooted.

The whole-box part is probably not ours, and the qualifier matters. The same shape is widely reported across Netflix, HBO Max, Paramount+, Prime and others on this hardware generation, Apple Support has called it a known issue, and the reported workarounds (a reboot, reseating HDMI, or setting Sleep After to Never) point at a wake-from-sleep HDMI handshake rather than at any one app. Those reports are on tvOS 26 and 26.0.1; this one is on 27.0, so either it survived the release or this is a different fault wearing the same shape. Worth knowing either way: several of those reports describe it happening after an idle hour with nothing playing at all, which no client can be blamed for. What is ours is everything in this issue: the engine is blind to it, it keeps using objects that are already dead, and one of its own mechanisms then wedges permanently.

What the log shows

09:35:23.179  [AVKitLayer] isReadyForDisplay=true t+4577.15s after attach
09:35:23.193  #2 item.videoTrack codec='avc1' enabled=true dim=1920x1080 (readyToPlay)
09:35:23.847  #2 failedToPlayToEndTime CoreMediaErrorDomain/1852797029
09:35:26.945  #93 item death (failedToPlayToEndTime) at 271.14s; reloading (attempt 1)
09:35:27.160  #3 item.videoTrack codec='?' enabled=false (readyToPlay)
09:35:27.162  #3 failedToPlayToEndTime CoreMediaErrorDomain/1852797029
09:35:32.756  #4 item.videoTrack codec='?' enabled=false (readyToPlay)

The layer had been attached for 4577 s, so the session crossed the suspension whole. 1852797029 is the FourCC 'nope'. From the second item onward AVFoundation reports readyToPlay with no usable tracks at all, which is what a media server that can no longer serve the process looks like from the client side.

Four defects behind that

1. No mediaServicesWereReset / mediaServicesWereLost observer exists. Zero occurrences in the package. Apple's contract is that every audio and video object a process holds is invalid after a reset and has to be rebuilt. The engine keeps its AVPlayer deliberately across a background teardown (keepNativeHost: true), so after a reset it reuses exactly the object the platform has already invalidated, and every recovery rung reloads onto it.

2. ItemDiagnosticReadPool wedges for the lifetime of the process. Diagnostics/AVPlayerItemDiagnostics.swift:128-145 dispatches synchronous XPC reads to mediaserverd on a bare thread. If one never returns, its continuation never resumes, runningCount never decrements, and the shared pool admits no further reads ever again, pinning up to two AVPlayerItems. cancel() cannot undo it and says so at :205. The #93 recovery ladder queues one more such read per rung, against the very server that is not answering.

3. RemoteHLSSubtitleProxy is never torn down on the background path. It owns its own HLSLocalServer (Native/RemoteHLSSubtitleProxy.swift:25, started at :84 and :140), and tearDown() is called only from load and from the public stop (AetherEngine.swift:3669, :5718). stopInternal does not touch it, and the tvOS background teardown goes through stopInternal. So a listen socket bound to 0.0.0.0, its accept thread and up to 32 connection threads cross the suspension, and the return builds a second one on a fresh port rather than reusing it. The engine names this failure mode itself one line above the stop() site at :5716.

4. An HDMI route that disappears is invisible. No AVAudioSession.routeChangeNotification observer exists either. On the tvOS background path the shared audio session is deliberately never deactivated (finalTeardown: false, keepNativeHost: true), so an E-AC-3 passthrough render ring is held against a sink that has gone away, for as long as the box sleeps. The engine's own comment at AetherEngine.swift:6487 describes exactly that as what strands a passthrough ring, and :6526 records that reactivating such a route costs a ~0.5 s XPC round trip.

Scope note on the trigger

The teardown that would have released any of this has one trigger on tvOS, didEnterBackground (AetherEngine.swift:6823). The host documents that the tvOS screensaver and the app switcher reach only willResignActive, and a playing session holds the idle timer off. Whether the field session backgrounded at all is not in the capture, because the diagnostic log is a 300 line ring and the hour rolled out of it. That question is worth settling separately; it does not change any of the four defects above, each of which is wrong on its own terms.

[superuser404notfound]

A constraint on defect 3 that changes what the fix has to be, found while attempting it.

The proxy is built in exactly one place, prepareRemoteHLSStandIn (AetherEngine+Loading.swift:574), called from exactly one place, loadRemoteHLS (:500). The return from a background teardown does not go through either: reloadAtCurrentPosition reaches reloadWithAudioOverride (AetherEngine+Loading.swift:2046), which reloads through loadSoftware or loadNative and never through loadRemoteHLS.

So simply tearing the proxy down in stopInternal, or on the background path, would not fix a leak, it would break the resume: the session's playback URL is the proxy's, and the return would reload a URL nothing serves any more. The same reasoning rules out the audio-track switch, which is the other stopInternal caller that must not lose it.

The fix therefore has two halves, and the second is the load-bearing one: release the standing socket when the session is put away, AND route the return back through the remote-HLS path so the stand-in exists again. Filed here rather than done hastily, because a wrong version of it removes subtitles from every server-transcoded source on the way back from a background trip.

Worth separating for triage: this defect is not part of the field report above. That session plays a direct file ([Demuxer] Opened: 27 streams, [AVIOReader] File size: 205056265 bytes) and never builds a proxy at all. It is a latent leak that the same suspension would expose on a server-transcoded source carrying external subtitles.

[superuser404notfound]

Defects 1 and 2 are released in 7.12.0, and both consumers are pinned to it.

• The diagnostic lane has a deadline, so a media server that stops answering no longer wedges the pool for the lifetime of the process (867dd144).
• mediaServicesWereReset and mediaServicesWereLost are observed, and a reset outranks every reason to keep the native host (021c384a).
• The tvOS background teardown and the loopback server's stop now say so in the log, which is what the next field capture needs more than either fix.

Defects 3 and 4 stay open here. Defect 3 is blocked on the constraint in the comment above; defect 4 wants a device round before anything changes at that interface.

On the capture side, the host half shipped in Sodalite (PR #161): the diagnostic log's file sink is no longer debug-only, it is a switch under the log itself. The log is a 300 line ring in memory, so the field capture in the body opens after the wake with the hour already rolled out of it, and every further report of this shape would do the same.

What the next reproduction has to answer is one line, and either value settles where the work goes next:

• [Lifecycle] #149 active after a background trip of <n>s means the teardown ran, and the fault is downstream of it.
• [Lifecycle] #149 active, never backgrounded (screensaver or app switcher) means the engine released nothing at all, for the whole suspension, audio session and passthrough render ring included. That makes defect 4 the mechanism rather than a suspicion.

Both of the new #597 lines answer the same question from the engine's side.

[superuser404notfound]

Control round: the same geometry on a box with no soundbar does not reproduce

The report came from an Apple TV 4K (3rd gen) with a Sonos behind it. The same repro was run today on a second Apple TV 4K (3rd gen) that is connected to a television and nothing else, on a build carrying 7.12.0, with the persistent log sink enabled so the whole hour survives.

It does not reproduce. Asleep for 5346.8 s (89 minutes), and the session comes back in full:

11:11:05.234  [Lifecycle] #149 resignActive: state=playing backend=native
11:11:06.198  [Lifecycle] #149 background: state=paused backend=native
11:11:06.856  [AetherEngine] #597 background teardown: releasing the video pipeline (backend=native, state=paused)
11:11:06.866  [AetherEngine] #597 background teardown done in 10ms; the audio session and the native host shell stay
12:40:12.985  [Lifecycle] #149 active after a background trip of 5346.8s: state=paused backend=none
12:40:13.462  [AetherEngine] #361 startup 8/8 presenting (gen 2)
12:40:15.563  [NativeAVPlayerHost] #2 timeControlStatus=playing reason=- t+2.41s

First frame 0.48 s after the foreground line, playing 2.58 s after it.

This is not evidence that the two shipped fixes worked

Worth stating plainly, because the run invites the opposite reading. Across 651 lines there is no mediaServicesWereReset, no mediaServicesWereLost, and no abandoned diagnostic read. Defects 1 and 2 are recovery, not prevention: the reset observer does something only after the media server has reset, and the read deadline only after mediaserverd has stopped answering. Neither condition occurred, so neither fix can be credited. The box simply never entered the broken state.

What the run does settle

The codec is not the variable. The control played the same source: stream[1] type=audio codec=eac3, prepared as avc1.640028,ec-3, so the same E-AC-3 passthrough attempt, the same sleep duration, the same engine. No wedge.

The trigger is now confirmed rather than assumed. Switching the Apple TV off does reach didEnterBackground, as the sequence above shows, so the background teardown runs and completes in 10 ms. That question was open: screensaver and app switcher reach only willResignActive, and the first capture had rolled the hour out of the in-memory ring. Defect 4 was a suspicion resting on that gap; the teardown demonstrably runs, and whatever fails in the reporting setup fails after it.

What remains different between the two boxes is the sink. The control reports ports=[Schlafzimmer[HDMIOutput, ch=2]], a television directly, against a Sonos over HDMI in the other room. That is the same surface as the named HDMI-CEC audio handshake regression, and it matches the workarounds in the field reports all pointing at HDMI negotiation rather than at any app.

Defects 3 and 4 stay open on their own merits.

[superuser404notfound]

Three corrections and additions to the control round above.

The documented countermeasure is ruled out. "Durchgehende HDMI-Verbindung" (continuous HDMI connection) was already enabled on the reporting box, and was enabled when the wedge occurred. So the named HDMI-CEC audio handshake regression cannot be dismissed as unconfigured, and its own workaround did not prevent this.

The OS axis is clean. Both boxes are AppleTV14,1 on tvOS 27.0 build 24J361, so the control differs from the failing box only in the audio chain and the app build, not in the system.

Correcting "the same E-AC-3 passthrough attempt" in the comment above. That is accurate for the engine, which stream-copies ec-3 in both cases, and it is not established for the sink. dumpAudioRoute reports output=6 on the control, but outputNumberOfChannels is the LPCM limit and E-AC-3 bypasses it through the bitstream tunnel, so the field cannot separate "bitstreamed to the television" from "decoded on the Apple TV to 5.1 LPCM". The control therefore proves the codec and the engine path are not sufficient to trigger this; it does not prove the sink negotiated the same thing.

One of the two shipped fixes does have a credible path to the system-wide symptom, contrary to the framing above. AVPlayerItemDiagnostics hands the AVPlayerItem to a bare thread (AVFoundationOffMain.read(item, ...)) and holds it itself. Before 867dd144, a wedged lane pinned that item for the lifetime of the process, and an AVPlayerItem holds decode resources in mediaserverd, which is a system daemon rather than a per-app one. That is the only one of the four defects that could plausibly reach other apps.

Two limits on that, so it is not overread: the pool can only wedge once mediaserverd has already stopped answering, so it would deepen and sustain the hole rather than open it, and the chain from a pinned item to another app's failed playback is reasoned, not measured. It does fit the reported shape of a state that persists until reboot.

[superuser404notfound]

Released in 7.13.0 (18a18aac). Both consumers are pinned to it.