Roku Ultra Stalling on Transcoding

Plex Players
1

Server Version#: v1.43.2.10687-563d026ea
Player Version#: 9.8.11

I’ve had some weird issues recently where some files work on Roku and others don’t for no obvious reason. They work fine on the web app, iPad, or the Windows app. Only issues with Roku. In the past, I force it to direct play and it worked, but doesn’t seem to work now, just hanging. I asked ChatGPT 5.5 thinking for some help looking into the issue, so what follows is from it.

I’m seeing a reproducible playback-start failure on a Roku Ultra where Plex appears to make a video-copy decision that the Roku cannot actually play.

Environment

  • Client: Roku Ultra

  • Plex client profile shown in logs: Roku-7.x

  • Playback settings:

    • Local Quality: Original

    • Direct Play: Auto

    • Direct Stream: Enabled

  • Server and Roku are on LAN.

  • Subtitles disabled / skipped in the tested playback path.

Symptom

One specific MP4 file never starts playback on the Roku. The Roku/Plex session remains stuck at buffering with playbackTime=0. The server is not obviously starved; the transcoder appears to generate HLS segments and then throttle/sloth.

Relevant failing-log behavior:



Transcoder segment range: 0 - 135...
Session ... is throttling
Throttle - Going into sloth mode.

Then the client repeatedly reports:



state=buffering
playbackTime=0
timeStalled=7

and later:



timeStalled=27
playbackTime=0
state=buffering

and later:



timeStalled=47
playbackTime=0
state=buffering

The same pattern appears in the uploaded failing log: Plex is generating segment ranges and throttling, while the Roku keeps reporting state=buffering and playbackTime=0.

Plex playback decision for failing file

For the failing file, Plex chooses HLS/MPEG-TS, copies the video, and transcodes AAC 5.1 audio to EAC3:



MDE: Hoppers (2026): Direct Play is disabled
MDE: Hoppers (2026): media must be transcoded in order to use the hls protocol
Hoppers - audio.channels limitation applies: 6 > 2
MDE: Cannot direct stream audio stream due to profile or setting limitations
...
decision=transcode container=mpegts protocol=hls
streams=(
  Video=(decision=copy width=1920 height=1040)
  Audio=(decision=transcode encoder=eac3_eae channels=6 rate=48000)
)

The active selected streams are H.264 video and AAC LC 5.1 audio. The audio transcode decision makes sense because the Roku profile appears to allow AAC only up to 2 channels.

A/B comparison: similar AAC 5.1 file works

I tested a second MP4 file that also has AAC 5.1 audio. Plex makes essentially the same decision for that file:



Scream 7 - audio.channels limitation applies: 6 > 2
MDE: Cannot direct stream audio stream due to profile or setting limitations
...
decision=transcode container=mpegts protocol=hls
streams=(
  Video=(decision=copy width=1920 height=800)
  Audio=(decision=transcode encoder=eac3_eae channels=6 rate=48000)
)

That working file reaches playback successfully; the log shows the Roku session becoming active/playing and then the session being terminated because the client stopped playback.

So this does not appear to be “AAC 5.1 always fails on Roku.” Both files trigger the same AAC 5.1 → EAC3 audio-transcode path. One starts; the other remains stuck at 0:00 buffering.

Local ffmpeg tests

I then tested the failing file outside Plex:

  1. Remux only, no re-encode: failed on Roku via Plex


ffmpeg -i "Hoppers (2026).mp4" -map 0 -c copy -movflags +faststart "Hoppers_remux_test.mp4"
  1. Short Roku-safe re-encode: worked on Roku via Plex


ffmpeg -ss 00:05:00 -i "Hoppers (2026).mp4" -t 180 \
  -c:v libx264 -profile:v high -level 4.1 -pix_fmt yuv420p -r 24000/1001 \
  -c:a ac3 -b:a 640k \
  "Hoppers_roku_test.mp4"

Because remux-only still fails but re-encoding works, this looks more like a Roku compatibility issue with the original H.264 bitstream, or Plex making an overly permissive Video=copy decision for this Roku/HLS path.

Visible media differences from logs / ffmpeg

Failing file:



Video: H.264 High, yuv420p, 1920x1040, 24 fps, ~2249 kb/s
Audio: AAC LC, 5.1, 48 kHz, 384 kb/s

Working file:



Video copied by Plex, width=1920 height=800
Audio transcoded AAC 5.1 → EAC3 5.1

The biggest visible difference is not the audio path; it is the video stream characteristics. The failing file is 1920x1040 at exact 24.000 fps, while the working file is 1920x800 and appears to survive the same HLS video-copy/audio-transcode path.

Question for Plex devs

Is this expected behavior for Roku Ultra / Roku-7.x, or should Plex be forcing a video transcode for certain H.264 streams when using HLS/MPEG-TS on Roku?

From the logs, Plex believes the video can be copied, but the Roku never starts playback. Re-encoding the video with libx264 makes the same content play, while remuxing does not. That suggests the issue is probably not AAC 5.1 alone and probably not the MP4 container alone, but the copied H.264 stream being accepted by the decision engine and rejected/stalled by the Roku playback path.