[PR #15696] Fix playback of .strm files with internal IPs by enforcing DirectStream #14214

New issue

Open

opened 2025-12-22 10:23:02 +01:00 by backuprepo · 0 comments

backuprepo commented

2025-12-22 10:23:02 +01:00

Owner

📋 Pull Request Information

Original PR: https://github.com/jellyfin/jellyfin/pull/15696
Author: @martenumberto
Created: 12/2/2025
Status: 🔄 Open

Base: master ← Head: fix-wrong-ip-behind-nat

📝 Commits (1)

c1386a7 Fix: Disable Direct Play for .strm files with HTTP URLs to ensure proper playback via proxy

📊 Changes

1 file changed (+11 additions, -0 deletions)

View changed files

📝 Emby.Server.Implementations/Library/MediaSourceManager.cs (+11 -0)

📄 Description

Describe the bug

Currently, .strm files containing HTTP links to internal resources (e.g., Docker container IPs like 172.x.x.x, localhost, or LAN IPs) are treated as "External Media" eligible for Direct Play.

When a client (e.g., Android TV, Web) is located outside the server's immediate network (e.g., different VLAN, external access via reverse proxy), it receives the raw internal IP address from the .strm file. Since the client cannot reach this private IP directly, playback fails immediately.

The Solution

This PR updates MediaSourceManager to intelligently detect if a .strm source URL points to an internal or private network address.
Fixes https://github.com/jellyfin/jellyfin/issues/15411
Previously https://github.com/jellyfin/jellyfin/pull/15575

Changes:

Dependency Injection: Injected INetworkManager into Emby.Server.Implementations.Library.MediaSourceManager.
Smart Detection: In GetPlaybackMediaSources, the code now parses the source URL host.
Config Awareness: It uses _networkManager.IsInLocalNetwork(ip) to check if the IP is local. This respects the user's "LAN Networks" configuration in the Jellyfin Dashboard as well as standard RFC1918 private ranges.
Routing Fix:
- If Internal File: SupportsDirectPlay is set to false. This forces Jellyfin to act as a proxy (typically utilizing ffmpeg -c copy / Direct Stream), making the stream accessible to the client.
- If Public File: Standard behavior is preserved. Public URLs (e.g., Internet streams) continue to use Direct Play to minimize server resource usage.

Testing Done

Environment: Jellyfin running in Docker.
Test Case: Created a .strm file pointing to http://172.19.0.4:8080/video.mkv (another container in the same bridge network).
Before Fix: Client received the http://172... URL and failed to connect.
After Fix: Client received a Jellyfin stream URL. Server logs confirmed "Direct Stream" (Remuxing). Playback was successful.
Regression Test: Verified that a .strm file pointing to a public URL (e.g., a test file on the internet) still utilizes Direct Play.

Checklist

I have read the contributing guidelines.
I have verified that my change is targeting the correct branch.
I have verified that my changes do not break existing functionality (public streams still work).

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/jellyfin/jellyfin/pull/15696 **Author:** [@martenumberto](https://github.com/martenumberto) **Created:** 12/2/2025 **Status:** 🔄 Open **Base:** `master` ← **Head:** `fix-wrong-ip-behind-nat` --- ### 📝 Commits (1) - [`c1386a7`](https://github.com/jellyfin/jellyfin/commit/c1386a776ee46df35f343df52bc39c009a85f40a) Fix: Disable Direct Play for .strm files with HTTP URLs to ensure proper playback via proxy ### 📊 Changes **1 file changed** (+11 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `Emby.Server.Implementations/Library/MediaSourceManager.cs` (+11 -0) </details> ### 📄 Description ### Describe the bug Currently, `.strm` files containing HTTP links to internal resources (e.g., Docker container IPs like `172.x.x.x`, `localhost`, or LAN IPs) are treated as "External Media" eligible for Direct Play. When a client (e.g., Android TV, Web) is located outside the server's immediate network (e.g., different VLAN, external access via reverse proxy), it receives the raw internal IP address from the `.strm` file. Since the client cannot reach this private IP directly, playback fails immediately. ### The Solution This PR updates `MediaSourceManager` to intelligently detect if a `.strm` source URL points to an internal or private network address. Fixes https://github.com/jellyfin/jellyfin/issues/15411 Previously https://github.com/jellyfin/jellyfin/pull/15575 **Changes:** 1. **Dependency Injection:** Injected `INetworkManager` into `Emby.Server.Implementations.Library.MediaSourceManager`. 2. **Smart Detection:** In `GetPlaybackMediaSources`, the code now parses the source URL host. 3. **Config Awareness:** It uses `_networkManager.IsInLocalNetwork(ip)` to check if the IP is local. This respects the user's "LAN Networks" configuration in the Jellyfin Dashboard as well as standard RFC1918 private ranges. 4. **Routing Fix:** * **If Internal File:** `SupportsDirectPlay` is set to `false`. This forces Jellyfin to act as a proxy (typically utilizing `ffmpeg -c copy` / Direct Stream), making the stream accessible to the client. * **If Public File:** Standard behavior is preserved. Public URLs (e.g., Internet streams) continue to use Direct Play to minimize server resource usage. ### Testing Done * **Environment:** Jellyfin running in Docker. * **Test Case:** Created a `.strm` file pointing to `http://172.19.0.4:8080/video.mkv` (another container in the same bridge network). * **Before Fix:** Client received the `http://172...` URL and failed to connect. * **After Fix:** Client received a Jellyfin stream URL. Server logs confirmed "Direct Stream" (Remuxing). Playback was successful. * **Regression Test:** Verified that a `.strm` file pointing to a public URL (e.g., a test file on the internet) still utilizes Direct Play. ### Checklist - [x] I have read the contributing guidelines. - [x] I have verified that my change is targeting the correct branch. - [x] I have verified that my changes do not break existing functionality (public streams still work). --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

backuprepo added the

pull-request

label 2025-12-22 10:23:02 +01:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: starred/jellyfin#14214

No description provided.

Rows
Columns