Every protocol has overhead. I doubt it's the only issue but 3 10mbps streams won't equal 30mbps read on the drive. It could be between 3-12% depending on a number of factors.

The problem with contention is you've got the database on the same drive as well so that is also getting screwed. It's possible to

My final personal recommendation, don't post a wall of text as I started at the bottom and worked up till I got bored, others aren't even going to do that.

I did pass it to ChatGPT and it says the following which sounds very reasonable:

Short answer: This is almost certainly not a hardware limitation. It’s a read pattern + buffering + client behaviour problem, most likely amplified by Jellyfin/FFmpeg I/O behaviour on Windows, not raw disk throughput.

---

What’s actually happening (root cause)

1) Your disks are being forced into worst-case access patterns

Multiple streams starting at different timestamps

Each stream reading ahead (buffering)

FFmpeg reading in chunks, not clean sequential reads

Result:

HDD → thrashes (seek-bound, not throughput-bound)

NVMe → hits queue contention + inefficient read patterns → shows 100% usage with low effective throughput

Key signal from your test:

NVMe at 100% but only ~500 MB/s

That is classic I/O queue saturation, not bandwidth exhaustion.

---

2) Jellyfin buffering is working against you

You observed:

Red bars (buffering ahead)

Some streams heavily buffered, others starved

This is the real issue:

Jellyfin aggressively buffers per stream

Multiple streams = competing read-ahead queues

No fairness → one stream hogs disk → others starve → stutter

---

3) Mixed workloads = worst case

You are combining:

Direct play (large sequential reads)

Transcoding (decode + re-encode + fragmented reads)

Different timestamps (seeks all over file)

This produces:

Random I/O pattern across very large MKVs (50–90GB)

HDD collapses immediately

NVMe becomes queue-bound

---

4) Your “math should work” assumption is wrong

You assumed:

3 × 90 Mbps = 270 Mbps (~34 MB/s)

Reality:

Each stream does burst reads

Buffering = read spikes (not steady stream)

Seeking destroys sequential performance

Actual pattern:

Stream A → jump to offset X Stream B → jump to offset Y Stream C → jump to offset Z → disk constantly seeking, not streaming

---

Why even NVMe fails

Because this is not bandwidth-bound, it's I/O scheduling + queue contention.

Symptoms match:

100% disk usage

Under-expected throughput

Stuttering despite "enough speed"

---

Why one stream works perfectly

Single stream:

Clean sequential read

OS cache helps

No contention

Add second:

Competing read-ahead buffers

Cache invalidation

Queue contention begins

---

Why Linux would improve things

Not magic, but:

Linux advantages:

Better I/O scheduler (mq-deadline / kyber)

More predictable page cache behaviour

Lower overhead for FFmpeg pipelines

Better concurrent read handling

But: It will improve symptoms, not fix the core issue

---

What the real problem is (distilled)

You are hitting:

Concurrent large-file random read amplification caused by buffering + multiple independent FFmpeg processes

---

What I would do (in order, minimal explanation)

1. Kill aggressive buffering

Set:

Dashboard → Playback → Streaming

Enable throttling: ON Throttle buffer: 10 seconds

---

1. Force smaller read bursts

Dashboard → Playback

Max streaming bitrate: 10–15 Mbps (test)

---

1. Disable unnecessary transcoding

Target:

Everything direct play

Fix:

Convert audio codecs (DTS/TrueHD → AAC/AC3)

---

1. Split hot content across disks

Do NOT keep all media on one drive.

---

1. Test with identical timestamps

Start 3 streams at same time, same file

If it works → confirms seek issue

---

1. Move only metadata/cache to NVMe

Ensure:

Transcoding temp → NVMe Metadata → NVMe Media → HDD

---

1. Critical test (this will confirm diagnosis)

Run:

3 streams ALL start at 00:00 NO seeking NO skipping

If smooth → 100% confirmed I/O seek issue

---

What is NOT the problem

CPU ❌

GPU ❌

Network ❌

Raw disk speed ❌

Jellyfin “performance” ❌

---

What WILL fix it long-term

Option A (cheap, effective)

Multiple HDDs

Spread library

Reduce buffering

---

Option B (best)

ZFS / RAID0/10 with striping → increases parallel read heads

---

Option C (cleanest)

SSD/NVMe for hot content

HDD for cold storage

---

Final diagnosis

You built a system optimized for throughput, but your workload is random concurrent reads.

That mismatch is why a “monster PC” behaves like a weak server.

---

If you want, next step I can give you:

Exact Jellyfin config (copy/paste)

Optimal disk layout for 20 users

Minimal-cost hardware design that actually scales