6.16.1 - An AirPlay route change the bypass no longer sits out
One fix on the nativeRemoteHLS bypass, for hosts that declare text sidecars at load. Drop-in from 6.16.0, internal surface only.
The shape
A wireless AirPlay receiver fetches for itself, so a route change reloads the session and re-resolves the playback URL onto the device's LAN IP (#86, #227). The nativeRemoteHLS bypass was excluded from that reload wholesale, on the premise written into the guard: remote HLS is already receiver-reachable.
That held for exactly as long as the bypass could only play the origin URL. 6.14.0 (#316) gave it a second shape: with text sidecars declared at load, the bypass plays a master the engine serves from its own loopback origin, so 127.0.0.1 is what the receiver was handed.
Engaging AirPlay mid-playback therefore lost the whole session, not just its subtitles. Nothing downstream caught it either: the progress watchdog that recovers a refused manifest requires an HLSVideoEngine session, which this bypass never builds, so there was no watchdog and no media-playlist fallback. What is left is the silent park a receiver does for a manifest it will not take: no -11868, no failed item, the rate flickering to playing for a single tick.
What changed
The discriminator is not the backend, it is where the session's playback URL points:
AirPlayPlaylistDecision.routeChangeNeedsReload(isRemoteHLSBypass:bypassServesLoopbackOrigin:)Both edges reload, matching the loopback path: engaging swaps in the LAN IP, ending puts the session back on the loopback rather than leaving it depending on a LAN address that outlives the receiver.
The reload already worked on this path and was only never started. load() seats the carryover registry at its registration point, which runs before the bypass branch, so the proxy is rebuilt with the same external ids; and loadedURL holds the origin rather than the proxy URL, so the reload re-enters at the origin instead of treating the loopback master as its source.
Who was affected
| Case | Before |
|---|---|
| AirPlay engaged before playback starts | unaffected, the LAN swap is applied when the proxy mounts |
| AirPlay engaged mid-playback, text sidecars declared | receiver parks silently |
| Wired display | unaffected, the device stays the stream origin |
| PiP | unaffected, no route change |
| tvOS | unaffected, external playback never engages there |
iOS only, wireless receivers only, and only with LoadOptions.externalSubtitles carrying a text sidecar on a nativeRemoteHLS VOD source. A bypass playing the origin directly behaves exactly as before.
Verification
3 new tests, 1658 tests in 243 suites green, tvOS and iOS Simulator builds green.
The device half is unverified from here, for the same reason as #316 itself: what a receiver does with the swapped URL is not observable headless. The line that says which shape the bypass is in:
[AirPlay] external playback active (wireless) -> LAN reload (remote-HLS bypass on its #316 subtitle origin)