I’m entirely unable to figure out why this server is serving video up so slowly. It was working fine up until a few weeks ago when its ability to transcode video seems to have gone down the tube. I’ve tried rolling versions back to no avail so I don’t think it’s got to do with that.
What’s basically happening is that anytime I attempt to play a movie it sits and spins, serving up a few frames every few minutes. I’ve been running Plex on this server for years with absolutely zero problems or complaints to speak of. Not really sure what’s going on.
I know the hardware is a bit old, but as I said above - it’s worked without issue for years. The only recent “big” change to speak of was a recent upgrade to Ubuntu 18.04 from 16.04 after several older disks died and I picked up some new ones. However, after the upgrade the server ran fine, serving up video with no problems from April/May until probably the last couple months.
That’s what my thought was going into this post, but wanted to be sure. I’ve picked up an AMD FX-8120 and plan on rebuilding this week sometime. Hopefully this new processor does the trick, it’s benchmark is definitely better.
Should that $100 CPU and Mobo not do the job, please remember that we did advise you and offered a solution which would last for 3-5 years into the future at minimum but, you’re right, the final choice is yours to make.
Best of luck.
FYI: You will likely be surprised how many people buy Ryzen and Xeon processors for their media servers. How silly is it to have an i7-7700 CPU in his NAS ?? I do and it wears a lot of hats in a very small footprint.
I tried to optimize the database via the UI, I tried with the shell. My old 8 cores server was running much more smoother. The current log should show a remote play from chrome.
If you could help me, that would be much appreciated. Also, if you need more info, just tell me
I recreated the problem. The zip is as is. I took from the troubleshooting page. Sometimes the transcoder goes really fast and sometimes like in this case, the transcoder speed does not go higher than 0.6. So after 2-3 minutes, the movie start buffering.
Sep 24, 2019 16:48:48.706 [0x7f6fbaffd700] DEBUG - Scaled up video bitrate to 4653Kbps based on 4.500000x fudge factor.
Sep 24, 2019 16:48:48.707 [0x7f6fbaffd700] DEBUG - MDE: Selected protocol dash; container: mp4
Sep 24, 2019 16:48:48.707 [0x7f6fbaffd700] DEBUG - MDE: analyzing media item 395047
Sep 24, 2019 16:48:48.707 [0x7f6fbaffd700] DEBUG - MDE: E14 - Woodland Critter Christmas: Direct Play is disabled
Sep 24, 2019 16:48:48.707 [0x7f6fbaffd700] DEBUG - MDE: E14 - Woodland Critter Christmas: media must be transcoded in order to use the dash protocol
Sep 24, 2019 16:48:48.707 [0x7f6fbaffd700] DEBUG - MDE: E14 - Woodland Critter Christmas: no direct play video profile exists for http/mkv/hevc
Sep 24, 2019 16:48:48.707 [0x7f6fbaffd700] DEBUG - MDE: E14 - Woodland Critter Christmas: no direct play video profile exists for http/mkv/hevc/ac3
Sep 24, 2019 16:48:48.707 [0x7f6fbaffd700] DEBUG - MDE: E14 - Woodland Critter Christmas: no direct play video profile exists for http/mkv/hevc/ac3
Sep 24, 2019 16:48:48.708 [0x7f6fbaffd700] DEBUG - MDE: E14 - Woodland Critter Christmas: no remuxable profile found, so video stream will be transcoded
It is going to transcode HEVC. There is no hardware assist,
It does have 13,000 total passmark if all the cores were used (which they won’t be). It must also perform Subtitle burning. (Web player does not support subtitles without burning – French selected)
Ubuntu is on a Vmware VM on a ESXI host. The vm currently have all the 32 cores. So youre saying even though I gave it 32 cores, it will never use all of them ?
That’s correct. On a single transcode, it will never use all 32. Transcoding in software is not a massively parallel operation like it is within a hardware GPU.
You’ll have: about 4 for the video, 2 for the audio, and another single thread (known bottleneck point) for subtitle burning. This is per transcode session.
What you need is more “Per thread” speed, not a massively parallel CPU.
As example:
Compare with an i7-7700 which has 8 threads. Look at its per-thread speed.
Yes. HEVC is the most difficult codec to process in software.
If this were H.264, that CPU would cut through it like a hot knife through butter
but being HEVC, everything changes. They created the codec to support SDR and HDR (10 bit) color spaces. That takes a lot of CPU to crunch for every frame.
Ok so If I avoid HEVC, my setup should be perfect for multiple transcode (+/- 6 streams)?
When you have multiple transcoding stream, will the transcoder overlap on the other cores ? For example, you mentionned 7 core for a single transcode, will the next stream use the 8th - 14th cores ?
If you don’t use HEVC + subtitles, you’re fine. Subtitles are your nemesis. They are single threaded tasks. You might have 8 actual decode / encode threads running for the video & audio but it all comes screeching to ta halt waiting for subtitles to finish.
Intel is adding subtitle support to the hardware acceleration VAAPI. Eventually, it will also be done.
This particular CPU won’t be able to use it because it doesn’t support QSV (Quick Sync Video)
I’m just blown away that my cpus can’t handle one hevc stream. 2 minutes ago I tried to stream (localy) a episode of Final Space (in hevc) and it kept buffering. But before I changed my server, Plex was running on a Intel® Xeon® Processor E3-1230 v2 and I was able to play it smoothly. What changed since ?
The difference is the 3.3 vs 2.6 Ghz clock speed. This is what drives the ‘per thread processing capability’
More cores is not always the answer. The difference between these two makes this point abundantly clear. 8 at a higher speed than 16 at a slower speed.
In this case, I have 3 streams. All H264, one paused and 8 mile is buffering because the transcoder doesn’t transcode fast enough. Do you see something special ?
