[Jellyfin] Intel QSV (transcoding) not working on latest proxmox kernel (6.8.4-3-pve)

[David-Moreira]

Hello,

I just happened to stumble upon this reddit post, where they mention that passthrough stopped working correctly for their plex on latest kernel.
https://www.reddit.com/r/Proxmox/comments/1cm607r/intel_quick_sync_passthrough_to_plex_lxc_stopped/
(It also talks about how someone fixed it for jellyfin)

Myself, I use tteck jellyfin container with quicksync enabled and decided to explore if this might be an issue.
Since I have two mini pcs with the same cpu (N100), I decided to upgrade on of them to check. let's call Main instance and Backup instance.

In my Backup instance, I decided to update to latest proxmox version, kernel 6.8.4-3-pve(uname -r) and install a fresh tteck jellyfin with default settings.
I enabled the QSV settings & downloaded big buck bunny(video sample for testing) and tried to set a lower resolution to transcode. Jellyfin will not transcode.

In my Main instance with kernel 6.8.4-2-pve (uname -r) my existing instance is working just fine, I also tried installing a new tteck jellyfin instance with default settings, enabling the QSV settings and it's working fine.

Hopefully I didn't make any mistakes in my testing... do you think it might be worth keeping an eye on this?

[tteck]

It would be nice to see the contents of each LXCs .conf file

[David-Moreira]

Only thing I noticed is that the card is assigned a different name:
/dev/dri/card1

No idea why it would not be card0 as the other one, and if it makes a difference whatsover?

[tteck]

The script checks for the existence of /dev/dri/card0, if not found, sets it at /dev/dri/card1

What is the output from ls -l /dev/dri executed within the Proxmox shell?

[David-Moreira]

It seems according to your script:
Backup:

Main:

Since the mini pcs are the same model I found it weird that it got assigned a different device name.

[tteck]

Mine did the same thing, went from card0 to card1. But I am not utilizing any transcoding.

[David-Moreira]

Hmm I see. Well, If I didn't make any mistakes in my testing, this might be an issue going forward for people who want to use your jellyfin container+ transcoding?

So unfortunately you don't have the tools necessary to test this on your end?

Anything you would like me to test, or should we leave it and figure out whether users come complaining in the near future?
I myself, am leaving my main instance on that 6.8.4-2-pve kernel for now while I monitor what people say, as I don't want to risk possibly loosing trancosing.

[tteck]

Also the contents of /etc/groups on the one not working

[David-Moreira]

Sorry about my ignorance, is that supposed to be a folder in the proxmox instance?

[tteck]

cat /etc/groups

[David-Moreira]

I guess you are asking for the groups?

Jellyfin instance of the Backup

root@jellyfin:~# cat /etc/group
root:x:0:
daemon:x:1:
bin:x:2:
sys:x:3:
adm:x:4:syslog
tty:x:5:
disk:x:6:
lp:x:7:
mail:x:8:
news:x:9:
uucp:x:10:
man:x:12:
proxy:x:13:
kmem:x:15:
dialout:x:20:
fax:x:21:
voice:x:22:
cdrom:x:24:
floppy:x:25:
tape:x:26:
sudo:x:27:
audio:x:29:
dip:x:30:
www-data:x:33:
backup:x:34:
operator:x:37:
list:x:38:
irc:x:39:
src:x:40:
gnats:x:41:
shadow:x:42:
utmp:x:43:
video:x:44:jellyfin
sasl:x:45:
plugdev:x:46:
staff:x:50:
games:x:60:
users:x:100:
nogroup:x:65534:
crontab:x:101:
messagebus:x:102:
syslog:x:103:
render:x:104:jellyfin
input:x:105:
sgx:x:106:
kvm:x:107:
ssl-cert:x:108:
postfix:x:109:
postdrop:x:110:
_ssh:x:111:
systemd-journal:x:112:
systemd-network:x:113:
systemd-resolve:x:114:
systemd-timesync:x:115:
uuidd:x:116:
tcpdump:x:117:
jellyfin:x:118:

[tteck]

No issues that I can tell

[tteck]

Keep reading the reddit post, it has a solution that I've not tested. Kernel issue for sure.

[tteck]

Would you mind doing a walk-through here so everyone that has this issue can follow your instructions?

[David-Moreira]

I just followed the https://github.com/intel/compute-runtime/releases instructions but sure, i'll recap

[David-Moreira]

@tteck
Done, feel free to edit the comment if you want to add anything or format it better.
Thanks for your help.

[tteck]

What is the output from ls -l /dev/dri when executed within the Proxmox shell now?

[David-Moreira]

It's still the same. So I guess something changed on that kernel that makes the device name show differently, but seems to have no drawbacks?

The issue that installing the updated compute-runtime supposedly fixes is this :
intel/compute-runtime#710

I can't say I understand much of it, but I guess the passthrough is ok, I assume the problem is something to do with some driver that should be loaded for proper utilization and that is not loaded on that kernel.

[David-Moreira]

Walkthrough for pve kernel 6.8.4-3-pve
(Tested with N100 - Intel QuickSync on a backup instance)

Issue : After upgrading to the kernel mentioned, QSV (Intel QuickSync) stopped working.

Solution:

1. On the proxmox instance install the latest release of compute-runtime (steps below for convenience) : https://github.com/intel/compute-runtime/releases
   1.1. mkdir neo
   1.2.

cd neo
wget https://github.com/intel/intel-graphics-compiler/releases/download/igc-1.0.16510.2/intel-igc-core_1.0.16510.2_amd64.deb
wget https://github.com/intel/intel-graphics-compiler/releases/download/igc-1.0.16510.2/intel-igc-opencl_1.0.16510.2_amd64.deb
wget https://github.com/intel/compute-runtime/releases/download/24.13.29138.7/intel-level-zero-gpu-dbgsym_1.3.29138.7_amd64.ddeb
wget https://github.com/intel/compute-runtime/releases/download/24.13.29138.7/intel-level-zero-gpu_1.3.29138.7_amd64.deb
wget https://github.com/intel/compute-runtime/releases/download/24.13.29138.7/intel-opencl-icd-dbgsym_24.13.29138.7_amd64.ddeb
wget https://github.com/intel/compute-runtime/releases/download/24.13.29138.7/intel-opencl-icd_24.13.29138.7_amd64.deb
wget https://github.com/intel/compute-runtime/releases/download/24.13.29138.7/libigdgmm12_22.3.18_amd64.deb

1.3. dpkg -i *.deb
1.4. Restart proxmox host (unfortunately I did not verify whether it works without restarting, it might)

2. In my case I tested by reinstalling a tteck jellyfin instance
   2.1 bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/ct/jellyfin.sh)"

3. Enable QSV in Jellyfin Playback configuration

4. Here I only had success after restarting the jellyfin instance.
   Some steps for quick testing.
   In the jellyfin instance:
   mkdir /movies
cd /movies
curl -O https://ia601306.us.archive.org/17/items/BigBuckBunnyFULLHD60FPS/Big%20Buck%20Bunny%20-%20FULL%20HD%2060FPS.mp4
   4.1 Add to library and play the video with the quality set to something like 480p
   4.2 Disclaimer that I did not thoroughly test every type of transcoding (tone mapping, other codecs, etc...), this is the only test that I did as I'm leaving my "production" jellyfin instance on kernel 6.8.4-2-pve for the time being.

[tteck]

Thank you

[tteck]

When I find the time, I plan to develop a script (or integrate it into the kernel clean script) to facilitate pinning and unpinning kernels. This way, we'll have a convenient method to revert changes when necessary.

[David-Moreira]

Haha I was actually reading up on this in case I needed to rollback. That'd be nice, yes.

[tteck]

https://helper-scripts.com/scripts?id=tyui8tzzxf5dnnq

[David-Moreira]

Looks nice, I'll try it out later today.
On another note, the new website, can you configure how it looks?

Could use some left margin for the menu on lower resolutions:

[kuchar91]

I found this

It should be "kernel" not "kernal"

[tteck]

The 6.8.4-3-pve (or newer) kernel is needed to use the Ubuntu 24.04 LXC template.

[David-Moreira]

I'm wondering did you make any changes for the transcoding to work or kept it "vanilla"?

[tteck]

I haven't looked at 24.04 for transcoding yet.

[tteck]

You need 6.8.4-3-pve and the compute-runtime fix just to start.

[tteck]

You could share /etc/group to get the ball rolling 😉

[David-Moreira]

I didn't actually try the newest lxc container I was just asking.
I could try it on my "backup" instance, but I already have the compute-runtime fix over there, it would be just to see if everything was ok otherwise...

I'm thinking in skipping 6.8.4.3-pve all together and just see how future kernels behave.