Same resource runaway/crash behavior but on a different PC

[darkquark]

Server Version#: 1.41.0.8911
Player Version#: Roku Latest

I had this issue and posted about it a few weeks ago. I ended up rebuilding Plex from scratch. I did not even pull over settings, cache or DB. And I put it on a different PC with different hardware and this moved me from Intel to AMD. My NIC, GPU and tuner card did move to the new PC.

But I am back in the same boat. I just kicked on a movie and my NIC usage maxes out and my memory usage creeps up and within 30secs the PC runs out of memory and crashes in one form or another.

Given almost everything is different and I rebuilt from scratch I have no idea what this could be outside of a niche Plex issue.

I am using a NAS in this case so media is being pulled from that over the NIC and clearly that is somehow related given the NIC hitting about 1GB. Which I do find interesting because this is a 2.5GB NIC and it does indeed move data at 2.5GB. I can copy the file from the NAS I would be playing in Plex and the NAS will serve it up to me raw at about 1.6gbs. But if I play that same file in Plex the NIC jumps to 1gb or a little less and hangs there while the RAM drains and my CPU spikes and stays high (but at like 50% or so).

I mention this because this leads me to believe that Plex is doing something to the data transmission from the NAS. Is it trying to throttle it as if it thinking this is a remote connection it needs to handle for the sake of bandwidth? If it is I could see it running itself nuts with a data rate that high and essentially blowing itself up trying.

Outside of that I don’t know what else to do.
Plex Media Server Logs_2024-08-25_12-37-37.zip (271.6 KB)

[BanzaiInstitute]

To make sure it is related to the network, you could make a new library that is on the server’s own hard drive. Put the same movie file in there. If it plays without crashing then it seems like you have demonstrated a networking bug.

[darkquark]

Would you believe me if I told you I thought about doing that before I posted but forgot? Regardless, awesome idea so thank you.

Trying that now.

[darkquark]

So this just got even weirder.

I ran the same file from C drive as you suggested. The same behavior occurred. But look at the screenshot. The Plex dashboard shows that about 1gb of traffic is being moved. Well, this is coming from the C drive and if you look to the right my NIC is doing almost zero. Yet memory and CPU still goes nuts and all the free mem drains until the box crashes.

Where you see the bandwidth trail off in the dashboard is when it crapped out.

[BanzaiInstitute]

Does it happen for every kind of file?

[darkquark]

On the previous machine yes. I only have MP4s and MKVs. In this instance this is a 4K/HDR MKV. So the file is large. The video is NOT being transcoded but the audio is. Now I have seen this happen whether things were being transcoded or not.

The fact the dashboard shows its moving 1GB of traffic when it clearly is not is super weird in my opinion. It seems as if data is being passed through some function of Plex mistakenly.

[FordGuy61]

Please re-enable debug logging in Plex Media Server (default level). Do not enable verbose logging.
Info level logs rarely contain enough information. Verbose level logs usually contain too much information.
Settings → Server_Name → General + Show Advanced.

Media streaming steady state at very high bitrates can indicate the container is damaged or the audio & video tracks are poorly interleaved. Remuxing will copy the tracks into a new container and interleave them correctly.

Try remuxing the file with MKVToolNix or similar tools.

It will copy the tracks to a new file, correctly interleaving the tracks in a new container.

MKVToolNix can read MKVs & MP4s. It saves files as MKVs.
XMedia Recode can read/write both MP4 & MKV. Be sure to copy, not convert (transcode), the tracks.
Subler is a nice Mac based tool. It can read MKV & MP4 and save as MP4.

If you prefer ffmpeg & cli:

ffmpeg -i input.mkv -map 0 -c copy output.mkv

ffmpeg -i input.mp4 -map 0 -c copy -movflags +faststart output.mp4

If the output is a mp4, movflags & faststart will rearrange some bits to make streaming start faster.

The input and output containers can be different (mkv to mp4, etc.).

[darkquark]

I will retest with the logs enabled, my mistake I forgot to turn that on since I rebuilt.
However, I really don’t want to remux, I have a ton of files and they are all are from just the same few sources. None of of them have ever been an issue for years until the last couple months. This file I am testing with now is from a disc I own and it is not transcoded, so it’s a lossless rip (MKV container).

For the record this file is 50GB. But on my prior plex box where this started small MP4s of 10GB or less would cause the exact same behavior.

Will retest shortly with logging on. Thanks.

[darkquark]

Logs with debug (but not verbose). I stopped the playback once the video quit playing.

Plex Media Server Logs_2024-08-25_20-01-49.zip (614.0 KB)

[darkquark]

I am going to try to run some smaller files today and see how they go. I had before and they were fine. In the previous iteration of my Plex server ANY file would do this.

[OttoKerner]

That issue looks like this one: High Bandwidth via Direct Play on Windows 10 - #4 by OttoKerner

[darkquark]

OK, so based on that thread I performed additional testing. This is a Plex problem it seems but it’s not the server I assume, it’s the Roku Plex Client.

The 2 test files, even the giant 4k one plays perfectly fine in a web browser. There is the initial short burst of network traffic and then it calms down.

From my Roku Plex client is where this is an issue regardless of what I play. All my files do it.

I also notice another difference. In the web browser the audio is of course transcoded but on the Roku in question it is not and it technically should be because it’s just stereo. This is a recent change in behavior I noticed that coincided with this problem. I noticed it because the audio was far louder all of a sudden on day (maybe 4 to 6 weeks ago).

[OttoKerner]

Look at the Dashboard in the web app during playback.
You might see that playback in the web app is Direct Stream or Transcoded, while Playback on the Roku is Direct Play.
If this is the case, it kinda confirms my suspicion that the source file is poorly muxed.

[darkquark]

I addressed that one I think. The video is direct stream in both cases. In the case of the Roku Plex client it is not transcoding the audio (which it always used to and should be) and in the web it is transcoding the sound (which is typical).

I don’t know what is considered poorly muxed or well muxed but I have thousands of files that played fine for years that are now causing this. As I demonstrated this is the issue only on the Roku Plex app. So muxed well or not the issue appears to be with the Roku Plex app.

Ironically, the sound in the Roku Plex App is much better without the transcode. Prior, anything in 264 sounded fine and in 265 it’s comes out very low. Not a huge deal to just turn up the volume, just something I noticed.

[darkquark]

I would like to reiterate that in my view, there is nothing wrong with the server. It seems to be the Roku Plex App that is the issue. I believe this because nothing changed behavior except that app.

[FordGuy61]

@darkquark

What’s the Plex app version number on your Roku? It should be displayed in Authorized Devices.

Please replay the same video, but first choose the AC3 audio instead of the DTS audio track.

That should direct play. In the session captured in the logs you attached, DTS audio was selected and was transcoding.

Do you still see the very high, steady state bandwidth in the Plex Dashboard?

Let it play for about a minute, then pull the log files.

Something is up, but I’m not sure what.

Your log files are full of transcoder range entries.
Aug 25, 2024 20:00:40.703 [16628] DEBUG - [Req#1d86e/Transcode/ee847d47-f941-4dbd-96a9-1cd19a65362b-25/6796cad9-4600-4222-918e-e7ff20e6eda4] Transcoder segment range: 0 - 1369 (1368)

With the high bandwidth, it can be an indicator of a poorly muxed file.

I tried to replicate the problem on my servers, but cannot.

Using a Roku Streaming Stick 4K w/ Plex app v7.24.8, I played the 60fps, 4K HDR version of Gemini Man, which runs at ~100 Mbps. I played the movie for 5 - 10 minutes multiple times and never had any crashes, buffering, etc.

I see an initial bandwidth spike (~1 sec.) when Plex fills the client buffer, but it quickly settles down to roughly 100 Mbps. It does not matter if I choose the TrueHD track, which transcodes, or the AC3 track, which direct plays.

I also see Transcoder Segment Range log entries, but only when the audio is transcoding.

I’m wondering if it makes a difference on your system if the audio is transcoding.

Here’s the bandwidth graphs from my server when playing Gemini Man. They both quickly settle down to the overall bitrate of the movie, ~100 Mbps.

Bandwidth Graph with TrueHD audio (transcoding):

Bandwidth Graph with AC3 audio (direct play).

[darkquark]

Here is my plex app version → 7.24.8.9449-c3a6c8a43-Plex

Now here is the thing. You say in my logs it shows transcoding. I find this interesting because the Plex dashboard is showing direct play for video AND audio. This is why I kept mentioning that was a change in behavior. It should show transcoding to AAC stereo as it always has but it is not. However, I have tried this on multiple Rokus and I get the same behavior including the one with a receiver on it that the audio is on passthrough.

Let me try that different stream and report back.

[darkquark]

Here are 3 pics.

1. I simply hit resume (now this time its shows transcode)
2. I let it play until the session crashes/stops
3. I selected the AC3 audio (happened to be the descriptive audio)

I know folks keep mentioning poorly muxed files. Let’s assume my thousands of files were muxed with a rusty cheese grader. I have played these files for several years without issue. So bad mux or not something is not performing as it typically has.

[darkquark]

@FordGuy61
@OttoKerner

I picked another file and tested it on the Plex Android client, web and Roku client. The runaway behavior occurred on the Android and Roku Plex apps but not in the web browser.

EDIT- I also checked it in the Windows Plex app, it’s normal there as well.

Thanks.

[darkquark]

Well this sucks. Plex is essentially useless to me in this state. I will have to use Jellyfin for now to watch my stuff. Hopefully this gets solved at some point. Thanks for the responses.