AirPlay LAN-swap reload destroys host subtitle session state (mid-session external tracks, active selection, native-rendition pick)

[dlev02]

Summary

When wireless AirPlay engages or ends, the engine reloads itself to move the
loopback playlist onto the device's LAN IP and back
(handleExternalPlaybackChange → reloadAtCurrentPosition(), the #86 path).
That reload is a full load(), and load()'s stopInternal wipes three
pieces of session state the host set up — none of which the engine restores:

1. Mid-session external subtitle registrations (addExternalSubtitleTrack,
   Select external subtitles to make them appear in engine.$subtitleTracks. #88). load() clears externalSubtitleRegistry / subtitleTracks /
   nextExternalSubtitleOrdinal and re-registers only
   LoadOptions.externalSubtitles. Every track the host added after load is
   permanently gone — the host's menu still lists them, but selecting one
   targets a synthetic id that no longer exists.
2. The active audio/subtitle selection. The reload re-runs
   preferred-language auto-selection, which can silently override the user's
   explicit picks (including subtitles they turned off).
3. nativeSubtitleReapplyOrdinal. This is the sharpest edge: the host
   reacts to AirPlay starting by calling setNativeSubtitleRendering(true)
   (per the documented contract), which sets the reapply ordinal — and the
   engine's own AirPlay reload, triggered by the same KVO flip, then nils it
   in stopInternal. Net effect: the receiver renders no subtitles at
   all, even for plain embedded text tracks, unless the host knows to
   re-assert after an engine-initiated reload it never asked for.

Notably the #65/#93 stall-recovery path already handles this correctly for
in-place item swaps — after host.load(url:startPosition:inPlaceSwap: true)
it replays nativeSubtitleReapplyOrdinal onto the fresh item. The AirPlay
reload deserves the same courtesy, extended to all three items above.

Surfaced by a Prism beta report: streaming iOS → tvOS via AirPlay, "the
subtitle selection dropdown is tripping out" (the wipe/republish churn
re-rendering an open menu) "and no data seems to be sent to the AirPlay
server side" (items 2 and 3, plus overlay-only mid-session tracks).

Repro

1. Host app: load() a stream with prepareNativeSubtitles = true, an
   embedded text subtitle track active, and one track added mid-session via
   addExternalSubtitleTrack.
2. Start playback, then AirPlay the video to an Apple TV (wireless — the
   wired-HDMI branch doesn't reload and is unaffected).
3. Call setNativeSubtitleRendering(true) on the external-playback flip (as
   documented for PiP/AirPlay).
4. Observe: [AirPlay] external playback active (wireless) -> LAN media reload, then:
   • subtitleTracks republishes without the mid-session external track;
   • activeSubtitleTrackIndex is nil (or the preferred-language auto-pick,
     not the user's track);
   • no legible rendition is selected on the receiver — the Sodalite#38
     force-deselect loop runs because nativeSubtitleReapplyOrdinal is nil
     again.

Asks

1. Carry session state across engine-initiated reloads (AirPlay LAN swap
   today; anything else that calls reloadAtCurrentPosition() internally):
   re-register mid-session external tracks (preserving their synthetic ids if
   possible), re-select the previously active audio/subtitle tracks instead
   of re-running auto-selection, and replay nativeSubtitleReapplyOrdinal
   the way the Presented frame drifts ~6 s ahead of currentTime/sourceTime after a rapid bidirectional seek burst (loopback-HLS native path) — frameAhead/producerShift/hostShift all report 0 #65 recovery already does.
2. (Feature, separable) Native-rendition eligibility for
   addExternalSubtitleTrack: append a WebVTT rendition + cue store to the
   live loopback master/media playlists so mid-session tracks can survive
   PiP/AirPlay without the host performing a full re-declared reload. Today
   the host's only route is a position-preserving load() with the track in
   LoadOptions.externalSubtitles, which costs a visible rebuffer — during
   AirPlay, exactly when the user is most likely to be adding subtitles.

Host-side workaround (shipping in Prism meanwhile)

On every isExternalPlaybackActive flip: freeze the host's track/selection
mirrors against the reload's transient wipe publishes, wait for the reload to
settle, re-addExternalSubtitleTrack the dropped tracks, re-apply the
session's picks, promote an overlay-only active pick via a re-declared reload,
and re-call setNativeSubtitleRendering. It works, but it's ~150 lines of
host code compensating for state the engine could preserve in one place.

[superuser404notfound]

Fixed in 5.17.1 (e0b6784). Excellent report, the three-item breakdown mapped exactly onto the code, and you are right that the #65 recovery already did this correctly for in-place swaps while the AirPlay reload restored nothing.

Ask 1 (session carryover) is implemented at the reloadAtCurrentPosition level, so it covers the AirPlay LAN swap in both directions plus the background-return reopen:

1. Mid-session external tracks survive with their synthetic ids. The reload captures the live registry and the fresh load() seeds it back id-exactly (removal gaps preserved, so later adds cannot collide with the session's id history). No more wipe/republish churn under an open menu.
2. The previous audio/subtitle selection is re-selected instead of re-derived. The audio pick rides load()'s existing audioSourceStreamIndex override (same mechanism the custom-source reload branch already used); the subtitle authority flag carries over, so the load-end preferred-language pass no longer runs against an explicit pick, including subtitles explicitly OFF.
3. nativeSubtitleReapplyOrdinal is replayed the way the Presented frame drifts ~6 s ahead of currentTime/sourceTime after a rapid bidirectional seek burst (loopback-HLS native path) — frameAhead/producerShift/hostShift all report 0 #65 recovery does, recomputed against the rebuilt rendition table. On top of that there is a latch for the race you called out: the AirPlay flip triggers the engine reload and your setNativeSubtitleRendering(true) from the same KVO change, and if your call lands mid-reload (active track transiently nil) it used to be misread as a deselect. It is now deferred and applied once the reload has re-established the selection, so the receiver gets its legible rendition regardless of ordering.

The audio-switch reload got the same ordinal replay (switching audio during PiP/AirPlay also stranded the receiver without subtitles), and an active external track now re-arms through its id there instead of collapsing to a one-shot sidecar URL.

Ask 2 (native-rendition eligibility for mid-session tracks) turns out to fall out of the carryover for the case that matters: the seed happens before the native rendition table is built, so mid-session tracks join the WebVTT renditions of the reloaded item. Since AirPlay entry IS an engine reload, your mid-session tracks become receiver-renderable at exactly that moment, at zero extra cost. The standalone form (promoting a track mid-item without any reload) is not implementable on AVPlayer: the master playlist is fetched once per item, so a rendition appended later never surfaces; an item swap is unavoidable, and the position-preserving re-declared load() remains the route for that. If the rebuffer cost of that path bites in practice I would treat an engine-side "promote" convenience (engine-internal reload with the carryover applied) as a separate feature request.

Your ~150-line host workaround should be fully removable on 5.17.1: no more transient wipe publishes to freeze against, dropped tracks to re-add, picks to re-apply, or rendering calls to re-assert. In the log you should see #170 re-applying native subtitle ordinal=N after session-preserving reload following the [AirPlay] external playback active (wireless) -> LAN media reload line.

Covered by 19 new tests (Issue170SessionCarryoverTests); full suite and multi-platform CI green. Please retest with your Prism beta setup (iOS to tvOS, embedded text track active plus a mid-session external) and report back; I will leave this open until you confirm.

[dlev02]

Perfect, I'll get this shipped in the next beta release and report back what I find out (it may take a bit). As always, thanks!