[BUG?] Very high Disk usage when using internal subtitles on Samsung

[davef_d]

Server Version#: 1.32.6.7557 (Synology)
Player Version#: 5.70.0 (Samsung QN95B 2022 TV)

Short version - Extremely high disk usage on my server when a file is played with text based Internal subtitles enabled. This happens with files that are Direct Play compatible. 120-150MB/s reads which depending on the server load and the file’s bitrate can and has resulted in buffering and playback failure.

Long version…

I’ve noticed that when playing any MKV file with internal subs enabled there is extremely high disk usage on my server.

My server has multiple drives but they’re all setup as separate basic volumes, so only 1 drive is being used to playback a file. In my testing I’ve ensured no one else was using the server, so the drive activity charts I’ve included below show the activity PLEX is generating on a single drive.

I first discovered this when I had buffering issues which resulted in failed playback with a 4K 20GB file. I found it odd as I’d watched numerous similar size files before with no issue, and I always make sure my files are direct play as I don’t allow video transcoding and try to avoid audio transcodes. After a lot of testing I found the difference was the forced internal subtitles.

Once I disabled those, the file played normally with very low disk usage. I then extracted the subtitles and used them as an External SRT and again, perfectly normal playback.

I’ve also found that if a transcode is taking place, or if you force Direct Stream, then disk activity is normal. So this seems to be a Direct Play issue.

In my testing I’ve since found this happens with ALL MKV files with internal subs. But the severity of the problem varies based on the file size and bitrate of the opening minutes.

What seems to happen is there is an intense period of disk reads when you start playing a file with internal subs enabled. A 3GB file will fall to normal disk reads after around 30 seconds, a 10GB file in 90 seconds, and a 20GB file in around 3-minutes. It’s almost like Plex is extracting the subtitles from the MKV while also playing the video - a process that is of course completed faster on smaller files. A process that - even on larger files - may pass unnoticed if the first few minutes are low bitrate and your system can handle the load. But on larger files with high bitrate openings the disk drive may struggle to keep up. Network usage during this period is completely normal. CPU usage is high.

The behaviour I’m seeing occurs on both my Samsung TV (2022 model) and Xbox using the latest player versions. Probably not surprising when comparing the release notes as they seem to be very similar.

PC and Amazon Fire Stick Plex players do not have this issue in my testing.

I’ve used 4 files for testing purposes to create the supplied logs with my Samsung TV - testing them over standard DLNA and through PLEX…

4K Source 20GB 115min (HEVC, EAC3, with forced internal SRT subtitles)
The first few mins have high constant bitrate of 20-40Mb/s
DLNA: Plays as you would expect. Normal Disk usage.
PLEX: Plays via Direct Play as expected. HIGH hard drive usage for just under 3-minutes, 120MB/s average, spiking to 150MB/s. After 3-minutes it settles down to normal usage.

4K Sample 10GB 57min with forced internal subtitles
I split the 20GB file in two.
DLNA: Normal.
PLEX: Direct Play. High disk usage, 120-150MB/s but this time the drive usage settles down after around 1min 20secs.

1080p Source 9.5GB 115min (x264, AC3 with internal subs)
The first few mins have high constant bitrate of 20-30Mb/s
DLNA: Normal.
PLEX: Direct Play. High disk usage, 120-150MB/s with a similar 1min 25sec time for the drive usage to settle.

1080P Source 2.8GB 46min (x264, EAC3 with internal subs)
Your standard good quality 1080P WEB-DL TV episode. 10-20Mb/s spikes but usually around 8-10Mb/s.
DLNA: Normal.
PLEX: Direct Play. High disk usage, 120-150MB/s but just 30secs or so for drive usage to settle.

Both the 4K 20GB Source and 1080P 9.5GB source files have buffered and failed playback on me. However - when I was testing to generate the supplied logs - playback was uninterrupted.

Disabling internal subs results in normal disk usage.
Using external subs also results in normal disk usage.

In the supplied logs I do the following in order:

Play “4K Source 20GB 115min” with internal subs for a little over 3mins (when the drive activity calms down).

Play “4K Source 20GB 115min” with external subs for about 1min 30secs.

Play “4K Sample 10GB 57min” with internal subs for a couple of mins.

Play “1080P Source 9.5GB 115min” with internal subs for a couple of mins.

Play “1080P Source 2.8GB 46mins” with internal subs for about 1min.

I’ve edited some identifying info out of the logs.

Plex Media Server Logs_2023-10-19_23-44-06.zip (222.0 KB)
XML for test files.zip (6.5 KB)

[davef_d]

I recently learned that PGS subtitles are now supported by Plex for Samsung (previously it would try to burn them causing a video transcode).

I’ve tested them and see the same problem when content is Direct Played, though the disk transfer graph is a little more peaky.

No logs unless anyone from Plex bothers to ask for them, but some images…

This is a 6.4GB file and the transfer rate settles down after around 100 seconds. So like the SRT subs the length of the extreme disk usage is related to the size of the file.

PGS subs have their own issue though. Anytime where there are overlapping lines the subtitles break and stop displaying. e.g. at around 23mins 25secs there’s a background announcement subtitle on the bottom of the screen that stays there for about 7-8 seconds, and during that time there are dialogue subtitles that should display above that line. Once that happens the PGS subs break and stop displaying. That’s for another thread though (and tbh I probably won’t bother, too much effort for no response).

[davef_d]

This has been an issue for a long time I think.

Using SRT subtitles inside the .mkv container causes 100% disk usage, while SRT subs downloaded inside the WebOS Plex app work fine

Platform Version#:5.1.1 Client Version#:5.5.1 LG CX The video and audio can be direct played, since both can be decoded by the TV (4k hvec 10 bit with HDR and ac3). If the played .mkv container has internal subs, and the internal subs are selected, it triggers the transcoder to kick in and it uses 100% of the HDD, causing buffering. The subtitles are SRT. The funny thing is that the player still says the movie is direct played, WITHOUT transcoding. Subtitles AREN’T burned, that option is sele…

[davef_d]

I know I’m just talking to myself here, but some extra random mumblings…

I know it’s different, but I was looking at the Emby forums and saw some talk that backed up my theory of the subtitles being extracted from the MKV.

I’ve installed Emby server and done some basic testing using the same files, and I see the same results.

Emby specifically has an option in their transcoding settings for subtitles:

With that enabled (which is the default setting) I see the exact same behaviour with extremely high disk usage which settles after a varying amount of time (in line with my results in the first post).

Checking the logs you can see the ffmpeg operation they use to extract the subs, and you can even find the extracted file in the cache.

If I change the Emby Samsung app’s Subtitle setting from “Default” to “No subtitle” (the wording is strange, but it seems to translate as changing it from “default based on language/mkv settings” to “let the user choose”) then I see this:

Which seems to be some direct stream/direct play hybrid with normal disk usage.

If I disable the extract setting on the server, then the files simply don’t play (just a constant loading screen).

It’d be nice to get some clarity from someone at Plex over this. Are you extracting subs? Why?

If its a necessity it’d be nice to have an option to optimize the library by doing it when adding files, making it a one-time operation instead of everytime the file is played.

On a different note, unlike Plex, Emby does the following without problem on a Samsung TV:

Direct Plays a file with >30 streams (Plex forces Direct Stream with audio transcode)
Direct Plays when you choose a secondary audio track (Plex transcodes the audio)
Plays subtitles fully (Plex skips the last line → Last line of subtitles is not displayed when using Plex on Samsung TV)

[Retalak]

I am having the exact same issue with an mkv direct streaming subtitles to my Samsung smart TV. I also see the audio being transcoded with that same message regarding 30 streams. I have to force burning in order to resolve the issue. Also it oddly always seems to buffer at certain parts of the show/movie.

[davef_d]

Keeping this alive with some logs from the latest public Plex server release and the latest Plex Samsung app.

Server Version#: v1.40.0.7998 (Synology)
Player Version#: 5.77.1 (Samsung QN95B 2022 TV)

Still seeing the same issue. The only real change I’ve noticed over the past month is that the Plex Dashboard now shows what stream type it’s using for subtitles (previously it didn’t). It starts out by reporting Direct Play, but this quickly changes to Direct Stream.

Examples below using GIFs:

In the new logs (fresh logs, some identifying info removed) I do the following:

23:37 - Play 4K Source 20GB 115min using the internal forced subs for approx 4mins which is how long it takes for the drive activity to go back to normal.

23:44 - Play the same file using an external srt file for a few mins.

In-between I started/stopped the same file a few times to capture the GIFs you see above.

As noted in my first post this affects all MKV files with internal subtitles. I strongly suspect this causes/contributes to buffering issues, particularly in cases where multiple users are streaming at once.

Plex Media Server Logs_2024-02-27_23-51-05.zip (118.7 KB)

[davef_d]

Keep alive post. Still occurs as of the latest server and app versions.

The only new thing to add is that I tried the new ‘Force Direct Play’ option but this only seems to impact video and audio. The subtitles still Direct Stream as noted in my last update.