What effort would be required on your part to install a bare-metal Ubuntu 24.04 LTS environment on that system with the native PMS .deb package? And test that, for science.
My guess is that you’d need to use a separate external SSD or similar and install/test with that, if you can handle your Unraid server being down for a bit. I wouldn’t think it would require more than an hour or so.
I might be able to do that and just bring it up in parallel with my working fly-by-night container. Would you suggest that I try both 1.43.0 and the 1.43.1 versions in order?
I’d just test with 1.43.1.x; maybe back down to 1.43.0.x if that doesn’t work.
Just to be clear, I’m suggesting taking Unraid and containers/VMs, any abstraction whatsoever, out of the mix.
Understood. I’ll look into it.
@pshanew - Thanks for the suggestion. Certainly worth trying, but no joy.
I installed 1.43.1.10561 via the .deb on the same Ubuntu machine, claimed the server, and triggered a transcode. The result was identical to Docker: “hardware transcoding: enabled, but no hardware decode accelerator found.”
Before concluding anything, I checked VA-API directly on the host as the plex user:
vainfo: VA-API version: 1.22 (libva 2.22.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 25.2.4 ()
vainfo: Supported profile and entrypoints
VAProfileH264Main : VAEntrypointVLD / VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD / VAEntrypointEncSlice
VAProfileAV1Profile0 : VAEntrypointVLD / VAEntrypointEncSlice
[... full profile list, all healthy]
The hardware and VA-API stack are completely functional. The plex user has the correct group membership and direct access to /dev/dri/renderD128. There are no permission issues, no container layers, no xe-vs-i915 complications.
What the bare metal test confirmed is that the issue is in Plex’s own driver download logic. After install, both the Drivers/ and Cache/va-dri-linux-x86_64/ directories remain empty - 1.43.1 never downloads the iHD driver it needs to initialize hardware decoding. The same thing happens in Docker. The system has a working iHD driver, but Plex doesn’t use it - it insists on its own downloaded copy, and on my system, that download isn’t happening.
Thanks again for your thoughts about this issue.
Having the same issue on my 245k as well. All the more annoying as unraid recently released a beta with the 6.18.20 kernel. Finally bringing better support for newer hardware. Been quite some time without any official update on this.
What I want in my Easter egg is a new beta with the HW acceleration working <3
I can confirm, also experiencing the same issue with a 265K running Unraid on both the i915 driver and XE driver via Docker and LinuxServer/Official images. Plex Version 1.43.1.10561. IT was working…. WAS.
Falls back to CPU - I disabled transcoding for now.
Having same issues with Intel Ultra 265K, Unraid, Linuxserver docker image, Intel IGPU passed into container on build 1.43.1.10561.
Mod Edit: Moved your post to this thread, as it better matches your setup. @FordGuy61
Just tested the new beta (1.43.1.10576-06378bdcd) hoping this would address the driver download regression.
Unfortunately, the same problem persists. After spinning up a fresh container and triggering a transcode, the Drivers/ and Cache/va-dri-linux-x86_64/ directories remain completely empty - no download attempt, no iHD driver, no hardware acceleration. The log confirms it immediately:
TPU: hardware transcoding: enabled, but no hardware decode accelerator found
TPU: hardware transcoding: final decoder: , final encoder:
I hoped 10576 would include a fix, but the core behavior is identical to what I saw earlier: 1.43.1 sees the hardware, enables the setting, attempts to transcode, and then silently falls back to software because it never retrieved the driver it needs.
Still running plex-next (thanks @skreii) without issue, so this isn’t urgent for me personally. But I wanted to make sure the thread stays current. Looking forward to the next build - hopefully the driver download logic is on someone’s radar.
Chiming in here on 1.43.1.10576 on an i5-1145G7 NUC. Transcoding silently falls back to CPU, no tonemapping. No activity in intel_gpu_top.
Good news everyone (or at least for me). Curiosity got the better of me as I was still rocking Ubuntu 25.10. After upgrading the system to 26.04, the iGPU is used again and tonemapping seems to be working as well. Had to chmod +x the Codecs directory to get TrueHD transcodes working but that’s an ever-reoccurring other topic on my server.
Tested @iophobia’s suggestion - spun up a fresh Ubuntu 26.04 container with the 1.43.1.10576 .deb installed natively (not the plexinc Docker image, but the actual Debian package in Ubuntu 26.04 with its libva stack). Same result:
TPU: hardware transcoding: enabled, but no hardware decode accelerator found
TPU: hardware transcoding: final decoder: , final encoder:
Drivers/ and Cache/va-dri-linux-x86_64/ both remained empty after triggering a transcode. The regression I’m seeing isn’t tied to Alpine or the plexinc container - it’s in Plex’s driver download logic itself. Ubuntu 26.04 doesn’t seem to change that behavior.
Still running @skreii’s plex-next (ghcr.io/home-operations/plex-next) with its bundled iHD driver as a workaround.
Hello, not sure if this is the right place or really what i can offer. I’m running on Ubuntu 24.04.4 LTS with a Ultra 7 265K. After the server update (i guess i need to turn off auto updates) my system is no longer Hardware Transcoding. Under Hardware transcoding device, Intel Arrow Lake-S is there but it’s never used and so the system only transcodes to h.264. It looks like my system is using the i915 driver.
Since i’m not using docker, i’m assuming the plex-next option won’t work for me. Is there anything else i can try to fix this?
Tested 1.43.1.10611 - same regression. Drivers/ stays empty, no hardware decode accelerator found.
Given the multiple anecdotes about this reproing outside of a Docker configuration, should the tags for this thread be changed to include server-linux?
Can confirm the issue with 1.43.1.10611 on Intel Core Ultra 225. Container Rollback to 1.43.0.10492 brings back working HW transcoding.
Doesn’t work for me either with a 265k ultra 7 thought I was going mad
Seems the update didn’t work for transcoding amd broken it further
Unfortunately for my processor and environment, the rollback to 1.43.0 doesn’t work either.
