Plex Transcoding Troubleshooting¶

Common issues when Plex is transcoding instead of direct playing, and how to fix them.

Playback Stops After ~1 Minute¶

Symptom: Video starts normally, plays for 60–90 seconds, then freezes or stops. Hitting play again works briefly, then stops again.

Cause: The Plex server is software-transcoding the stream and the CPU can't keep up in real time. Plex delivers video as a series of short HLS segments (3 seconds each by default). When the transcoder falls behind real-time, the client exhausts its segment buffer and stops.

This is most common when: - The client has an auto-quality or bandwidth-limit setting enabled, forcing a transcode even for natively supported codecs - The source file is HEVC and the client is set to anything other than "Play Original" - Multiple streams are transcoding concurrently and saturating the CPU

How to Confirm¶

SSH into the Plex host and check for an active software transcode:

ps aux | grep 'Plex Transcoder' | grep -v grep

Look for libx264 or libx265 in the output — these are CPU software encoders. A CPU% above 30–40% per stream on an i7-7700K means it's at or near the real-time limit for 1080p60.

Fix: Enable Direct Play¶

The correct fix is to eliminate the transcode entirely.

On Apple TV: 1. Open the Plex app → tap the user icon → Settings 2. Go to Quality 3. Set both "Home Streaming" and "Remote Streaming" to "Play Original" (or "Maximum") 4. Restart playback

Apple TV 4K supports direct play for H.264, HEVC (H.265), and most common containers (MP4, MKV). With "Play Original" set, Plex streams the file as-is with no server-side processing.

On other clients: Look for a Quality or Streaming Quality setting and set it to Original/Maximum. The specific label varies by app version.

Direct play still fails if the file's PEAK bitrate exceeds the link

"Play Original" removes the transcode, but the client must then pull the file at its full bitrate. Files encoded with constant-QP and no rate ceiling can average 32 Mbps while peaking at 149 Mbps — beyond any Wi-Fi link. Check the per-second bitrate, not the average, before assuming direct play is sufficient. See 4K60 Transcode Ceiling and VBR Peaks on Wi-Fi Clients.

If Direct Play Isn't Possible¶

If the client genuinely can't decode the source codec (e.g., a browser playing HEVC), reduce the transcode quality to something the CPU can sustain in real time:

8 Mbps 1080p is usually achievable for a single stream on an i7-7700K
Avoid 1080p60 at high bitrates — the frame rate doubles the encoding work

Alternatively, enable hardware transcoding (see below).

Understanding When Plex Transcodes¶

Plex will transcode (convert on the fly) when any of the following are true:

Trigger	Example
Client can't decode the codec	Browser playing HEVC
Client quality is set below original	"8 Mbps 1080p" selected
Audio codec isn't supported by client	DTS-MA, TrueHD on some devices
Subtitles need burning in	Forced image-based subs (PGS)
Bandwidth limit set in Plex server settings	Server-side quality cap

Direct play happens when the client supports the video codec, audio codec, container, and no quality downgrade is requested.

Hardware Transcoding (VAAPI / RX 480)¶

majorhome has an XFX Radeon RX 480 8GB with VAAPI support. Hardware transcoding can offload video encoding from the CPU and allows more concurrent transcode streams.

Enable in Plex: Settings → Transcoder → "Use hardware acceleration when available" (requires Plex Pass)

Caveats: - The RX 480 VAAPI encoder (hevc_vaapi, h264_vaapi) is benchmarked ~3× slower than the i7-7700K CPU for single-stream x264 output on this workload. Hardware transcoding only wins when the CPU is already saturated (2+ concurrent streams). - VAAPI hardware transcode on AMD requires the radeonsi Mesa driver and libva-mesa-driver. Both are present on majorhome.

Hardware acceleration does NOT rescue 4K60 sources

Measured on this RX 480: decoding 4K60 HEVC and re-encoding runs at 0.3–0.4x real time at 4K output, and only 1.1–1.5x when downscaling to 1080p. Real-time playback needs ≥1.0x, and ~2x to hold a client buffer. The 4K60 HEVC decode is the bottleneck, so no output-quality setting rescues it.

If a client reports "server is not powerful enough" on 4K content, enabling hardware acceleration will not fix it — the source must be re-encoded to 1080p. See 4K60 Transcode Ceiling and VBR Peaks on Wi-Fi Clients.

Check VAAPI is working:

vainfo 2>/dev/null | grep -E "VAProfile|VAEntrypoint"

CPU Transcoding Capacity (i7-7700K)¶

Scenario	CPU Load	Sustainable?
1× HEVC → H.264 1080p30	~20%	✅ Yes
1× HEVC → H.264 1080p60	~40%	⚠️ Borderline — may drop behind
2× HEVC → H.264 1080p60	~80%	❌ Will fall behind in real time
1× H.264 → H.264 1080p (remux only)	~5%	✅ Yes

Bottom line: One software-transcode stream at 1080p60 is at the edge of what the i7-7700K can sustain. Two will fail. Direct play eliminates the problem entirely.

Checking Active Transcode Sessions¶

# See all active Plex Transcoder processes and what they're encoding
ps aux | grep 'Plex Transcoder' | grep -v grep | grep -oP '\-i \S+' | sed 's/-i //'

# Full transcode command (codec, bitrate, resolution)
ps aux | grep 'Plex Transcoder' | grep -v grep

You can also see active sessions in Plex Web → Dashboard → Now Playing.