2ka I've been out of town all week and got in yesterday...I took another look and I think I just forgot to turn direct play on after removing the elements. So, I have a new situation...I have the 4K version of the movie, 1917. There were NO elements to remove and wen trying to play in direct play, it said "No Audio detected" and asks if I'd like to change it back to "auto" and try again. Of course, if I say No, the picture is great but without audio. 🤣 I'm about to rip these new Roku's out and drop kick them across the street!
jtodd76and others,
I hope the following explanation will help a bit.
The red distortion will happen *whenever* HEVC-encoded video that uses the BT.709 colorspace is played from an MKV container that has (optional) color information in the header on a newer model Roku (that is, any model that has the video upscaler feature). Unfortunately, this container type (MKV with color info) is exactly the one the Plex server uses whenever it transcodes or Direct Streams. That is what makes the behavior harder to understand.
The problem will not happen if:
- the content is Direct Played from an MP4 container, or
- the content is Direct Played from an MKV container that has had the color info removed, or
- The video is transcoded for any reason. Plex server will transcode the video to burnin subtitles or to reduce bandwidth. But Plex always transcodes video using the H.248 encoder at 1080P or lower. This means the red problem disappears on transcodes, but so does 4K resolution.
The problem will happen if:
- The content is Direct Streamed, even if the original was in an MP4 container. This is because Plex Server uses MKV containers (with color info) when remultiplexing for Direct Streaming.
- The content contains only incompatible audio tracks, such as AAC surround sound. In this case Plex Server will transcode the audio to a compatible format, and then remux the whole into a new MKV container (with a color header), thus triggering the bug. The AAC stutter workaround also triggers the bug by forcing remultiplexing.
If your force Direct Play on an MP4 file that contains incompatible audio, the red problem will disappear, but so will the sound. Ditto for an MKV file with the color info removed. You can't Direct Play what can't be directly played, if you follow my meaning.
In order to workaround the problem, you first have to ensure the file contains audio that is compatible with Roku and your playback environment. Otherwise Plex will transcode the audio and remultiplex into an MKV container. AC3 is the most broadly compatible format. If the original audio is incompatible, you have to pre-transcode the audio track yourself using a tool like ffmpeg. You then have to either mux the content into an MP4 container or use an MKV container and then use a utility like MKVToolNix to remove the color info. Finally, you have to make sure the your player is set up to Direct Play the file.
The workaround, as you see, is pretty complex. That is why so many people struggle with it. You have to get it right, or the red problem persists.
I totally get why it's happening based on reading through the forums over the past few weeks...but the bigger question is: Do you think they will EVER fix it? Or are we just going to have to adjust our media so that it won't show red? It's really ridiculous.
I hope not! I have been grappling with this issue for weeks now and I can't seem to find a reasonable way to address my library of hundreds of affected files. I'm giving up.
The way I dealt with this was to create a batch file (.bat file) that takes all the .mp4 files in a directory (i.e., in whatever directory the batch file is running). It will then convert the audio to a compatible format for the Roku and Plex (EAC3) and then re-containerize the new MP4 into an MKV file. This ensures a compatible file that does not have any color issues. You need ffmpeg and mkvmerge in your path (i.e., findable by the batch file). These are free utilities you can download.
It will also put the original mp4 file into a backup directory (I did this when initially testing it, but have never had an issue with the new mkv file). The backup directory will need to be changed (C:\Users\myName\Desktop\BACKUP).
If you do this on an SSD drive you can probably do a 2 hour movie file in about 1 minute and it will run on all mp4 files in the directory so you can do many files at once (just be aware that every file generates 2x more space: the original mp4 which is put in a backup directory, the new mp4 which is put in the recycle bin, and the final mkv). You can of course modify this to suit your needs.
Here is the batch file (put into a text file and rename it to .bat):
FOR /F "tokens=*" %%G IN ('dir /b *.mp4') DO ffmpeg -i "%%G" -c:a eac3 -b:a 256k -c:v copy "%%~nG_2.mp4"
FOR /F "tokens=*" %%G IN ('dir /b *_2.mp4') DO mkvmerge --ui-language en --priority lowest --output ^"%%~nG.mkv^" --language 0:und --language 1:en ^"^(^" ^"%%G^" ^"^)^" --track-order 0:0,0:1
del *_2.mp4
move *.mp4 C:\Users\myName\Desktop\BACKUP
setlocal ENABLEEXTENSIONS ENABLEDELAYEDEXPANSION
FOR /F "tokens=*" %%G IN ('dir /b *.mkv') DO (
echo.%%G
set filename=%%~nG
echo.!filename!
set filename2=!filename:~0,-2!
echo.!filename2!
ren "%%G" "!filename2!.mkv"
)
