switch

Don't know what the official Emby container uses as it's base. What I know is it does not use apt as it's package manager Yes, try linuxserver's version of the container. And please post output of ls -la /dev/dri from the Unraid terminal as well.

Omit sudo, as you're already root inside the container. But as card0 is missing, you'll likely won't get anything useful from vainfo. How does ls -la /dev/dri look like from the Unraid terminal?

Unraid is based on Slackware. What's important is, what's used as the base for the Emby container. Could be Alpine, could be Arch, Ubuntu... There is something wrong with the passthrough setup, the output should look like this: root@optiplex:/# ls -la /dev/dri total 0 drwxr-xr-x 2 root root 80 May 17 19:20 . drwxr-xr-x 6 root root 360 May 17 19:20 .. crw-rw---- 1 root video 226, 0 May 17 19:20 card0 crw-rw---- 1 root videouYsyOXiq 226, 128 May 17 19:20 renderD128 You're missing the card0 device completely. Ditch the official Emby container and try using Linuxserver's.

Then the container doesn't have a bash shell. Try opening up the terminal by clicking on the container icon in the docker manager and select Console. Also, have you tried linuxserver's version of the Emby container? May be worth a shot.

Careful, Linux is case-sensitive. From your first screenshot, the name of the container is "embyserver", not "EmbyServer".

Open up an Unraid terminal and try this: docker exec -it embyserver /bin/bash This'll effectively take you into a terminal session inside of your Emby container. Once you're in, type the follwing commands and paste their output here. ls -la /dev/dri vainfo The vainfo package will most likely not be installed inside the Emby container, assuming it is based on Ubuntu, install it via sudo apt update && sudo apt install vainfo

As this is not likely related to the issue we were dealing with in this thread, let's take further troubleshooting to the thread you've created.

Looks like you're passing through the device incorrectly. Pass just /dev/dri, not /dev/dri/renderD128. See if that helps.

Thanks. Looks like they're already working on a fix. For now, I'll make a script that'll run after a Plex update to check if the iHD driver exists and if it does, delete it.

Great find, thanks! How did you find out about it? Google doesn't find much about the iHD_drv_video.so driver on the Plex forums. Have you reported the issue to the Plex devs? If so, is there a thread that you can link me to so I can +1 it?

Just wanna let everyone know that this issue is fully fixed on unRAID 6.8.0-rc1. Everything works as expected without disabling IOMMU or any other config edits, patches or hacks.

This is perfect! Thanks a lot for your effort! Can confirm that "intel_iommu=igfx_off" is working for me as well on 6.7.3-rc3. Since this is clearly a bug in the Linux kernel and not within unRAID itself, I have now marked this bug report as resolved. @limetech, this appears to be fixed in the kernel v5.0 and up, will unRAID 6.8 include a v5.0+ kernel?

Changed Status to Solved

I see. Thanks, will give it a go.

Can you please clarify what do you mean by "one of the downgrades"?

My syslinux.cfg is absolutely untouched, as stated in the first post. I did however try to add it during my troubleshooting attempts and in makes precisely zero difference. You mentioned HW transcoding works for you on a J3455, what version of unRAID are you on?

I give up. Since LimeTech provides zero support, I'll just stay on 6.6.7 or upgrade to a CPU that is not affected by this issue some time in the future. /shrug

I think we can rule "weird bios interactions and use of hacks" out, since HW transcoding works perfectly fine on 6.6.7. I am not using any HDMI headless dongles, I have a proper HDMI cable attached to the iGPU output and connected to a real monitor (transcoding works fine on 6.6.7 even without the iGPU being connected to anything). No other GPU in my system. Is there a way to "transplant" the Docker engine used in 6.6.7 to a later stable build so we can potentially rule it out as well? Does anyone know if there perhaps were any changes to the mainline kernel between 6.6.7 and 6.7.x that could break this? Would it be of any use to test the HW transcoding on a Slackware distro with the same kernel version or is unRAID's kernel too heavily modified for a test like this to have any value? My mistake. I'm pretty new to unRAID and it didn't occur to me there's the option to download the diagnostics. I will provide that as soon as possible, but since I'll need to upgrade to 6.7.x to actually make transcoding not work again so there is something to troubleshoot, it's going to be a PITA. Maybe some of the other affected guys currently on 6.7.x will be kind enough to post their diagnostics in the meantime? Anyone?

@limetech any chance of a reply from you guys? "We will look into it" at least?

I can confirm this. Plus, running vainfo clearly shows the supported encode/decode formats: root@7011518d444b:/# vainfo error: XDG_RUNTIME_DIR not set in the environment. error: can't connect to X server! libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_1 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.1 (libva 2.1.0) vainfo: Driver version: Intel i965 driver for Intel(R) Gemini Lake - 2.1.0 vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264Main : VAEntrypointEncSliceLP VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileH264High : VAEntrypointEncSliceLP VAProfileH264MultiviewHigh : VAEntrypointVLD VAProfileH264MultiviewHigh : VAEntrypointEncSlice VAProfileH264StereoHigh : VAEntrypointVLD VAProfileH264StereoHigh : VAEntrypointEncSlice VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc VAProfileJPEGBaseline : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointEncPicture VAProfileVP8Version0_3 : VAEntrypointVLD VAProfileVP8Version0_3 : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointVLD VAProfileHEVCMain10 : VAEntrypointEncSlice VAProfileVP9Profile0 : VAEntrypointVLD VAProfileVP9Profile0 : VAEntrypointEncSlice VAProfileVP9Profile2 : VAEntrypointVLD So can we please stop focusing on the hardware, which is clearly capable of HW transcoding and instead focus on the real issue - unRAID ver. 6.7.0 and up?

I know that ARK does not specifically mention QuickSync support, BUT... J4105 has a UHD600 graphics built in and UHD600 does indeed support QuickSync. This is further evidenced by HW transcoding working perfectly fine on unRAID 6.6.7 https://en.wikichip.org/wiki/intel/celeron/j4105#Graphics https://en.wikichip.org/wiki/intel/uhd_graphics/600#Hardware_Accelerated_Video

I am passing the iGPU to Plex exclusively, nothing else is using it. On another note, I know this is a minor issue but it is 10 days today since I've opened this report and there has been zero response from anyone from the unRAID team. A simple "we will look into it" would be just fine. This is not how you do customer support.

I've already reported this in the Bug Reports section. Anyone else affected by the nonfunctioning HW transcoding on an iGPU please chime in here:

So far this seems to be UHD600 iGPU / 7th gen Celeron Gemini Lake (J4105 namely) specific. I've opened a bug report, link one post above.

Fire away.