[HLSLiveIngestReader / nativeRemoteHLS] Live HLS playback fails on tokenized/header-enforcing IPTV streams over redirects

[parthp1808]

What happened?

Summary

When attempting live playback of tokenized IPTV HLS streams (.m3u8) requiring custom httpHeaders (User-Agent / STB profile headers) across cross-origin HTTP 302 redirects:

1. nativeRemoteHLS: true fails because Apple's AVPlayer / AVURLAsset drops custom HTTP request headers when following cross-origin redirects to edge CDN nodes, resulting in origin HTTP 401 Unauthorized / 403 Forbidden errors (ProviderError / AVFoundationErrorDomain).
2. nativeRemoteHLS: false (raw live path) fails closed with hlsPlaylistOnRawLivePath ([AVIOReader] HLS playlist body on the raw live path (AE#140); failing closed. Use LoadOptions.nativeRemoteHLS or HLSLiveIngestReader for m3u8 sources).
3. HLSLiveIngestReader(playlistURL:httpHeaders:) terminates with HLSIngestError when encountering variant structures, non-TS media segments, or redirect token parameters.

Expected Behavior

Live .m3u8 streams requiring httpHeaders should be playable via HLSLiveIngestReader or nativeRemoteHLS without losing custom headers across redirects or failing closed on the raw path.

Actual Behavior

• nativeRemoteHLS: true -> AVPlayer drops headers on 302 redirect -> Origin returns HTTP 401/403.
• nativeRemoteHLS: false -> hlsPlaylistOnRawLivePath error (AetherEngine#140).
• HLSLiveIngestReader -> Terminates with HLSIngestError.

Logs

[portal.raw-response] ... data={"js":{"id":"1432","cmd":"http:\/\/glen.packetcdn.me:9324\/86e4228d...\/index.m3u8?token=2be67cd6..."

[com.orvix.tv:playbackSession] [INFO] Attempting playback on candidate engine [aether]
[com.orvix.tv:aether] [INFO] Preparing stream; isHLS: true, live: true, nativeRemoteHLS: false, liveJoinProfile: fastZap, header count: 1
[AVIOReader] pump conn start gen=1 offset=0 open-ended
[AVIOReader] pump gen=1 first data after 11ms
[AVIOReader] HLS playlist body on the raw live path (AE#140); failing closed. Use LoadOptions.nativeRemoteHLS or HLSLiveIngestReader for m3u8 sources.
[AetherEngine] probe failed (HLS playlist supplied to the raw live path); proceeding without criteria
[com.orvix.tv:aether] [ERROR] Aether playback phase error: HLS playlist supplied to the raw live path. Use LoadOptions.nativeRemoteHLS or HLSLiveIngestReader for m3u8 sources.


### Steps to reproduce

1. Obtain an IPTV live channel URL returning an `.m3u8` playlist that issues a 302 redirect to a CDN node requiring custom HTTP headers (e.g., User-Agent or Authorization).
2. Configure `LoadOptions`:
   let options = LoadOptions(
       httpHeaders: ["User-Agent": "Mozilla/5.0 (QtEmbedded; ...)"],
       isLive: true,
       nativeRemoteHLS: true
   )
3. Call `try await engine.load(url: streamURL, options: options)`.
4. Observe that AVPlayer drops the custom HTTP headers on the cross-origin redirect, causing the stream server to return HTTP 401/403 (`authenticationFailed`).
5. Alternatively, call `engine.load(url: streamURL, options: LoadOptions(isLive: true, nativeRemoteHLS: false))` and observe `hlsPlaylistOnRawLivePath` (AetherEngine#140).


### AetherEngine version or commit SHA

6.21.0

### Host app

Custom / my own integration

### Platform

iOS

### OS version

ios 26.5

### Device / chip

iPhone 17 Pro (Xcode simulator)

### Playback path

Native AVPlayer

### Source media (for playback bugs)

_No response_

### Error codes / log lines

```text

Anything else

No response

[superuser404notfound]

Thanks for the detailed report. Two of the three points are fixed in 6.24.0, released just now. The third needs one log line from your side, because the error class it names has seven cases and they do not share a fix.

On the stated cause, the header loss over the redirect: that is not what happens, at least not here. Before changing anything I built a fixture origin that answers 403 to every request missing an exact header and logs the verdict per request, then pointed the nativeRemoteHLS bypass at both shapes of your case: a 302 that changes host and port, and a master whose variants name a second origin absolutely. In both, every playlist, variant and segment request arrived with the header intact and the session played through, on User-Agent specifically and on a custom header. So LoadOptions.httpHeaders do ride across a cross-origin redirect into the AVURLAsset (that is #119, and it holds).

Which leaves the origin's own reasons for the 401/403 worth checking on your side: your log line reads header count: 1, and Stalker-style portals commonly want a Referer or the portal Cookie next to the STB User-Agent. A curl with exactly the header set you pass, following the redirect, is the quickest way to tell that apart from anything in the player.

What was genuinely missing is the routing, and that is what 6.24.0 changes. The engine holds HLSLiveIngestReader, which is the only live path that puts your headers on the playlist, on every segment and on every AES key, and both ways of reaching it required you to wire it by hand.

1. load(url: <m3u8>, options: LoadOptions(isLive: true)) without nativeRemoteHLS no longer fails closed with hlsPlaylistOnRawLivePath. The detection stays (an #EXTM3U body where a container's first byte belongs, which is what stopped the endless reconnect loop in load(url:) with isLive: true on an HLS playlist URL fails open: silent reconnect loop with no terminal state (262 cycles over a 5.75-min observation), playlist body consumed as raw bytes, no error, no give-up #140), but the engine now builds that ingest reader itself, with your headers. This is the call I would suggest for your streams. The typed error still exists for a custom IOReader carrying the same misroute, since that source has no playlist URL for the engine to route.

2. A live nativeRemoteHLS session the origin refuses outright is handed to the same ingest instead of failing the load. HTTP 401 reaches the item as NSURLError -1013 and 403 as -1102, identically whether the refused request was the master or the first segment. The point is that the ingest fetcher is a different client at that origin: your headers on every request, at most four concurrent fetches, and no AppleCoreMedia user agent, so a UA filter or a full per-token connection cap that turned AVPlayer away can still serve it. Gated by LoadOptions.nativeRemoteHLSIngestFallback, fires once per session, and is not remembered for the next load, because a token expires and a cap frees up.

For your third point I need the terminal case. HLSIngestError has seven of them and the log carries the verdict verbatim:

[HLSIngest] terminal: <case>

Variant structures are handled (the reader resolves the master to the highest-BANDWIDTH variant, resolves relative URIs against the post-redirect URL, and inherits headers into demuxed-audio and subtitle renditions), and token query parameters are carried untouched. unsupportedSegmentFormat is a real Phase-1 limit: an EXT-X-MAP or a first segment that is not MPEG-TS goes terminal by design, since fMP4 ingest is not implemented. If that is what you hit, the head of the media playlist your channel serves (with the token redacted) would tell us whether the gap is fMP4 carriage or something else entirely.

Alongside the fix, aetherctl can now drive a header-enforcing origin, which is what made the measurement above possible: play --header "Name: Value" and hlsfixture --require-header / --deny-status / --deny-user-agent / --redirect-entry / --media-origin. If you can reproduce against a public URL, that harness will reproduce it here too.