Server Version#: 1.30.0.6486
Player Version#: 5.51.1
Platform Version#: 5.5
Where should I report this issue, where the report is not closed after 90 days? Was reported over a year ago, it is still not fixed.
Bump.
I really hoped, that “(Transcoder) Decoding certain TrueHD audio streams could fail (#14023)” was a fix for this issue. It is not.
Same issue for months, don’t know why. If it Directs Stream for any reason and you select a subtitle, it will start to stutter and buffer until it crashes or exists the episode (happens when the mkv file has more than 30 tracks which forces it to direct stream). This should be solved.
The 30 track limit is a Samsung limit. Use MKVToolNix or similar tools to remove unnecessary audio and subtitle tracks.
With some Plex Smart TV apps, if the media is direct streaming, such as when audio is transcoding, and you enable any subtitle, it results in a video transcode.
If your server cannot transcode the video in real time, you will experience buffering.
You can monitor playback via Plex Dashboard → Now Playing, the Plex Dash mobile app, or Tautulli to see if Plex is transcoding the video.
The root cause is due to limitations in the HLS streaming protocol used between the server and client. Plex has to burn the subtitles into the video stream, otherwise they would become out of sync with the video and audio.
LG, Samsung, and probably other SmartTVs are affected.
Use MKVToolNix or similar tools to remove unnecessary audio and subtitle tracks.
I’m aware of that, I was giving an example to confirm that it’s because of Direct Streaming.
…and you enable any subtitle, it results in a video transcode.
If your server cannot transcode the video in real time, you will experience buffering.
When that happens (audio transcoding so it directs stream), the video never automatically transcodes, it gets streamed as-is to my TV. But also why should the video be ever transcoded just because of of the audio, it’s really an annoying bug. The server can trasncode 4K HDR and is connected directly to ethernet, so the buffering is definitely not a server/client connection or hardware power issue.
As for the re-encode the audio to AAC suggestion (or any modifications to the mkv), I can’t always do that, bluray movie sizes are huge and take a while to be written (upwards of an hour), so that’s not a viable option at all to be done frequently (as lossless audio tracks also need transcoding). And I can’t always just do that, I go remote a lot.
The root cause is due to limitations in the HLS streaming protocol used between the server and client. Plex has to burn the subtitles into the video stream, otherwise they would become out of sync with the video and audio.
That’s a shame, I don’t know much about HLS and streaming protocols, but this wasn’t an issue a while ago so I wonder. I hope this gets some focus from the team at least.
Correct. Transcoding audio is OK. Transcoded audio + subtitles is what causes the video transcode.
Maybe from another thread? I did not suggest such.
FWIW, if you ever want to change just the audio, use XMedia Recode or ffmpeg. Do not use Handbrake.
XMedia Recode can be configured to copy the video track and transcode the audio (and keep original format if desired). Transcoding audio is very quick. You can do the same with ffmpeg if you like to use CLI vs GUI.
Don’t use Handbrake. It will always transcode video, which is very slow compared to transcoding audio.
Maybe from another thread?
Probably, I’ve been digging for info about this a lot and I think some suggested that.
FWIW, if you ever want to change just the audio, use XMedia Recode or ffmpeg
Yes, that’s what I use. Specifically, an ffmpeg command that inserts an AAC track as the first, from the original lossless track. But what I mean, is that re-muxing still takes a while, the sizes are upwards of 60GB for movies, writing that much takes a bit of time with my HDD. This issue is huge with the shows that I own 4k blurays of, mostly HBO but a single episode is like 24gb. So you can imagine how long it would take just because Plex can’t transcode the audio on this client.
This is also an issue if I’m tight on storage space, as that means I need double the space between muxing & removing the old file.
I tested it today, and had no freezing. It may have been fixed.
Nevermind, buffering after 46 minutes… Almost made it to the end, 47 minutes and some…
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
