Cannot replicate transcoding problems with Ubuntu 22.04 & PMS build 9092
Please attach DEBUG logs ZIP file which captures the failure.
Hello Chuck again, sorry to bother, just quick question, is your finding correct? If so, can we expect some eta to fix? So far as I understand, this should be just add some lines to config, it is very frustrating to not be able to use Plex to its full potencialā¦
Thanks again 
which finding please? There are two observations here.
Intel Raptor Lake Refresh (Intel Core 3 U100) support, as plex show it as Unknown (intel) and HW transcoder does ignore this GPU.
The issue is scheduled (that much I know). I donāt know where it is on the list of hardware changes to make. There are only two of us working on transcoding (and I spend a lot of my time here in the forums helping folks).
It would be really nice if we had at lease one more person on our team.
( Buy more PlexPasses! ā hint hint ā 
)
Update: We just chatted. The CPU/GPU list is being updated now.
it will make the next release (no promises)
1 Like
ALL:
Weāve found a small secondary issue preventing our build from working correctly for āUnknownā devices. ( Unknown Intel - Unknown Nvidia )
The updated build is generating now.
I will have a test build either later tonight or first in the morning US EDT.
1 Like
@ChuckPa I have the same issue on an i5-13500H when I was on Version 1.41.2.9134 I could not get hardware transcoding to work on files I have had no issues with in the past. When I pinned the 1.41.1.9057 version in the docker-compose file and tried those same files and had no problem hardware transcoding them.
Can you please get me the server DEBUG logs ZIP file which captures the start of the failing playback
Please help me undertstand your config?
- You have a native PMS and a Docker PMS ?
- The native PMS fails but the Docker PMS works?
HW transcoding & Tone mapping working OK for me
CPU: Intel(R) Coreā¢ Ultra 7 155H
GPU: Meteor Lake-P [Intel Arc Graphics]
OS: Ubuntu 24.04.1 LTS
Kernel: 6.8.0-47-generic x86_64
PMS Version: 1.41.1.9057
I am running Ubuntu 22.04.04 LTS which is running docker/docker-compose and that is running plex. When I upgraded to 1.41.2.9134 the hardware transcoding quit working but when I pinned the 1.41.1.9057 version using docker-compose it started working again. I will work on getting you the logs later today as I will have to revert to the latest and retest. I am not running a bare-metal/native PMS it is only running in docker. Also, the hardware transcoding video device is showing āRaptor Lake-P [Iris Xe Graphics]ā in the drop-down so I wouldnāt think it would be related to the unknown issue above.
Not sure my CPU is listed in first post
Core Ultra 7 265K
Tried Debian Testing (Trixie) (Kernel 6.11.4) - Not Working
Tried Ubuntu 24.10 (Kernel 6.11) - Not Working
Come join us here.
I have an Experimental build with updated CPU/GPU for the new Arrow Lake CPUs
Would appreciate your confirmation nothing got broken 
I upgraded the docker container again to the plex pass version 1.41.2.9134 to get you the logs but it appears to using the hardware decoding again successfully. If I run into the issue again I will send you the debug logs.
Thank you
I just upgraded to 24.04.1 from 22.04 and am now having issues getting HW transcoding working. I had originally upgraded because I had read that a newer kernel version was required to hardware tone mapping transcoding, but this seems to have opened up a can of worms.
Ubuntu Version: 24.04.1
Kernel Version: 6.8.0-49-generic
GPU model: i5-8400
PMS version: 1.41.2.9200 (Docker Container)
Basic transcoding only pegs the CPU and the intel-gpu-top shows no usage.
ls -la /dev/dri
total 0
drwxr-xr-x 3 root root 100 Nov 30 17:43 .
drwxr-xr-x 19 root root 4620 Nov 30 17:45 ..
drwxr-xr-x 2 root root 80 Nov 30 17:43 by-path
crw-rw---- 1 root video 226, 1 Nov 30 17:56 card1
crw-rw---- 1 root render 226, 128 Nov 30 17:43 renderD128
my dockeruser which I am passing into the container as the PLEX_UID is a member of both video and render groups. I am able to see and select the hardware transcoding device by name in the server transcoding options.
Debug ā [Req#9d5c/Transcode] Codecs: testing h264 (decoder) with hwdevice vaapi
Debug ā [Req#9d5c/Transcode] Codecs: hardware transcoding: testing API vaapi for device '/dev/dri/renderD128' (CoffeeLake-S GT2 [UHD Graphics 630])
Error ā [Req#9d5c/Transcode] [FFMPEG] - Failed to initialise VAAPI connection: -1 (unknown libva error).
Debug ā [Req#9d5c/Transcode] Codecs: hardware transcoding: opening hw device failed - probably not supported by this system, error: I/O error
Debug ā [Req#9d5c/Transcode] Could not create hardware context for h264
I am able to use hardware transcoding with Immich and can verify this using intel_gpu_top.
Ubuntu 24.04.1
6.8.0-49-generic x86_64
CPU/iGPU: i5-8259U / Intel Iris Plus Graphics 655
PMS: 1.41.2.9200 and 1.41.3.9232 (linuxserver/plex docker)
HW transcoding workings fine by itself, but enabling āHDR tone mappingā seems to make it fallback on software transcoding and the CPU alone struggles with a single video stream.
Just tried rolling back to Ubuntu 22.04 on kernel 5.15.0, it has the same problem there.
Whenever youāre using Docker, the UID which you run in the container
(env var: PUID, or PLEX_UID) must be a member of the groups which own the /dev/dri nodes (on the host itself).
The native host PMS installer examines /dev/dri to determine this and adds user āplexā to those groups.
When you create a container, you must add the group memberships yourself.
For an i5-8400 CPU (Coffee Lake), the 5.15 kernel will work but isnāt the best. It was OK in 20.04.
With 22.04 or 24.04, you really need to be at the 6.8 kernel because of the runtime library changes in how /dev/dri is handled.
I would very much like to see PMS debug logs ZIP which captures:
- PMS startup
- The start of a playback which invokes transcoding.
I only need a few seconds.
Iām pretty sure the linuxserver.io plex image sets the /dev/dri permissions correctly. I 've updated my ubuntu 22.04 install to the 6.8 kernel and still seeing the same issue.
Iāll PM my logs.
