mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-05-04 18:09:12 +03:00
Change per user bandwidth limit to be global #7021
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Splatink on GitHub (May 17, 2025).
The user bandwidth limit is currently applied only to non-local devices, however, since Jellyfin is exposed to the web either via a reverse proxy or VPN by most users this means this setting is not applied.
I would suggest changed it so that this setting applies no matter what, or can be applied when traffic comes from a specific IP or subdomain.
@JPKribs commented on GitHub (May 17, 2025):
You should be able to set this using the LAN network setting. I do this already where I've set my local domains so I can still access it without the restriction but, I specifically made sure not to include the domain/IP address addresses that I know are on my VPN (10.192.1.0/24).
I haven't personally tried it, but my guess is you could just individually set the IP address of the server itself (127.0.0.1/32) and then everything would be treated as remote traffic.
@Splatink commented on GitHub (May 17, 2025):
This can be somewhat fixed by setting LAN networks (as user @JPKribs mentioned literally as I was writing this) in the networking settings (setting an invalid IP so that all traffic is considered non-local and the bandwidth limit is applied to everyone).
This is a hacky fix that only works with VPN traffic (so say local net 10.0.0.0/24 isn't limited but vpn traffic 10.0.20.0/24 is) and doesn't with reverse proxy traffic (say reverse proxy running on 10.0.0.5).
The best way to go about this would be to instead forget about trying to differentiate local and internet traffic and instead run a quick bandwidth test before playback and then set bitrate accordingly.
The interface can have an option to set the server's internet bandwidth (say 5Mbit/s) and if the test run shows equal or less than that then an additional option "max user bandwidth percentage" can be applied (say 50%). But if the test exceeds the internet bandwidth (say 950Mbit/s because local device) then "max user bandwidth percentage is ignored, but bitrate changes may still apply.
An example:
Server Bandwidth: 5Mbit/s
Media Bitrate: ~50Mbit/s
User: John
Origin: Internet
Bandwidth Test: 4Mbit/s
User's Set Limit: 50%
Bitrate Chosen For Transcode: 2.5Mbit/s
User: George
Origin: Internet
Bandwidth Test: 1Mbit/s
User's Set Limit: 50%
Bitrate Chose For Transcode: 1Mbit/s or a safer value
User: Splatink
Origin: Local
Bandwidth Test: 950Mbit/s
User Set Limit: 75%
Bitrate Chosen For Transcode: No transcode needed
User: Splatink
Origin: Local, weak wi-fi
Bandwidth Test: 25Mbit/s
User Set Limit: 75%
Bitrate Chosen For Transcode: 25Mbit/s or a safer value
@JPKribs commented on GitHub (May 17, 2025):
For the reverse proxy, your best off using X-Forwarded-For then using the
Known proxiessetting in Jellyfin. This forwards the original IP instead of using the proxy's IP. This would require that you also configure that on the reverse proxy as well but I believe that's the default in the docs. I see it's there in the NGINX configuration.This is where you would set your Proxy's IP. You WOULD NOT use this for the VPN's IP:
For the Bandwidth check, I added that on Swiftfin a while back and I'm less than impressed:
https://github.com/jellyfin/Swiftfin/pull/1147
The issue I see is that you need to take a fairly long test to get a consistent bitrate. In quick bursts, networks can dramatically over/under report the true available bandwidth for streaming. You can get a decently accurate test but it might take 10+ seconds of waiting before the stream to properly test it. Even then, since most Jellyfin instances are on home networks, you can't be certain that the bitrate you test at the beginning of a stream will exist at the end. I know Android TV removed it for this exact reason. Even Plex appears to have recently removed the auto-bitrate setting in their latest app rewrite, likely for the same reasons.
This being said, bitrate testing would fall more on the client side than the server side for this change. From personal experience, I unfortunately wouldn't recommend it