Backups & Storage
Plex buffering on a NAS
Separate direct play, transcoding, network, and storage causes when a NAS-hosted Plex stream buffers or pauses.
Problem summary
Plex buffering on a NAS is usually a transcoding load, network path, or client codec mismatch rather than a Plex bug. The fastest path is to read the server dashboard first, then check the layer the dashboard points at.
Read the Plex Dashboard while the buffer is reproducing.
Plex Web > Settings > Status > Dashboard > active session row
The active session row shows Direct Play, Direct Stream, or Transcode along with a Reason (codec, container, audio, subtitle).
Stop before disabling parity protection or critical scheduled jobs permanently.
Layer path
Step-by-step runbook
Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.
Reproduce the buffer with the Dashboard open
Check: Start the buffering file and switch to Plex Web > Settings > Status > Dashboard.
Expected result: You can see the active session row and the Reason field while buffering.
If not: If no buffering happens with the Dashboard open, capture a different file or time that reliably reproduces.
Read the Reason and the bitrates
Check: Note Direct Play / Direct Stream / Transcode, the source bitrate, the transcoded bitrate, and the Reason text.
Expected result: You know whether this is video, audio, subtitle, container, or bandwidth.
If not: If the Reason is unclear, hover over the session row for more detail or check the server log timestamp.
Pause non-Plex NAS workloads and retest
Check: Pause active backup jobs, parity checks, and Mover; stop heavy Docker containers.
Expected result: If the buffer disappears, the cause was contention, not Plex itself.
If not: If buffer persists, contention is not the layer; continue.
Safe stop: Stop before disabling parity protection or critical scheduled jobs permanently.
Isolate the network path
Check: Wire the client or move it close to the AP; run iperf3 between client and NAS if available.
Expected result: Throughput exceeds the source bitrate by at least 2x.
If not: If throughput is below the bitrate, the network is the bottleneck.
Fix the layer the evidence points at
Check: Subtitle burn-in: passthrough mode. Video transcode: lower remote quality or pre-transcode. NAS CPU: hardware-transcoding host or fewer concurrent streams. Storage: separate Plex appdata onto cache pool / SSD.
Expected result: The targeted fix removes the buffer without weakening other workloads.
If not: If the targeted fix has no effect, re-read the Dashboard Reason; the layer may have shifted.
Safe stop: Stop before opening router ports for remote access; use Plex Relay or pre-transcoded copies if upstream is limited.
Decision tree
If: Dashboard says Direct Play but the stream still buffers.
Then: Playback path is correct; the network or client is the bottleneck.
Action: Wire the client or move closer to the AP; run iperf3 between client and NAS to measure the actual path.
If: Dashboard says Transcode with reason Video.
Then: Source codec or container is not supported by the client; NAS CPU is the bottleneck.
Action: Lower remote quality, pre-transcode the file, or move Plex to a host with hardware transcoding.
If: Dashboard says Transcode with reason Subtitle.
Then: Burn-in is forcing transcoding even when video would direct-play.
Action: Set subtitle mode to passthrough, or pick a client/format combination that supports the subtitle natively.
If: Buffer is only on Internet sessions; LAN is fine.
Then: Upstream bandwidth, CGNAT, or Remote Access state is the layer.
Action: Lower remote quality, check ISP upload speed, and verify Remote Access state in Plex server settings.
Safe stop: Stop before opening router ports; prefer Plex Relay or pre-transcoded copies if upstream is genuinely limited.
If: Multiple sessions buffer simultaneously even with low per-session bitrate.
Then: NAS CPU or disk IO is saturated by concurrent transcoding or backup workloads.
Action: Reduce concurrent transcoding limit in Plex, stagger backup schedules, or move Plex to better hardware.
Evidence table
| Symptom | Evidence to collect | Likely layer | Next action |
|---|---|---|---|
| Buffer only on 4K HEVC files. | Dashboard reason: Video codec; NAS CPU at 100% during play. | Transcoding load on a host without hardware decode. | Pre-transcode to H.264 1080p or move Plex to a host with hardware transcoding. |
| Buffer only when subtitles are enabled. | Dashboard reason: Subtitle; CPU rises only when subtitle is on. | Subtitle burn-in | Switch subtitle mode to passthrough or pick an external subtitle file the client supports. |
| Buffer only on one specific TV/client. | Other clients play the same file fine. | Client device or its network path. | Wire the client or test the same file on another client to confirm the layer. |
| Buffer starts at the same time every night. | Backup jobs, parity check, or Mover scheduled in that window. | NAS workload contention. | Shift Plex priority workload outside the backup window or stagger schedules. |
Commands and settings paths
Plex Dashboard reason
Plex Web > Settings > Status > Dashboard > active session row
Where: On the Plex server web UI while the buffer is reproducing.
Expected: The session row names Direct Play / Direct Stream / Transcode and a Reason field with the failing layer.
Failure means: Without the reason, you cannot tell codec, bitrate, subtitle, and network apart.
Safe next step: Capture the reason and source/transcoded bitrates before changing anything.
NAS CPU and disk IO during play
Unraid Dashboard / Synology Resource Monitor / TrueNAS Reporting / QNAP Resource Monitor
Where: In the NAS admin UI in a second tab while the buffer reproduces.
Expected: CPU stays below ~70% and no disk is at 100% utilization.
Failure means: Saturated CPU is transcoding bottleneck; saturated disk is storage contention.
Safe next step: Stop concurrent workloads and retest before blaming Plex.
Plex server logs
Plex Web > Settings > Server > Help > Download Logs
Where: On the Plex server web UI after a reproducible buffer.
Expected: Plex Media Server.log contains the session timestamp and any 'Transcode failed' or 'Buffer underrun' entries.
Failure means: Without logs, fixes are based on guesswork.
Safe next step: Download and search the log around the buffer time before changing transcoder settings.
Network path bandwidth
iperf3 -c <plex-server-ip>
Where: On the buffering client device (Mac/Linux/Windows with iperf3 installed).
Expected: Measured throughput exceeds the source bitrate of the buffering file by at least 2x.
Failure means: If throughput is below the bitrate, the network path is the bottleneck.
Safe next step: Wire the client or move closer to the access point; do not change Plex transcoder settings yet.
Hardware and platform boundary
Change only when
- Buy a Plex host with hardware transcoding (Intel Quick Sync N100/N305 or similar) only after the Dashboard Reason consistently shows Video transcoding and the current host CPU is the proven bottleneck.
Evidence that matters
- Hardware transcoding support, host CPU single-thread performance, fast cache/SSD for the transcoding temp directory, and wired LAN to clients matter.
Evidence that does not matter
- Total drive bays, RGB, and marketing 'AI' features do not improve playback path.
Avoid
- Avoid buying NAS hardware to fix buffering that is actually a Wi-Fi or subtitle issue.
Related tool/checklist
Use the linked tool when you need a guided plan from your exact symptoms instead of a static checklist.
NAS storage and backup plannerRelated problems
Last reviewed
2026-05-07 · Reviewed by HomeTechOps. Reviewed for Plex playback chain triage using Dashboard Reason, NAS CPU/IO evidence, server logs, network bandwidth measurement, and subtitle/transcode-layer separation.
Sources/assumptions
- Assumes Plex Media Server is running on the NAS itself (Docker or native app), not on a separate machine reading the NAS over SMB/NFS.
- Exact transcoding behavior depends on NAS CPU model, hardware-transcoding licensing, source codec, and the client device's supported codecs.
Source-backed checks
HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.