![]() |
Dynamic user bandwidth allocation? - Printable Version +- Jellyfin Forum (https://forum.jellyfin.org) +-- Forum: Support (https://forum.jellyfin.org/f-support) +--- Forum: General Questions (https://forum.jellyfin.org/f-general-questions) +--- Thread: Dynamic user bandwidth allocation? (/t-dynamic-user-bandwidth-allocation) |
Dynamic user bandwidth allocation? - dakazze - 2025-06-10 Hey guys! Sadly it looks like it will take another year until we finally get fiber here and for the time being I am stuck with 50 MBits upload. Since I only have 2-3 users outside of my LAN and not too much concurrent use, limiting their upload to 20 MBits has been working fine but thinking about ways to make the most of what I got I came up with this concept and I would appreciate some input for the jellyfin side of things (API possibilities, etc.): So my plan is to build a node or python daemon that basically has 2 main components. 1. Talk to openWRT: Keep asking the openWRT router about the demand for upload bandwidth outside of Jellyfin and if I am super motivated, it might dynamically change SQM settings. 2. Talk to Jellyfin: Keep asking Jellyfin how many users are streaming outside of the LAN and dynamically limits upload bandwidth for each remote user. This way a single streaming user can have 100% of the bandwidth as long as there is no other demand for it. When a second remote user starts streaming, both get an equal share of the bandwidth and when there is high priority demand from my office PC I can still ensure that both remote clients still have a good minimum share of the cake to stream their stuff. This way the upload bandwidth I have available is always utilized as good as possible and my users get the best possible quality all the time, only getting throttled when actually needed. I would really appreciate every bit of input:
RE: Dynamic user bandwidth allocation? - akepound - 2025-06-11 Your idea of a daemon that dynamically checks both OpenWRT and Jellyfin states is solid. For Jellyfin, the API does expose session info (/Sessions) which includes whether a user is streaming, their IP (LAN or WAN), bitrate, etc. So tracking remote streaming users in real time is totally doable. RE: Dynamic user bandwidth allocation? - dakazze - 2025-06-11 Thank you @akepound ! I just finished studying the API a bit and it looks like everything I need is already in place. The only important piece of info I am missing (for now) is what happenes after changing the bandwidth/bitrate limit mid session. Does anyone know if it is applied right away mid-session or if it would take a session restart for the change to take effect? If it does not work mid session I would have to figure out a way to make the process as seamless as possible. RE: Dynamic user bandwidth allocation? - Venson - 2025-06-12 no a bitrate change mid-session does not change a stream in progress RE: Dynamic user bandwidth allocation? - dakazze - 2025-06-12 (2025-06-12, 08:01 AM)Venson Wrote: no a bitrate change mid-session does not change a stream in progress Thank you very much for this info! I already built the framework for my little daemon and it is already getting active sessions, checking their IPs, getting and setting the bandwidth for each user. Applying the changes mid session proofs harder than expected though, so I would be grateful for any idea that might help. For now I am using the playing/stop endpoint to force stop a session which is then automatically resumed but it is a ~3 seconds interruption that is flashing the episode selection for ~1 second which is far from seamless. (edit: almost finished with a first fully working version. I already prepared a github repo and will share it once done) RE: Dynamic user bandwidth allocation? - Efficient_Good_5784 - 2025-06-13 Considering that the server stops the current ffmpeg process and creates a new process with the updated settings, maybe making it launch a new ffmpeg process while the old one is still running can solve the issue. Then, it would just be a matter of timing the new transcode to align with the old one, switching to the new one, and finally deleting the old process when done. RE: Dynamic user bandwidth allocation? - dakazze - 2025-06-14 (2025-06-13, 04:23 AM)Efficient_Good_5784 Wrote: Considering that the server stops the current ffmpeg process and creates a new process with the updated settings, maybe making it launch a new ffmpeg process while the old one is still running can solve the issue. Thanks for taking the time to chime in! I already tried via ffmpeg but for some reason it did not work out. I think it was because there is only a ffmpeg process when transcoding so updating users in a direct play session would not work. With a bit of tuning I might get this working without it being too intrusive: - change bandwidth limit - get current episode and timestamp - stop playback - start playback - jump to timestamp All of this is already working in my current build but it somehow is pretty hard to really allign the timestamp correct. Another unforeseen challenge is getting a good reading of jellyfins outgoing traffic (excluding streams of local users) due to flow offloading but I already have a few ideas on how to get a reliable reading on that. |