which specific CPU do you have ?
grep 'model name' /proc/cpuinfo | uniq
/dev/dri won’t exist in the container until you pass it through from the host
sturen@TrueNas:~$ grep 'model name' /proc/cpuinfo | uniq
model name : 12th Gen Intel(R) Core(TM) i7-12700
Create a test container with UID=0 and GID=0 from an account which has full administrative privileges
TrueNAS itself does not require the QSV GPU.
When you SSH into truenas itself, does ls -lan /dev/dri show the GPU?
If not, then all stop – TrueNAS has problems
(confirming this is what you showed me above)
Last silly question, Did you create another container from a template which already took the GPU?
Look here. This will help you diagnost WTH is happening.
Looks like TrueNAS doesn’t bother scanning for GPUs anymore.
benjamin@athena:/$ sudo dmesg | grep i915
[ 12.537909] i915 0000:00:02.0: Your graphics device 4c9a is not properly supported by the driver in this
kernel version. To force driver probe anyway, use i915.force_probe=4c9a
followed by
benjamin@athena:/$ sudo midclt call system.advanced.update '{"kernel_extra_options": "i915.force_probe=4c9a"}'
Extra care here:
Note: The ‘4c9a’ in the ‘midclt’ command above should be replaced with the results from the ‘lspci | grep -i vga’ command. The four characters directly after the “Intel Corporation Device” string.
Follow the procedure. Use the results for YOUR CPU
I really appreciate your following here @ChuckPa thx!.
Following your command, the i915 is not supported
sturen@TrueNas:~$ sudo dmesg | grep i915
[ 14.304698] i915 0000:00:02.0: Your graphics device 4680 is not properly supported by the driver in this
kernel version. To force driver probe anyway, use i915.force_probe=4680
[ 14.354229] snd_hda_codec_hdmi hdaudioC0D2: No i915 binding for Intel HDMI/DP codec
but when I try get kernel force probe 4c9a in your case, I don’t understand what exactly code is on my case 
sturen@TrueNas:~$ lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation AlderLake-S GT1 (rev 0c)
You don’t want the code 4c9a.
As I stated, use the code for your machine.
Looking above, your machine is reporting 4680
this makes it:
'{"kernel_extra_options": "i915.force_probe=4680"}'
Every machine is different. Use the values returned by dmesg and edit the i915.force_probe= statement accordingly
I’m really dismayed what TrueNAS has done (hasn’t done) here.
It’s as if they don’t want you using it as a media server appliance
As confirmation, Intel CPUs almost always put the QSV on 0000:00:02.0 in the CPU.
i915 0000:00:02.0:
This is my i7-8809G CPU
*-display
description: Display controller
product: HD Graphics 630
vendor: Intel Corporation
physical id: 2
bus info: pci@0000:00:02.0
version: 04
width: 64 bits
clock: 33MHz
capabilities: pciexpress msi pm bus_master cap_list
configuration: driver=i915 latency=0
resources: iomemory:2f0-2ef iomemory:2f0-2ef irq:190 memory:2ffe000000-2ffeffffff memory:2fa0000000-2fafffffff ioport:f000(size=64)
The point here is ,
- Must probe the i915
- When the i915 is probed, the QSV will be discovered
- Once discovered, driver will be loaded and enumerated in /dev/dri
gacha!, now the i915 display information is done
sturen@TrueNas:~$ sudo dmesg | grep i915
[ 0.000000] Command line: BOOT_IMAGE=/ROOT/22.12.4.2@/boot/vmlinuz-5.15.131+truenas root=ZFS=boot-pool/ROOT/22.12.4.2 ro libata.allow_tpm=1 amd_iommu=on iommu=pt kvm_amd.npt=1 kvm_amd.avic=1 intel_iommu=on zfsforce=1 nvme_core.multipath=N i915.force_probe=4680
[ 0.033231] Kernel command line: BOOT_IMAGE=/ROOT/22.12.4.2@/boot/vmlinuz-5.15.131+truenas root=ZFS=boot-pool/ROOT/22.12.4.2 ro libata.allow_tpm=1 amd_iommu=on iommu=pt kvm_amd.npt=1 kvm_amd.avic=1 intel_iommu=on zfsforce=1 nvme_core.multipath=N i915.force_probe=4680
[ 14.679072] i915 0000:00:02.0: [drm] VT-d active for gfx access
[ 14.679211] i915 0000:00:02.0: vgaarb: deactivate vga console
[ 14.679979] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
....
and now I have folder ons dev/dri
sturen@TrueNas:/dev/dri$ ls -lha
total 0
drwxr-xr-x 3 root root 100 Feb 27 18:25 .
drwxr-xr-x 22 root root 4.2K Feb 27 18:26 ..
drwxr-xr-x 2 root root 80 Feb 27 18:25 by-path
crw-rw---- 1 root video 226, 0 Feb 27 18:25 card0
crw-rw---- 1 root render 226, 128 Feb 27 18:25 renderD128
but… the streaming 4k still having problems 
, this is a new log
plex_log_2.zip (51.2 KB)
You’re getting really close… but the GIDs are screwed up
They should look like this (be the same whether ‘video’ or ‘render’)
[chuck@lizum docker.2002]$ ls -la /dev/dri
total 0
drwxr-xr-x 3 root root 140 Feb 27 08:18 ./
drwxr-xr-x 21 root root 5400 Feb 27 19:14 ../
drwxr-xr-x 2 root root 120 Feb 27 08:18 by-path/
crw-rw----+ 1 root render 226, 0 Feb 27 08:18 card0
crw-rw----+ 1 root render 226, 1 Feb 27 08:18 card1
crw-rw----+ 1 root render 226, 128 Feb 27 08:18 renderD128
crw-rw----+ 1 root render 226, 129 Feb 27 08:18 renderD129
[chuck@lizum docker.2003]$
How good are you at the command line in the docker container ?
ALSO, for this testing. NO SUBTITLES PLEASE!
Feb 27, 2024 18:33:27.483 [140269309676344] Debug — [Req#14f0/Transcode] Subtitles: Found a candidate subtitle language [en] for a foreign film
Feb 27, 2024 18:33:27.483 [140269309676344] Debug — [Req#14f0/Transcode] Audio Stream: 102452, Subtitle Stream: 102453
Feb 27, 2024 18:33:27.485 [140269309676344] Debug — [Req#14f0/Transcode] Codecs: testing h264_vaapi (encoder)
Feb 27, 2024 18:33:27.485 [140269309676344] Debug — [Req#14f0/Transcode] Codecs: hardware transcoding: testing API vaapi for
Which GID are you running as?
As a test, we can force the OS ownership for /dev/dri temporarily
How good are you at the command line in the docker container ?
I can, what do you have in mind?
ALSO, for this testing. NO SUBTITLES PLEASE!
sorry, I just recreate the same issue
I specifically want you to get on the TrueNAS command line.
The easiest and least intrusive is this way:
- Confirm your
/dev/drihas survived reboots
ls -la /dev/dri
- Now we remove the UID/GID restrictions (which normally udev handles)
chmod 666 /dev/dri/card* /dev/dri/render*
This ^^ command will allow any GID to read/write the QSV (renderD128) and access the OpenCL (card0)
- We confirm:
ls -la
[chuck@lizum rules.d.2006]$ ls -la /dev/dri
total 0
drwxr-xr-x 3 root root 140 Feb 27 08:18 ./
drwxr-xr-x 21 root root 5400 Feb 27 19:14 ../
drwxr-xr-x 2 root root 120 Feb 27 08:18 by-path/
crw-rw----+ 1 root render 226, 0 Feb 27 08:18 card0
crw-rw----+ 1 root render 226, 1 Feb 27 08:18 card1
crw-rw----+ 1 root render 226, 128 Feb 27 08:18 renderD128
crw-rw----+ 1 root render 226, 129 Feb 27 08:18 renderD129
[chuck@lizum rules.d.2007]$ sudo chmod 666 /dev/dri/card* /dev/dri/render*
[chuck@lizum rules.d.2008]$ ls -la /dev/dri
total 0
drwxr-xr-x 3 root root 140 Feb 27 08:18 ./
drwxr-xr-x 21 root root 5400 Feb 27 19:14 ../
drwxr-xr-x 2 root root 120 Feb 27 08:18 by-path/
crw-rw-rw-+ 1 root render 226, 0 Feb 27 08:18 card0
crw-rw-rw-+ 1 root render 226, 1 Feb 27 08:18 card1
crw-rw-rw-+ 1 root render 226, 128 Feb 27 08:18 renderD128
crw-rw-rw-+ 1 root render 226, 129 Feb 27 08:18 renderD129
[chuck@lizum rules.d.2009]$
- Please see if you have ‘udev’ installed on the host
command -v udevadm
as showing previewslly, I change permissions for this two folders, and udev installed:
sturen@TrueNas:~$ ls -la /dev/dri
total 0
drwxr-xr-x 3 root root 100 Feb 27 18:25 .
drwxr-xr-x 22 root root 4300 Feb 27 18:26 ..
drwxr-xr-x 2 root root 80 Feb 27 18:25 by-path
crw-rw---- 1 root video 226, 0 Feb 27 18:25 card0
crw-rw---- 1 root render 226, 128 Feb 27 18:25 renderD128
sturen@TrueNas:~$ sudo chmod 666 /dev/dri/card* /dev/dri/render*
sturen@TrueNas:~$ ls -la /dev/dri
total 0
drwxr-xr-x 3 root root 100 Feb 27 18:25 .
drwxr-xr-x 22 root root 4300 Feb 27 18:26 ..
drwxr-xr-x 2 root root 80 Feb 27 18:25 by-path
crw-rw-rw- 1 root video 226, 0 Feb 27 18:25 card0
crw-rw-rw- 1 root render 226, 128 Feb 27 18:25 renderD128
sturen@TrueNas:~$ command -v udevadm
/usr/bin/udevadm
should try reproduce file?
Do you have a H.264 file (not hevc) without subtitles you can test first ?
Also, after changing the permissions in /dev/dri, please restart the container so PMS knows to get the correct drivers downloaded
Do you have a H.264 file (not hevc) without subtitles you can test first ?
All my 1080p files (H.264) working perfectly, my files on 4k all is HEVC 
Also, after changing the permissions in /dev/dri, please restart the container so PMS knows to get the correct drivers downloaded
Done, if I disable burn subtitles, the file is sended to player directly, so don’t use transcoding on server and working perfect, but If I force transcoding (burning the subtitles), same issue.
I don’t see any difference here is a log or folder /dev/dri
plex_log_3.zip (5.5 KB)
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
