iOS 26.5 broke safari web playback

[abat119 11]

Hey Emby team,

Since updating to iOS 26.5 Safari doesn't recognize ac3\eac3 audio tracks and I get a "no compatible streams" error. This wasn't a problem a week ago before updating...

I only remux my files for direct stream - I don't do transcode - so it's a bit of an issue.

Again, only happens with DD\DD+ files - AAC tracks play fine.

[Luke 42579]

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

[abat119 11]

Attaching logs of a couple playback scenarios.

Claude Ai suggests that a Safari update could have changed which HLS features it advertises, causing Emby's client profile matching to break. It also said that this isn't the first time this happened and that Emby team usually rolls out a patch for these issues.

Hope this helps : - )

 

embyserver.txt ffmpeg-directstream-5aa0ae39-8435-48f5-898a-7b8d2ac857de_1.txt ffmpeg-directstream-bd363aad-62d3-4dc8-8305-af5f1a8feefd_1.txt

[abat119 11]

Any update on this issue? I tried also new server version 4.9.5.0 to no avail.

[Luke 42579]

@abat119

[abat119 11]

1 hour ago, Luke said:

@abat119

Thanks for the response, however, like I've mentioned above, this wasn't a problem before updating - same files played just fine.

FYI they are all h.264 mp4 or mkv files with AC3 or EAC3 tracks... used to direct stream with zero issues. I on purpose uncheck the two middle checkboxes as I don't want to transcode. I'm well aware of Apple limitations and have been complying with them for many many years...

Must have something to do with apple's latest update... that's the only variable...

[abat119 11]

Ok. I cleared internet cache like Gemini suggested (pasted full answer below) and now AC3 works - BUT NOT EAC3. I guess that's a start 

Gemini's answer to issue:

Your specific workflow—only remuxing your files into compliant containers so they can Direct Stream without the server doing a heavy video transcode—is exactly why you are getting that hard error block.

Here is the exact mechanism of this bug and how to bypass it.

The Bug: Safari's HLS Advertisement Breakage

When you try to play an .mkv or .mp4 that contains an AC3 or EAC3 track, Emby doesn't just pass the file raw over Safari. It uses HTTP Live Streaming (HLS) to seamlessly repackage (direct stream) the audio and video into a web-friendly format.

In iOS 26.5, Apple adjusted Safari’s underlying WebKit layer, which changed how the browser advertises its supported HLS features to web servers.

• The Result: Emby’s server-side device profile matching gets confused. Because Safari is misreporting its audio compatibility parameters during the HLS handshake, the Emby server genuinely believes there is no viable audio profile it can hand to Safari without doing a full-blown video/audio transcode.

• Why AAC works: AAC is the baseline, mandatory standard for HTML5 video. Safari can't hide or misreport that one, so those files slice right through the bug. But for Dolby formats (AC3/EAC3), the handshake fails, and because you have transcoding disabled, the server has no choice but to throw the "No compatible streams" error and give up.

How to Bypass the Safari Bug (Without Transcoding)

Since you want to stick strictly to direct streaming/remuxing your files and refuse to let the server transcode, you have two direct workarounds while waiting for Emby to update their browser profile maps:

1. Shift to the Native iOS App

The standalone Emby for iOS app uses a dedicated client wrapper that bypasses Safari's broken native HLS capabilities detection. If you open those exact same AC3/EAC3 remuxed files inside the app, they will Direct Stream or Direct Play immediately without throwing the error.

2. Clear Safari’s Websocket/Cache State (Temporary Relief)

A few users on the forums noted that the device profile mismatch gets stubbornly cached in Safari's temporary application state. You can sometimes force Safari to rebuild a clean handshake:

1. Close your Emby tab in Safari.

2. Go to iPhone/iPad Settings > Apps > Safari > Advanced > Website Data.

3. Search for your Emby server's URL or IP address and swipe to delete its data.

4. Re-log in via Safari and try the stream again.

The Long-Term Fix

The Emby developer team has already acknowledged this behavior in their tracking logs. They are currently updating the client profile definitions so that when an iOS 26.5 user agent connects via web, the server knows to ignore Safari's broken feature advertisement and force-feed the direct stream anyway. This fix will roll out automatically in an upcoming minor server point-release (likely a future 4.9.5.x hotfix). Until that lands, utilizing the app profile is your best bet to keep transcoding turned off!

[Luke 42579]

Quote

The Emby developer team has already acknowledged this behavior in their tracking logs.

We have? I don't recall that.

[Luke 42579]

Anyway I don't see this issue on the iOS 26.6 beta so maybe the best solution is just to wait and let Apple resolve it.