![]() ![]() If I upgraded to 19.10 or something then I'd be running a more recent kernel, but I tend to stick religiously to LTS releases for my systems as I do rely on them for stuff like running my Docker swarm which runs services like e-mail, NextCloud, MySQL and Wordpress for my personal site. To switch to the 5.x kernel set I followed these instructions which I did link in the original text. It also has a ZFS replication target on it for my main ZFS array, but I digress. Literally the only other thing I use it for is X2Go as a "management desktop" in my environment particularly when I'm remote. In my case, my 18.04 Plex Server is almost completely that it runs Plex (and Jellyfin, but that's another conversation entirely and only for my private use at the moment) and other services are secondary or just not used. Now, of course you can enable the 5.x kernel set so long as you aren't too bothered by the chance that something will fail. With 18.04 Desktop it tends to lean more aggressive in updates. It tends to stay conservative when running 18.04 SERVER specifically because you want servers to be stable rather than "cutting edge". Typically, the apt-get upgrade (or apt upgrade) will update the kernel, but it tends to be patches and updates for the current kernel set at the time the OS itself "shipped". I know others replied, but let me help you out a bit as a noob. Hope this helps someone out, or at least provides an interesting point of discussion :) I don't know what might've changed in Plex particularly but it seems consistent with a code change that may affect a small number of us, but I think is too specific to only affect me. It took me a few hours to figure out what was going on and I went through a few iterations of test (including trying the oibaf PPA for updated Intel drivers before upgrading the entire kernel) before I hit on a solution that seems to work. I wanted to post this mostly for visibility in the community the fix is pretty easy (upgrade to the 5.x kernel tree) and might be very specific to my hardware config and use case, but it would be worth others running similar setups to test and see if you're running 10-bit HEVC transcoding with hardware acceleration or if you're just chowing down your CPU time unnecessarily. I also suspect some update to ffmpeg caused the similar issue with encoding/decoding 10-bit HEVC with HW acceleration, but I haven't dug enough into it to say for sure. As a result, I imagine when my son was streaming 10-bit HEVC and something else was happening on the box (it's also my "jump box" admin station when I'm not at home running XFCE) that's when the buffering occurred. ![]() My Plex server isn't powerful it's an Intel NUC running an i3-8190U. At some point, this may have just broken and not been a big deal because people who use QS to transcode 10-bit HEVC on Ubuntu Server 18.04 and the 4.x kernel tree are probably in a minority. Some changes were made to the Intel drivers and vaapi libraries for the 5.x kernel that I suspect the Plex developers are now targeting instead of the older setup. So what's the cause? Well, for starters my configuration is running Intel's QuickSync via vaapi. suddenly everything is working perfectly again! Playback is near instantaneous and isn't sitting there soaking up two of my cores when trying to transcode a single stream. I reverted to an older kernel but while that seemed to fix ffmpeg, it didn't fix Plex.įinally after some testing and screwing around I decided to take the leap on that server to the new 5.x kernel tree ( ). It's worth noting that he couldn't tell me exactly when the problem started occurring, just that it was "recently"Īfter digging I found that ffmpeg also wasn't hardware accelerating transcodes either, but this had definitely worked fine at least a few months ago so I was a bit perplexed. ![]() This was weird because other than routine updates of Plex and occasional kernel updates via "apt upgrade" there hadn't been significant changes in my environment in quite a while. I decided to dig into it a bit and realized his problems were with 10-bit HEVC encoded stuff specifically, and when I started testing the files I found that my server was no longer doing hardware-accelerated transcoding but reverting instead to software. basically they would take a long time to start and/or buffer occasionally. I had gotten some reports from my son (who often binge-watches shows) that recently he's been having trouble with watching some shows on my Plex server. if you've recently noticed that HEVC / x265 streams (particularly 10 bit) don't seem to be streaming properly lately read on. I wanted to post this for anyone running Plex as a server on their Ubuntu 18.04 Server instance like me. ![]()
0 Comments
Leave a Reply. |