Can you provide some additional detail to backup these assertions? If this were true, no HW-accelerated transcoding would function for any architecture which require iHD. And that’s just not the case.
The path your reference is the build path of the driver (“conan” in the path indicates this), not the runtime path. The runtime path always points to the Plex driver directory in the server data directory path.
Thanks @pshanew for having a look. I certainly may have read too much into what I saw. I think I conflated the build-time rpath entries I saw in the transcoder’s --help output with runtime behavior. I appreciate the correction that the runtime path resolves through the server data directory, not the conan build paths.
To be more precise about what I actually observed rather than what I inferred:
On the official plexinc/pms-docker:beta image, the transcoder logs consistently show:
TPU: hardware transcoding: enabled, but no hardware decode accelerator found
TPU: hardware transcoding: final decoder: , final encoder:
No iHD driver is being loaded. I was unable to find a configuration that changed this on Arrow Lake-P (Intel Core Ultra 7 255H, device 8086:7d51), even with LIBVA_DRIVER_NAME=iHD set, correct device permissions, and a host stack that passes vainfo cleanly with iHD 25.2.4.
What did work, after some trial and error, was switching to @skreii’s plex-next image — with one critical fix I was missing: group_add: ["109"] in the Compose file. Without it, the container’s user (running as 997:997) lacked membership in the host’s render group (GID 109), which owns /dev/dri/renderD128. That permission failure was being surfaced as “Invalid argument” at the ffmpeg level. Once I added that, hardware transcoding came up immediately: final decoder: vaapi, final encoder: vaapi, zero-copy, iHD 25.4.6.
My question is really: on the official image and Arrow Lake specifically, where should the iHD driver be coming from at runtime, and is there a known reason it isn’t being found? I’m happy to provide whatever diagnostic output would be useful.
The path to the drivers should be (from within the container):
/config/Library/Application Support/Plex Media Server/Drivers
There’ll be separate icrl and imd directories (older platforms will have an ivd directory with the i965 driver).
It’s just strange to me that many others can now get this working with Battlemage and modern (Arrow Lake) graphics without resorting to custom, opaque, custom images.
Thank you for the pointer to the Drivers directory - that was the right place to look, and it led directly to the answer.
Plex downloaded and installed imd-32d7192a7be141f227f779f1-linux-x86_64/dri/iHD_drv_video.so. Inspecting it:
$ strings iHD_drv_video.so | grep "Intel iHD"
Intel iHD driver for Intel(R) Gen Graphics - 24.1.5 ()
$ readelf -d iHD_drv_video.so | grep NEEDED
NEEDED libgcompat.so.0
NEEDED libigdgmm.so.12
NEEDED libc.so
Two problems, stacked, specific to Linux:
1. Driver version 24.1.5 predates Arrow Lake. intel-media-driver 24.1.5 was released in early 2024. Arrow Lake (Core Ultra 200 series, Battlemage Xe2) didn’t ship until October 2024. Hardware-level support for this architecture wasn’t added to intel-media-driver until the 24.2/24.3 timeframe. The driver Plex is bundling simply doesn’t know this GPU exists.
2. The bundled driver is musl-compiled and requires libgcompat.so.0, which is an Alpine Linux compatibility shim. On Ubuntu - where plexinc/pms-docker is based - this library doesn’t exist, and the driver fails to load. This is a Linux-specific packaging issue; Windows has its own driver stack entirely and wouldn’t be affected.
The imd-* directory also only contains dri/iHD_drv_video.so - libigdgmm.so.12 isn’t included alongside it, and the driver’s RUNPATH of $ORIGIN/.. would expect it there rather than at the system library path.
So the likely split in experiences: Windows users with Arrow Lake/Battlemage are working (separate driver stack). Linux users with older Intel hardware (Gen 11/12/13) are working (24.1.5 supports them, and libgcompat isn’t needed or is satisfied differently). Linux users with Arrow Lake/Battlemage hit both walls at once.
If others on Linux are successfully using the official image with Battlemage specifically, I’d genuinely like to understand how - are they on a different Plex build that ships a newer imd-* package, or is there something resolving the libgcompatdependency on their system?
Interesting. On my own system it’s:
$ strings iHD_drv_video.so | grep -i "intel ihd"
Intel iHD driver for Intel(R) Gen Graphics - 25.2.6 (042218f)
As for libgcompat, it’s present in the Plex Media Server install directory, /usr/lib/plexmediaserver in the lib sub-directory.
Are you still running version 1.43.1.10540 (or later)? If so, that should include the updated drivers/libraries.
I just performed a test where I moved my “Drivers” directory aside forcing it to re-download them. I then confirmed that the iHD driver was still version 25.2.6.
A correction and an update - thank you for your patience as I’ve worked through this.
First, a clarification I owe: I’ve been incorrectly describing my iGPU as “Battlemage” in earlier posts. The hardware is an Intel Core Ultra 7 255H (Arrow Lake-P), PCI ID 8086:7d51 - which is an Arc 130T/140T iGPU using the Xe-LPG+ architecture, not Xe2/Battlemage. Battlemage applies to Arc B-series discrete GPUs and Lunar Lake iGPUs. I apologize for the confusion that may have introduced.
Following your guidance about the Drivers directory, I spun up a completely clean plexinc/pms-docker:beta container on 1.43.1.10561 - fresh config, no migration artifacts. Here’s what I found, stated as carefully as I can:
What I confirmed:
libgcompat.so.0, libigdgmm.so.12, libva.so.2, and libva-drm.so.2 are all present in /usr/lib/plexmediaserver/lib/ as you described.
The Cache/va-dri-linux-x86_64/ directory is created at startup.
No download request to downloads.plex.tv for the imd-a5431fbbff9ce9568f94ae21 package ever fired during my observation window. The Drivers directory remained empty throughout.
What I tried and what didn’t work:
I manually extracted the imd zip (which contains iHD 25.2.6) directly into Cache/va-dri-linux-x86_64/. All dependencies resolve correctly against Plex’s lib directory. I also explicitly set LIBVA_DRIVERS_PATH and LIBVA_DRIVER_NAME=iHD as container environment variables. Even with the driver physically present and the path explicitly pointed at it, every transcode attempt still returned “hardware transcoding: enabled, but no hardware decode accelerator found.”
What I think might be happening:
My best current guess is that the driver download is gated on a successful hardware probe - if Plex can’t confirm the device is usable through its own detection code, it skips the download entirely. Something about my system is causing that probe to fail before the driver is ever loaded, which creates a dead loop that manually placing the driver doesn’t break.
What that “something” is, I’m less certain about. On kernel 6.17, the xe kernel driver is now active for my Arrow Lake-P iGPU, having replaced i915 as the default on newer kernels. It’s possible Plex’s hardware probe was written or tested primarily against the i915 DRM interface, and behaves differently when xe is the active driver. If that’s the case, this may affect any Intel platform where xe has become the default - not just my specific hardware - and users on older kernels where i915 is still active for their GPU might have a different experience even with the same CPU generation.
I want to be clear this is speculative. I don’t have visibility into Plex’s probe code, and I could be wrong about the mechanism. But it’s the best explanation I have for why placing the correct driver in the correct location still doesn’t result in detection.
Is there anything specific you’d like me to capture about my environment that might help narrow it down?
Just a quick question to start: Have you tried playing anything since spinning up the new container? As far as I know, the drivers are downloaded until a play attempt is made which requires HW-accelerated transcoding. I can test that again as it may have changed but I’m almost positive that was the behavior in the not-too-distant past.
Edit: Nope, I’m mistaken. I just did a quick test and the drivers are immediately downloaded, if missing.
In that case, you may want to post (or DM) your server logs (with debug enabled); there may be an issue on your system with downloading the drivers.
Also, in PMS’ transcoder settings (Settings → Transcoder), ensure that your device is listed as an option in Hardware transcoding device.
Thank you for the self-correction - that’s actually helpful context, because it rules out the “no play attempt” explanation. I made multiple play attempts on the fresh container, and also watched the logs from the moment the container started. The imd package download never fired at any point - not at startup, not on first play, not on subsequent attempts.
To answer your questions directly:
Does the device appear in Settings → Transcoder? Yes. “Intel Arrow Lake-P” appears in the hardware transcoding device selector, and HardwareDevicePath="8086:7d51:1043:88fe@0000:00:02.0" is correctly set in Preferences.xml. I selected it explicitly on the fresh container.
What do the logs show? Every transcode attempt, without exception, produces:
TPU: hardware transcoding: enabled, but no hardware decode accelerator found
TPU: hardware transcoding: final decoder: , final encoder:
There is no attempt to open the VAAPI device, no libva output, and no outbound request to downloads.plex.tv for the imd package. For comparison, the x264 software codec (liblibx264_encoder.so) downloaded successfully from downloads.plex.tv on first use, so outbound connectivity is fine.
I went further and manually extracted the imd package (which I confirmed contains iHD 25.2.6 and is available at the URL hardcoded in the 1.43.1.10561 binary) directly into Cache/va-dri-linux-x86_64/. Verified all dependencies resolve correctly against /usr/lib/plexmediaserver/lib/. Still the same result.
I’m happy to pull and share the full debug logs if that would help. My suspicion remains that the probe is failing at a level below the driver - possibly related to the xe kernel driver being active on kernel 6.17 instead of i915 - but I could easily be wrong about that mechanism.
Your observations match mine. The driver isn’t downloaded and the log output is quite minimal.
But I’m on a 6.8 kernel with the i915 driver in use. So, it seems unlikely that’s xe vs i915 is the root of the issue.
Thank you - this is really useful. The fact that you’re seeing identical behavior on kernel 6.8 with i915 rules out my theory about the xe driver being the root cause. I appreciate you sharing that.
It also narrows things considerably. If the probe fails regardless of which kernel driver is active, the issue is more likely sitting at a higher level - either Plex’s detection code doesn’t recognize our specific GPU PCI IDs, or something in the capability query itself fails for our hardware generation before the driver download is ever triggered.
One thing worth noting from the Alder Lake thread: a user with an Intel N95 (kernel 6.17, i915) resolved their issue by removing what turned out to be stale Preferences.xml entries carried over from previous hardware migrations. The fix involved purging those entries along with the Cache, Codecs, and Drivers directories. Their imd package (also containing iHD 25.2.6) then downloaded successfully on restart. That’s a clean resolution for their case, but it wouldn’t explain our situation - my test was on a completely fresh container with no migration history and the same result.
It would be interesting to know your specific hardware and PCI ID. My GPU is 8086:7d51 (Core Ultra 7 255H, Arrow Lake-P, Arc 140T). If your hardware has a different PCI ID and is also failing, it would suggest the issue spans the Arrow Lake generation broadly rather than being specific to one device ID. And if pshanew’s working systems happen to have different PCI IDs, that comparison might help pinpoint exactly where Plex’s detection draws the line.
Mine is 8086:7d67.
Would you mind DM’ing me your Plex server logs (with Debug, but not Verbose), from after a reboot?
This issue was already reported 11 days ago by myself: Hardware/GPU/Quicksync transcoding broken on Beta 1.43.1.10540
Can we please merge both topic into one to keep one place for this issue?
done! Sorry I’ve been trying to determine which threads were similar enough to merge.
edit: I think I got them all. Sorry for any confusion the merge may have caused.
Thank you 
Coming from one of the merged threads, I read this thread to try to understand how these problems are related. I ran two clean sequential tests - same fresh config directory, same hardware (Intel Core Ultra 7 255H, Arrow Lake-P, PCI 8086:7d51, kernel 6.17 with xe driver active), same Docker setup. Started on 1.43.0.10492, ran a transcode, then upgraded the same config in place to 1.43.1.10561 and ran another transcode.
On 1.43.0.10492:
The driver download mechanism works. On first transcode attempt, Plex downloaded iHD 24.1.5 into Drivers/imd-32d7192a7be141f227f779f1-linux-x86_64/ and created a symlink at Cache/va-dri-linux-x86_64/iHD_drv_video.so. It then attempted initialization and failed:
Codecs: hardware transcoding: testing API vaapi for device '/dev/dri/renderD128' (Intel Arrow Lake-P [Intel Graphics])
[FFMPEG] - libva: /config/Library/Application Support/Plex Media Server/Cache/va-dri-linux-x86_64/iHD_drv_video.so init failed
[FFMPEG] - Failed to initialise VAAPI connection: 18 (invalid parameter).
Codecs: hardware transcoding: opening hw device failed - probably not supported by this system, error: I/O error
TPU: hardware transcoding: enabled, but no hardware decode accelerator found
The initialization failure on 1.43.0 is expected - iHD 24.1.5 was released in early 2024, before Arrow Lake shipped. But the mechanism itself worked correctly: detect device, download driver, attempt initialization, report failure.
On 1.43.1.10561 (same config, upgraded in place):
The first thing 1.43.1 did on startup was delete the drivers 1.43.0 had installed:
Codecs: Deleting old driver library directory at ".../Drivers/icr-8cc9b1b5bc2e41d30c62ae32-linux-x86_64"
Codecs: Deleting old driver library directory at ".../Drivers/imd-32d7192a7be141f227f779f1-linux-x86_64"
No replacement download followed. On transcode attempt:
TPU: hardware transcoding: enabled, but no hardware decode accelerator found
TPU: hardware transcoding: final decoder: , final encoder:
No driver load attempt, no libva output, no request to downloads.plex.tv for the new imd package. The old drivers were removed but the new ones were never fetched.
Summary:
The regression in 1.43.1 appears to be that it correctly identifies and removes outdated driver packages on upgrade, but then fails to download their replacements. On Arrow Lake at least, this leaves the system in a state where no driver is present and the hardware probe is skipped entirely - a worse outcome than 1.43.0 where the probe at least ran and reported a meaningful error.
I’m happy to PM the full logs from both sessions if that would help, just let me know.
The underlying Arrow Lake initialization failure on 1.43.0 is a separate issue - iHD 24.1.5 is simply too old for this hardware - but the 1.43.1 regression means users on affected hardware get no diagnostic information at all.
Just chiming in here. Running Ultra 5 245k and getting the same result.
Thanks, @Lanny0134. Hoping that this thread is getting official attention.
Also chiming in. Ultra 9 285 experiencing the same failure of hardware transcoding when upgrading from 1.43.0 to 1.43.1.
Buried in logs is the same hardware transcoding: enabled, but no hardware decode accelerator foundentry mentioned in this thread.
Behavior on 1.43.1 is to fallback to software transcoding. Reverting back to 1.43.0 restored previous behavior (hardware transcoding works as expected).
Unfortunately for my hardware and environment, neither 1.43.0 nor 1.43.1 gives me hw transcoding.
