Plex buffering at the start of every episode? Check disk spin-up

Aug 11, 2026 · unraid, plex, storage, troubleshooting

Every episode started the same way: hit play, watch the spinner for ten to fifteen seconds, then flawless playback for the next forty minutes. No buffering mid-stream. No quality drops. Just a stall at the beginning, every single time.

That pattern — slow to start, perfect once started — is the whole diagnosis, and it points away from everything people normally blame.

Why it isn’t Plex, and isn’t transcoding

A transcoding problem doesn’t behave like this. If the CPU or GPU couldn’t keep up, you’d see stalls throughout playback, worse in busy scenes. A network problem looks similar. A failing disk throws errors and gets slower over time.

A stall that happens only at the start, then never again, means something had to wake up before the first byte arrived.

Here’s what I ruled out before landing there, with the numbers:

Every component was healthy. Which is the point: nothing was broken. The system was behaving exactly as configured, and the configuration was wrong.

The measurement that proves it

This is the test worth running, because it turns a hunch into a number. Read a file from the media disk twice — once after the disk has been parked a while, then again straight after.

Same drive, same file, minutes apart:

spinning up : 58 MB/s
fully awake : 243 MB/s

A ~4x difference, entirely explained by the platters getting up to speed and the heads seeking for the first time. Ten to fifteen seconds of that at the front of a stream is exactly the stall Plex was showing.

If you want to see the state directly rather than infer it:

# is the disk actually parked right now?
hdparm -C /dev/<device>      # "standby" = parked, "active/idle" = awake

Two wrong turns worth recording

I did not go straight there, and the detours are instructive.

I suspected the GPU first. A graphics card had been reinstalled recently, and my theory was that device indexes had shifted and Plex was now pointed at the wrong card. Plausible — but wrong, because Plex was pinned by UUID, not by index, so the shift couldn’t affect it. nvidia-smi inside the container confirmed it still had the right card. That’s the whole argument for pinning GPUs by UUID rather than device index: it doesn’t just prevent the bug, it lets you eliminate an entire theory in thirty seconds.

Then I measured the wrong disk. Twice. Device letters had shifted across a reboot — the disk I wanted was now sdl, not the letter I remembered. I was benchmarking a completely different drive and drawing conclusions from it.

The rule: never trust a device letter you remember across a reboot. Resolve it from rdevName.N in /proc/mdstat or from disks.ini every time. Letters are assigned at enumeration and they move.

The blind spot that caused it

The spindown setting wasn’t a mystery or a default someone forgot about. It had been deliberately set to 30 minutes, with an explicit and reasonable-sounding rationale:

nothing routinely writes to the array

That’s true. It’s also irrelevant, and that’s the actual bug. Nothing routinely writes to the array — but Plex reads from it constantly, every time anyone watches anything. The rationale considered one direction of I/O and silently assumed the other didn’t matter.

Worth remembering as a general habit: when you justify a power-saving setting, check the justification against reads as well as writes. Media libraries, backup verification and anything that scans on a schedule are all read-heavy and will fight a spindown timer.

The fix: per-disk, not global

You do not want to disable spindown across the whole array. Most disks genuinely are idle most of the time, and keeping eight drives spinning around the clock costs real money and real heat.

Set Never on the disks that hold media, and leave the global timer alone for everything else:

Media disks       -> Never
Everything else   -> 30 min (or whatever your global is)

Which disks hold your media is worth checking rather than assuming — with Unraid’s allocation, a share can be spread across more disks than you think.

Gotcha 1: apply it through the GUI, not by editing disk.cfg

The running emhttpd process owns these values. If you edit disk.cfg on disk, your change is ignored until the next reboot — and worse, the file will disagree with live behaviour in the meantime, which is a great way to lose another hour.

This is the same stale-config trap that catches people editing share and pool settings by hand. Use the Disk Settings page.

If you’re driving it programmatically, the form submits changeDisk=Apply with diskSpindownDelay.<idx>, where the index comes from disks.ini (parity is 0, disk1 is 1, and so on). Replay every disk*.<idx> field at its current value in the same submission, or the fields you omit get reset.

Gotcha 2: “Never” does not wake a sleeping disk

Setting a disk to Never stops it parking again — it doesn’t undo the fact that it’s parked right now. The next playback will still stall once. Spin them up manually so you’re not confused by one last slow start:

dd if=/dev/<device> of=/dev/null bs=1M count=100

After that, both disks read at 241 and 244 MB/s immediately, and the stall was gone.

Is this worth the power?

Honestly, it’s a real trade. A 3.5” drive spinning continuously uses roughly 5–8 W more than a parked one. Two disks kept awake permanently is on the order of 100–140 kWh a year — enough to notice on a bill, not enough to change your life.

The alternative — leaving the timer on and living with a ten-second stall before everything anyone watches — is worse for exactly the reason it took so long to diagnose: it doesn’t look like a config choice, it looks like Plex being broken.

Quick reference