If you use any of the Dolby codecs and require transcoding – this is where the file locking is required. The EAE (EasyAccessEncoder) they provide is very unsophisticated. We must use file locking and Linux’s inotify to properly detect when the encoder has completed its work.
If there is nothing in /dev/dri, or the directory doesn’t exist at all, the kernel itself, specifically the i915 ASIC in the CPU, isn’t being found by the kernel. The i915 is used as the interface device to communicate with the transcoding HW (Quick Sync Video) ASIC.
There are multiple motherboards which disable all this by default or, if it worked prior to Ubuntu 20.04, then Ubuntu isn’t understanding the motherboard.
My logic looks at what the kernel detects and creates (/dev/dri). I specifically look for:
/dev/dri/renderD128 for the Quick Sync Video
/dev/fb0, and a few other legacy names, to determine the render/video group to add PMS to.
I guess what i’m saying is that everything was working as it should (HW transcoding, temp folder on the NAS, etc etc etc) prior to the update.
All i did was an apt update then apt upgrade, then all hell broke loose.
so i’m not sure what happened, and/or how to fix this
It wouldn’t be a big deal if I were to completely remove/purge the server and re-install from scratch if that fixes the problem.
But i’m curious as to what was the cause and not having it repeat.
[ 0.027834] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-37-generic root=UUID=877477ce-cf39-4a44-b927-c87db6a985f3 ro nomodeset
[ 0.027873] You have booted with nomodeset. This means your GPU drivers are DISABLED
[ 0.027874] Any video related functionality will be severely degraded, and you may not even be able to suspend the system properly
[ 0.027874] Unless you actually understand what nomodeset does, you should reboot without enabling it
I guess my next question is, what did i do to cause this? and how do i correct it?
Then start looking through the BIOS/UEFI settings and see if it’s disabled.
Something might have turned it off in the UEFI but that’s extremely unlikely. BIOS is not accessible by the OS but UEFI boot parameters are.
You likely need to take this to the Lenovo forums for further help in determining what happened.
Same issue for me. Everything was working fine until the update to 1.12.1.1253-c29aa096
Hardware decoding is not working and the CPU pegs at 100 percent and drops the quality.
I have two files, card0 and renderD128 under /dev/dri/
Running on a dual Celeron QNAP server that has had no issues for quite some time.
Rebooted the QNAP NAS, downgraded to last Plex version, had somebody that required transcoding try it again and still the same issue. Reverted back to version 1.19.3.2852 and still have the issue.
I believe there was some sort of update (possibly kernel update) on the QNAP/Linux side that is causing this, for me at least. I will open up a ticket with QNAP to see what’s going on and if I’m feeling adventurous, I might downgrade the QNAP firmware to resolve this temporarily.
