Add configurable per-stream connection limit (separate from global connection settings)

[r0bsen86]

Is your feature request related to a problem? Please describe.

Yes. Currently the connection settings in nzbdav are global only. When a single stream is played, it immediately saturates all available download connections (in my case all 15 download connections / up to the 50 provider connections to my Usenet provider). This means one stream consumes the entire connection pool, leaving nothing for other concurrent streams.
I share my setup with family members, and when several people stream at the same time, they all compete for the same global connection pool. A single playback already maxes everything out, so additional streams suffer from slow start, buffering, or stalled downloads. There is currently no way to reserve or distribute connections fairly across multiple simultaneous streams.

Describe the solution you'd like

A configurable per-stream connection limit, separate from the global connection setting. For example, an option such as "max download connections per stream" that caps how many connections any single active stream is allowed to use, regardless of how many are globally available.
This would let the global pool be shared more evenly across concurrent streams. Example: with 15 global download connections and a per-stream limit of 5, up to three streams could run in parallel without one stream starving the others. Ideally this limit would be a simple numeric setting in the WebDAV/streaming configuration, applied independently to each active stream/mount.

[loambit]

I'm using these rclone settings as a workaround (smaller chunk sizes result in more connections but also prevents one stream from starving the others):

--vfs-read-chunk-size=32M --vfs-read-chunk-size-limit=32M

[tylerwiebermusic-max]

Connection per stream makes no sense, it was removed for a reason

[r0bsen86]

I'm using these rclone settings as a workaround (smaller chunk sizes result in more connections but also prevents one stream from starving the others):

--vfs-read-chunk-size=32M --vfs-read-chunk-size-limit=32M

thanks! i thought i can pass the sidecar installation. Maybe i give it a try

[r0bsen86]

Connection per stream makes no sense, it was removed for a reason

Okay and why it makes no sense? Please enlighten me; maybe I'm missing something.

[Shisuki]

Okay and why it makes no sense? Please enlighten me; maybe I'm missing something.

@r0bsen86 From my understanding, setting per-stream connection limits would just block unused connections once a stream doesn't need them anymore. Which would hurt your overall stream capacity.

So imagine you have 50 connections and you set 10 connections/user limit, when streamA stars it would capture 10 connections from your overall 50 pool to buffer the file and keep it running, but this isn't ideal.. if you stream an FHD file then 1-2 connections is enough, the other 8-9 would be unopened and wasted here. If you're instead streaming a 4k remux file, then those 10 connections would barely be enough to cover it and the stream would buffer non stop.

If another concurrent stream starts, it would capture another 10 connections from your now 40 pool, use them all to buffer then 9 are either wasted or your stream is starved, and so on with every stream started.. so basically with a 50 connection pool you can only start a maximum of 5 concurrent inefficient streams.. really not ideal.

With the current global pooling system, a stream starts, uses all your Max Download Connections (see: #390 (comment)), let's say 15 to aggressively fill the stream buffer, and only capture 1-2 dedicated to keeping the stream alive and opening more connections as needed. Another stream starts, it repeats the process etc etc.. so you have a much higher limit of how many concurrent streams your NzbDAV can support.

(@nzbdav-dev please feel free to correct me if I'm wrong)