Plex Media Server process uses 100% cpu (SRT->ASS Conversion)

Thanks for that kick in the teeth. Not my fault but I still take the hit.

Duly noted.

You take the hit for how you treated your paying users. Not believing them, ignoring the numerous posts telling you it’s not a Docker issue, derailing the thread by blaming Docker, eventually lying about the fact that you contacted the engineering team but then saying you needed more info in order to do so months later…

The dev team takes the hit for still having this outstanding unresolved issue for months now. Since we have no visibility on the roadmap, there’s no way to even know if they are aware of the issue and/or if they plan to address it some day.

So yeah, hits for everyone it seems.

Did you not read above where I found it or are you too focused on Docker and perceived bias? (July 27 post)

I posted my results. Although I can’t reproduce reliably 100% of the time, I submitted it to Engineering.

I even spoke with the transcoder engineers who confirmed there is an inefficiency in the conversion which can account for what is being seen.

Since this apparently means nothing, I withdraw from the thread.

I’m on Windows 10, I updated the server from 1.14.1.5488 again to check it out and it still doesn’t work, going back to 1.14.1.5488.

Hey guys, I have read through this thread, and raised a new issue with our engineering team to resolve :slight_smile:

Awesome!
Thank you so much @chrisallen !

Finally an employee at Plex Inc that can do something useful. And it only took a few hours. Thanks wingman!

We’ve found the issue, and fixed it; will make it into the next release (or the one thereafter, depending on timing).

Thanks for the ping, it helped move this along!

Finally, thanks @elan and @chrisallen!

There are some learnings that can be taken out of this thread, I hope they will be useful for the future of Plex’ customer service :slight_smile:

Awesome news @elan, thank you!

Yes, I fully agree.

Thanks @elan for the update!

And all the guys posted, I just want to say something here. @ChuckPA has always been one of the most active Plex reps here.

We’ve all been waiting and been frustrated about the bug here. I myself have tested this several times using different methods (excluding docker, but windows and Linux). The bug would rarely appear on a fresh install (including fresh OS install from format) of any of these tested OS, and would occur once you settle in for few days and update its versions, that’s why some people do not have the bug yet.

I have done the tests with another Plex employee on my own posts (did not want to include his/her name here), and it took several tries after several days for the bug to be shown/occur. That bug was really buggy in its own way ;p

What I’m trying to say is that it was frustrating and easy to blame it on another, he was trying his best and was very much active to both our positive and negative replies and I want to really thank him for replying to us on every post from every person here, he did not ignore it and leave for someone else to pick it and I appreciate taking his time to reply to everyone.

His updates and replies were more than enough for us to feel at ease that at least our message went across to the engineers. Whether or not it got fixed I understand that it wasn’t in his hands to actually fix it but to acknowledge it. His replies were only human.

I would like to voice my opinion here and say I appreciate his time and he actually replied to me from other threads and asked every little detail on how to re produce the bug, he was very thorough with me. (you can checkout my posts from other threads related to the same problem and his replies)

Thanks again @ChuckPA and I really hope you don’t take anything personal here as its hard to please but easily blamed.

You guys had good reasons to be frustrated, I’m not against anyone’s reaction as I am too was frustrated and it hindered my experience, but please do understand his position. I do not think he was out of bounds here. Hey, we’re all on the same team in the end :innocent:

Edit: formatting and spelling mistakes.

No, he really wasn’t. Look at the kinds of responses we got over months and excuses like how he couldn’t do anything about this. Then elan and wingman step in and it gets resolved in a day.

Not trying to crap all over the guy, but the level of customer support we got here was some of the worst I’ve seen. And I’m sure elan doesn’t want this to be the standard that Plex Inc upholds in the future.

Anyway, let’s put this discussion to bed. The issue is going to get taken care of now. I’m tired of getting email notifications for pointless drama. The next notification we all get should be the one that says this issue is finally resolved.

Just chiming in to confirm the SRT->ASS CPU issue still exists in the recently released Version 1.16.5.1554 - if you rolled back to a previous version, don’t update yet.

Something I’ve noticed is that my 8i5 is 100% for a good 15mins when someone starts a movie requiring subtitle conversion but eventually calms down when the stream gets “throttled”. It seems the cpu is doing an abnormally large amount of work to convert sub formats.
Edit: spoke too soon, locked at 100% whenever user is playing video.

And finally… it’s fixed :smiley: (1.17.0.1709)
Thanks to everyone involved fixing this annoying issue !

Finally wouhouuuuuuuu :tada::tada::tada::tada::tada::tada::tada::tada::tada::tada:
I confirm it works here also (with docker) using 1.17.0.1709 :stuck_out_tongue_closed_eyes:

Thank you!!

Is there a way to update from 1.16.6.1592 to 1.17.0.1709 without having to reinstall the server then reload my media database? The “Check for Updates” only shows 1.16.6.1592 in the web browser then says its up to date.

PS: TYSM for this post. My wife would start streaming in the living room while I am playing a game, and the game goes from 165FPS to 8FPS with the CPU usage spiking to 100% as soon as she starts the stream, making it completely unplayable, on a high end machine.

And you have selected beta in the update settings?

PS At the bottom.