Pixelated/Blurry/Discolored Playback on Roku when Transcoding

[Xalactic 6]

Saw the 4.8.10 update with the hardware transcoding fix note and thought it might address this, but I'm still having the same issue. This is happening on pretty much any transcoded movie I watch, but I'll mention again that it's really only during dark scenes.

I really hope this gets addressed at some point. Some of these bug reports do seem to grow stale... Please let me know if I can provide additional information or test anything.

[Luke 42077]

Hi, we are looking into this. Thanks.

[Xalactic 6]

This is still an issue... Running 4.9.1.7 beta at the moment.

[Xalactic 6]

Is this just being ignored, or what? Still very much a noticeable issue during darker scenes. Don't want to come across as rude but this is getting frustrating.

[Luke 42077]

@Xalacticapologies for the delay. Since you've updated to 4.9, can you please provide a log example from that? Thanks !

[Xalactic 6]

On 9/7/2025 at 1:13 AM, Luke said:

@Xalacticapologies for the delay. Since you've updated to 4.9, can you please provide a log example from that? Thanks !

https://www.dropbox.com/scl/fo/fqh921rtwz0gfkfdqdeaw/AN5BOATUAQ8GeZ4YLUGO0og?rlkey=01h72ol5i0njpihv1rjj22fqr&st=w98y0e52&dl=0

Running 4.9.1.27

[Xalactic 6]

@LukeDoes that give you what you need? Any ETA or detail on when this will be fixed?

[Luke 42077]

Hi, we are working on it. Thanks.

[Xalactic 6]

Checking in again. On the latest beta after seeing the Intel driver and subtitle related fixes. Still having this issue. Any specific details or ETA at all? It's been over a year since this was reported.

[Xalactic 6]

This is ridiculous. Is this just going to be ignored and not fixed? It's been over a year and I've provided logs twice. This is a consistent playback issue with paid software. I guess I'm somehow the only one having this issue but it feels like I'm getting the runaround here.

[Luke 42077]

HI, apologies for the delay. We are looking into this.

[Luke 42077]

Have you tried setting your hardware transcoding on the server to vaapi rather than qsv?

[Xalactic 6]

59 minutes ago, Luke said:

Have you tried setting your hardware transcoding on the server to vaapi rather than qsv?

 

On 9/3/2024 at 4:26 PM, Xalactic said:

Yes, same exact issue with only VAAPI enabled.

I have tried it since then as well.

[Luke 42077]

On 11/11/2025 at 5:00 PM, Xalactic said:

 

I have tried it since then as well.

Can we please see a log example of that? Thanks.

[Xalactic 6]

On 11/17/2025 at 5:19 PM, Luke said:

Can we please see a log example of that? Thanks.

Here. The issue is still very much apparent. https://www.dropbox.com/scl/fo/d6h5vz4vltzf880lb7l8d/AMpcss4lNeNIzn40M_R3iM4?rlkey=eg8z1o8u93oxv0q2imdurbg4y&st=efy5swyx&dl=0

[Luke 42077]

OK we are looking into it. Thanks.

[Xalactic 6]

On 11/30/2025 at 4:55 PM, Luke said:

OK we are looking into it. Thanks.

Still an issue. I don't know if I'm somehow the only one experiencing this or what but it's incredibly frustrating to keep hearing that it's being looked into and nothing else. It's been over a year and I've provided logs across multiple versions. Please fix it or just say that it's not going to be fixed because this is ridiculous.

[Gilgamesh_48 1240]

3 minutes ago, Xalactic said:

Still an issue. I don't know if I'm somehow the only one experiencing this or what but it's incredibly frustrating to keep hearing that it's being looked into and nothing else. It's been over a year and I've provided logs across multiple versions. Please fix it or just say that it's not going to be fixed because this is ridiculous.

FWIW: I use a fairly under powered server and I have never seen the issue you describe. If I were troubleshooting your set up I would look at things like:
Are you using your server for other duties? That is usually a bad idea.
Is your server wireless? That is always a bad idea.
Is there wireless interference affecting your client(s)? That can cause all sorts of unusual problems as communication between client and server is very important.

Are the involved files very large or have high bit rates or high frame rates?

The fact that nobody else is seeing this issue pretty much says that it is something local to your setup. 
The one thing I can think of is that your server is simply under powered for the task(s) you are using it for but that is up to you unless it has lots of other duties. If it does then that needs to be reduced a lot or the "other" duties need to be switched to a different computer.

[Xalactic 6]

3 minutes ago, Gilgamesh_48 said:

FWIW: I use a fairly under powered server and I have never seen the issue you describe. If I were troubleshooting your set up I would look at things like:
Are you using your server for other duties? That is usually a bad idea.
Is your server wireless? That is always a bad idea.
Is there wireless interference affecting your client(s)? That can cause all sorts of unusual problems as communication between client and server is very important.

Are the involved files very large or have high bit rates or high frame rates?

The fact that nobody else is seeing this issue pretty much says that it is something local to your setup. 
The one thing I can think of is that your server is simply under powered for the task(s) you are using it for but that is up to you unless it has lots of other duties. If it does then that needs to be reduced a lot or the "other" duties need to be switched to a different computer.

I am using the server for other applications but it has resources to spare. Everything in this scenario is hardwired. I've seen this issue across DVD, Bluray, and UHD rips. Again, only on Roku clients. I'm open to this being a localized issue but I don't know how that would be the case.

 

[speechles 2055]

57 minutes ago, Xalactic said:

I am using the server for other applications but it has resources to spare. Everything in this scenario is hardwired. I've seen this issue across DVD, Bluray, and UHD rips. Again, only on Roku clients. I'm open to this being a localized issue but I don't know how that would be the case.

 

•  
• 21:55:25.995 Stream #0:0 (h264_qsv) -> hwdownload:default (graph 0)
• 21:55:25.996 Stream #0:3 (pgssub) -> scale:default (graph 0)
• 21:55:25.996 hwupload:default (graph 0) -> Stream #0:0 (h264_qsv)
• 21:55:25.996 Stream #0:1 -> #0:1 (dts (dca) -> ac3 (native))

 

If you disable burning in the pgssub and instead used external srt that would make the video stream able to be copied and direct played. Since it isn't copying the video stream this means it will use HLS. The audio stream is DTS is not supported in HLS. But if you weren't using those graphical pgssub, either no subtitles or external srt, it would've been direct playing and it could've then direct played the DTS audio too. The entire container would've been used with no HLS used at all.

 

You notice it in your example when the entire scene changes. The initial keyframe looks blocky/muddy. Cannot be easily fixed without a huge initial delay in transcoding. The method Emby is using for HLS has a much faster start time. Then it sorts itself out. This isn't unique to the Roku. Rather the Roku makes it noticeable this is happening. Any device that cannot burn in pgssub subtitles and needs to burn them into the video would cause the same thing. The video would get transcoded and the DTS audio would need to be converted since DTS isn't supported with HLS.

 

Edited January 26 by speechles

[Xalactic 6]

11 hours ago, speechles said:

•  
• 21:55:25.995 Stream #0:0 (h264_qsv) -> hwdownload:default (graph 0)
• 21:55:25.996 Stream #0:3 (pgssub) -> scale:default (graph 0)
• 21:55:25.996 hwupload:default (graph 0) -> Stream #0:0 (h264_qsv)
• 21:55:25.996 Stream #0:1 -> #0:1 (dts (dca) -> ac3 (native))

 

If you disable burning in the pgssub and instead used external srt that would make the video stream able to be copied and direct played. Since it isn't copying the video stream this means it will use HLS. The audio stream is DTS is not supported in HLS. But if you weren't using those graphical pgssub, either no subtitles or external srt, it would've been direct playing and it could've then direct played the DTS audio too. The entire container would've been used with no HLS used at all.

 

You notice it in your example when the entire scene changes. The initial keyframe looks blocky/muddy. Cannot be easily fixed without a huge initial delay in transcoding. The method Emby is using for HLS has a much faster start time. Then it sorts itself out. This isn't unique to the Roku. Rather the Roku makes it noticeable this is happening. Any device that cannot burn in pgssub subtitles and needs to burn them into the video would cause the same thing. The video would get transcoded and the DTS audio would need to be converted since DTS isn't supported with HLS.

 

Sure, using SRT does indeed get around the issue. Manually lowering the bitrate while using PGSSUB also gets around the issue as found previously. I'd like to not have to set the bitrate when using PGSSUB. I try to use SRT for most things but sometimes the automatically downloaded set is out of sync and I'm not near my computer to go find a different version when the movie starts. Sometimes SRTs don't get downloaded automatically and I have to do it manually. Sometimes the PGSSUB formatting is just nicer than SRT on Roku.

Based on all the previous log requests and "looking into it" responses, it sounded like there was some acknowledgement of this being a bug. Is the official answer now just "Don't use PGSSUB"? I'll have to go strip them out of every file and/or set up some automation to rename the downloaded SRT files as default since there's no option to name them as such automatically.