AirPlay: Use en0 WiFi IP address instead of 127.0.0.1

[DrHurt]

What happened?

When AirPlaying, the airplay protocol is not smart enough to understand not to forward the localhost (127.0.0.1) to the TV.

My suggestion (and what I've done): obtain en0 (wifi) internal IP and use that instead.

eg http://192.168.8.166/media.m3u8

AVPlayer accepts that in the same way as 127.0.0.1

Both IPs are interchangeable, no further work needed.

Caveat:
On devices with Ethernet (or multiple network cards), en0 may not always be the actively used network device so IP maybe wrong.

Steps to reproduce

.

AetherEngine version or commit SHA

.

Host app

Custom / my own integration

Platform

tvOS

OS version

26.5

Device / chip

4K 2022

Playback path

Native AVPlayer

Source media (for playback bugs)

No response

Error codes / log lines

Anything else

No response

[DrHurt]

A quick search shows you should be able to identify active network interface using usesInterfaceType(_:) and then use getIFAddresses to get the corresponding IP.

I haven't tested that but seems to be the way forward.

[DrHurt]

Another unrelated AirPlay caveat: Just mentioning this as I'm sure someone will open an issue in the future about it:

AVPlayer will reject DV/HDR master playlist on SDR receivers device even if "match dynamic range" is enabled. It will not automatically switch.

TV MUST be in HDR or DV mode to accept any non-SDR content via AirPlay.

This should not be an issue as users should leave their Apple TV running in HDR or DV by default. The tvOS UI is mastered in HDR anyway and tvOS does a great job tone mapping SDR to HDR/DV.

My Suggestion: leave it like that, but just document this as a genuine AirPlay limitation. Users are advised to set their Apple TVs to HDR or DV (mine does that by default anyway). The alternative would be to force media playlist routing with AirPlay as a safe universal option (I do recommend this).

[superuser404notfound]

Shipped, and verified end to end on iPhone to Apple TV. Implementation follows your suggestions:

• HLSLocalServer now binds 0.0.0.0 so the receiver can reach it over the LAN.
• While the AVPlayer reports external playback, the engine reloads the loopback over the device's active LAN IP instead of 127.0.0.1 (en* scan: en0/WiFi preferred, wired en* fallback), and forces the media playlist so a DV/HDR master is never handed to an SDR receiver (your second caveat). It reverts to the 127.0.0.1 loopback when AirPlay ends, since loopback is more reliable for local playback.
• Because the receiver plays the engine-processed HLS, Dolby Vision / Atmos / subtitles are carried through rather than lost.

Thanks for the precise pointers, including the active-interface and DV/HDR-master caveats. The NWPathMonitor active-interface approach is noted for the both-WiFi-and-Ethernet edge; for now the synchronous en* scan keeps it off the reload path.

[DrHurt]

I don't use AirPlay much but I'm very curious to try this and see how an "external" avplayer interacts with the engine on the iPhone with things like seeking.

A minor correction to your note, DV/HDR will not be carried through as media playlist routing will make AVPlayer tone map to SDR (even if TV is in HDR or DV mode)

The real choices are:

• media playlist: airplay forces SDR for everything regardless of media, receiver capabilities or current TV mode. Safest.
• master playlist: HDR & DV will work when receivers are in HDR mode. SDR-locked devices will reject it. Best for HDR TV users.

It is a limitation we'll have to deal with for now as we cannot probe receiver capabilities via AirPlay. I'll you decide which path to take.

In both cases SDR & Atmos work.

Very excited to try Sodalite on my iPhone (assuming its the same TestFlight)!
And hopefully you'll consider allowing local files for easier testing :P (but I understand if you want it to stay strictly Jellyfin)

[DrHurt]

I see you've added mov_text subs to PIP. Might be worth adding it here as well so text subs get forwarded via AirPlay.