I've done a bunch of testing. I reset Orion to factory defaults (wiped the entire Defaults folder from ~/Library/Application Support/Orion/) and tested systematically on macOS 26.4. No settings were changed, no extensions installed, no flags toggled.
What works on a factory-fresh Orion install:
Bitmovin DRM demo (HLS + FairPlay, single-key) — plays fine
Apple HLS test streams (developer.apple.com/streaming/examples) — plays fine
Apple fMP4 test streams — plays fine
Amazon Prime Video — plays fine
Spotify Web Player — plays fine
What fails:
Bitmovin’s capability check confirms EME is supported and FairPlay is detected as the active DRM system. Widevine is not supported, which is expected.
Key findings:
This reproduces on a completely clean Orion install. No Compatibility Mode, no UA spoofing, no experimental flags, no extensions. Error 83 appears immediately on a stock install. This is not a configuration issue.
Simple FairPlay works perfectly. Bitmovin’s FairPlay test, Apple’s own HLS test streams (including fMP4), Amazon Prime Video, and Spotify all play without issue. The fundamental FairPlay handshake, entitlements, and Verified Media Path are all working correctly.
Only production streaming services with complex FairPlay sessions fail. Disney+, Netflix, and HBO Max all use multi-key content encryption, concurrent audio+video SourceBuffers with separate key IDs, and server-driven license renewal. These are the services that break.
Safari has identical non-fatal errors but plays fine. I ran Disney+ with Web Inspector in both Safari and Orion on the same machine. Both browsers show:
Failed to preconnect to https://edge.bamgrid.com/ — hostname not found
Library Detected: undefined, UA Detected: safari
Could not determine privacy consent status before playback
Conviva CORS blocks
Sandbox access violations on about:blank frames
None of these cause the failure. Safari ignores all of them and plays the video. Orion shows the same errors and fails.
The actual failure point: Both browsers create the blob: URL on the <video> element. Both fetch encrypted segments from Disney’s CDN. In Safari, the segments are decrypted and appended to the SourceBuffer normally. In Orion, the MediaSource’s readyState transitions to closed when the first segment is appended:[Error] Fatal: Fail to append buffer to audio media source:
-updating: false, readyState: closed, operationType: append,
MEError: 3 The object is in an invalid state.
[Error] SOURCE_BUFFER_INVALID_STATE_ERROR (fatal)
[Error] Fatal PlaybackSessionStateChange error...
client should release PlaybackSession
With Compatibility Mode enabled, the failure actually happens earlier — the blob: URL isn’t created at all and the <video> tag stays empty.
Revised analysis:
In my earlier post #19), I suggested this might be an entitlement/code signing issue with Orion’s custom WebKit binary failing the Verified Media Path check. The new evidence rules that out — Apple’s own FairPlay test streams work, so VMP and entitlements are fine.
The bug is specifically in Orion’s EME/MSE coordination layer when handling complex multi-buffer encrypted sessions. The likely suspects are:
Multi-key / key rotation during playback
Concurrent encrypted SourceBuffers (separate audio + video with independent key IDs)
Server-driven license renewal (persistent sessions vs. temporary)
Complex EME event sequencing that Disney’s HivePlayer / Netflix’s Cadmium player depend on
These are all features that Apple’s simple test streams and Bitmovin’s demo don’t exercise, which is why those work while production services don’t.
It appears this is not an upstream WebKit bug. Other third-party WebKit browsers (Nook) handle Disney+ and Netflix with no issue. The problem is in Orion’s bridging layer between WebKit’s media pipeline and the system CDM.
@Yannick and @dino Happy to provide full console logs from both Safari and Orion, or any other testing you’d find useful.
