STRM files with HLS proxy - Windows app instant start/stop cycle, DirectPlayError fallback fails

[Meeko 35]

Environment:

• Emby Server 4.9.3.0 (Linux, Ubuntu)
• Emby Windows App 2.234.2.0 (device: GAMING_X3D)
• Remote access via DDNS (subdomain.ddns.net:8096)
• User: meeko, isInLocalNetwork: False

Setup:
I have a custom HLS proxy service running on the Emby server at localhost:5081. My .strm files contain URLs like:

http://localhost:5081/play/jujutsu-kaisen/3/7

The proxy resolves the actual stream source, fetches the HLS master playlist (m3u8), rewrites segment URLs to route through the proxy, and serves the rewritten HLS stream. This works perfectly in web browsers (hls.js handles it fine).

The Problem:
The Emby Windows desktop app cannot play these STRM files. It enters a rapid start/stop cycle and eventually shows an error or gives up.

Observed Behavior (from server logs):

1. Emby tries DirectPlay first via original.hls - receives the m3u8 but fails:

GET /emby/videos/143265/original.hls?...&PlaySessionId=8fe172fabe404d2cb072c0c60796c2cf
HttpClient: GET http://localhost:5081/play/jujutsu-kaisen/3/7
HttpClient: Http response 200 from http://localhost:5081/play/jujutsu-kaisen/3/7 after 153ms
Response 206 to xx.xx.xxx.xxx. Time: 154ms. Content-Type=application/octet-stream, Content-Length=3467

The server fetches the m3u8 from the proxy successfully (3467 bytes), serves it to the client as application/octet-stream with a 206 response. But then immediately:

Playback stopped - Position: 0 ms. PlaySessionId: 8fe172fabe404d2cb072c0c60796c2cf

2. App falls back to transcoding with TranscodeReasons=DirectPlayError:

GET /emby/videos/143265/master.m3u8?...&EnableDirectPlay=false&EnableDirectStream=false
  &MaxStreamingBitrate=7000000&TranscodeReasons=DirectPlayError

3. Emby starts ffmpeg transcoding (DirectStream copy) from the proxy URL:

ffmpeg -i "http://localhost:5081/play/jujutsu-kaisen/3/7" 
  -c:v:0 copy -c:a:0 copy -f segment -segment_format mpegts 
  -segment_time 00:00:03.000 ...

4. First segment takes ~10 seconds, then segments flow normally:

GET /emby/videos/143265/hls1/main/0.ts - Response 200. Time: 9686ms (first segment!)
GET /emby/videos/143265/hls1/main/1.ts - Response completed after client disconnected. Time: 19ms
GET /emby/videos/143265/hls1/main/2.ts - Response 200. Time: 2ms
GET /emby/videos/143265/hls1/main/3.ts - Response 200. Time: 755ms
...segments 4-15 flow normally...

5. But the app has already given up - it stops and retries the whole cycle:

Playback stopped - Position: 8500 ms (barely started)

Then immediately starts a NEW session, repeating steps 1-4. This loop continues multiple times.

6. ffprobe calls are slow (blocking PlaybackInfo responses):

ffprobe -i "http://localhost:5081/play/jujutsu-kaisen/3/5" ...
PlaybackInfo Response Time: 10686ms (blocked by ffprobe!)

7. Client disconnects during segment delivery:

Response completed after client disconnected to xx.xx.xxx.xxx. Time: 19ms.
  GET .../hls1/main/1.ts

8. One session briefly worked locally before remote retry killed it:
When accessed from LAN (192.168.178.87, isInLocalNetwork: True), the transcoding actually started and delivered segments. But the app switched to remote mode and killed the session:

# LAN session - segments flowing:
Playback stopped - Position: 59999 ms (played ~60 seconds!)

# Remote session - instant death:
Playback stopped - Position: 0 ms

Key Observations:

• The original.hls endpoint serves the m3u8 as Content-Type: application/octet-stream - should this be application/vnd.apple.mpegurl?
• The Windows app's native player seems to not understand the proxied m3u8 served as octet-stream
• ffprobe takes 7-10 seconds per STRM URL (it has to fetch the HLS stream to probe it), which blocks PlaybackInfo responses
• MaxStreamingBitrate=7000000 (7 Mbps) is the remote limit, but the first transcoded segment takes ~10s, causing the app to time out
• When accessed locally (isInLocalNetwork: True), the stream actually played for 60 seconds before being killed
• The app enters a rapid retry loop: DirectPlay attempt → fail → transcode attempt → first segment slow → app gives up → repeat

Questions:

1. When Emby serves a .strm file via the original.hls endpoint, does the Windows app expect a specific Content-Type? The server returns application/octet-stream for what is actually an m3u8 playlist.
2. Is there a timeout for the first HLS segment in the Windows app? The 10-second wait for 0.ts (while ffmpeg fetches the source and starts segmenting) seems to cause the app to abort.
3. Is there a way to set MinSegments higher so the app waits for more segments before starting playback?
4. Why does the app work briefly when isInLocalNetwork: True (played 60s) but instantly fail when isInLocalNetwork: False for the same content?

TV Apps Samsung, Android, Linux work perfectly!!

Any guidance would be appreciated. Happy to provide ffmpeg logs or additional server logs.

Edited 29 minutes ago by Meeko