Install Jellyfin without HW transcoding

[orsib78]

Hello.
Is it possible to run the jellyfin script without the HW transcoding part?
The script failed to run on my Supermicro X11SCL-F motherboard, because this MB disables the IGPU and uses the GPU of the management interface instead (which is a joke). However during installation the script tries to use this GPU to install the transcoding part and as a result it fails. Is there a way to execute the script without the HW transcoding commands?
Thanks,
Balazs

This is the output of the script:

    __     ____      _____     
  / /__  / / /_  __/ __(_)___ 

__ / / _ / / / / / / // / __
/ // / / / / // / / / / / /
_/_///_, // /// //
/___/
🧩 Using Advanced Settings on node pve
🖥️ Operating System: ubuntu
🌟 Version: 22.04
📦 Container Type: Unprivileged
🔐 Root Password: ********
🆔 Container ID: 107
🏠 Hostname: jellyfin
💾 Disk Size: 8
🧠 CPU Cores: 2
🛠️ RAM Size: 2048
🌉 Bridge: vmbr0
📡 IP Address: dhcp
🌐 Gateway IP Address: Default
📡 APT-Cacher IP Address: Default
🚫 Disable IPv6: yes
⚙️ Interface MTU Size: Default
🔍 DNS Search Domain: Host
📡 DNS Server IP Address: Host
🏷️ Vlan: Default
🔑 Root SSH Access: no
🔍 Verbose Mode: yes
🚀 Creating a Jellyfin LXC using the above advanced settings
✔️ Using local for Template Storage.
✔️ Using local-zfs for Container Storage.
✔️ Updated LXC Template List
✔️ LXC Container 107 was successfully created.
⠴/dev/dri/renderD128 is not a device
⠦
[ERROR] in line 875: exit code 0: while executing command pct start "$CTID"

[cricalix]

There's one workaround I can find - use advanced settings and change to a privileged container. The logic in build.func around line 830 checks whether the host even has that device before trying to configure it in the container if privileged is selected. If unprivileged is selected, the logic assumes the device exists and passes it through.

A PR could probably be created to add the same detection logic that exists for privileged to unprivileged. The config file won't get the devices that way and start should work. This should not cause any grief for the various install scripts, as they only try to change permissions on the /dev/dri* stuff, not use it - the commands will error, but the error can be ignored.

[orsib78]

Hello.

That's not that simple in my case. As I mentioned my Supermicro MB has some kind of (garbage) GPU, embedded into the ARM IPMI chip which is exposed to the OS, while the IGPU of the CPU is disabled by design. So the the /dev/dri folder indeed containing something, but nothing jellyfin could ever use. The solution would be to update the script, so I can select in the advanced settings whether I want HW transcoding or not (regardless the container is privileged or unprivileged). Anyway, here is the output of the ls dev/dri* command:

root@pve:~# ls /dev/dri*
by-path card0 renderD128

Thanks,
B.

[cricalix]

Ah bother, no, apologies. I read the code backwards. Unprivileged checks whether /dev/dri/renderD128 is present, privileged doesn't. Still needs a PR for that I think, because the script should not assume all machines always have the IGPU (or other) available.

That said, privileged does use the optional flag, so the container starts. You could also try an Advanced Settings installation, take all the defaults, but make the container privileged. It should complete successfully and boot up. I will note that on my installation, I did that to test, and forgot I'd passed the device through to a VM. Accessing it from the container (even though it wasn't present in the host due to PCI passthrough) apparently caused a kernel panic - the PVE host dropped from the network, as did all containers and VMs.

[cricalix]

Hello.

That's not that simple in my case. As I mentioned my Supermicro MB has some kind of (garbage) GPU, embedded into the ARM IPMI chip which is exposed to the OS, while the IGPU of the CPU is disabled by design. So the the /dev/dri folder indeed containing something, but nothing jellyfin could ever use. The solution would be to update the script, so I can select in the advanced settings whether I want HW transcoding or not (regardless the container is privileged or unprivileged). Anyway, here is the output of the ls dev/dri* command:

Yeah, that's going to need to be a PR I'm sure, because the tooling assumes "hey, the device is there, make it available". So unprivileged sees the device, mounts it through.. but then it's not available? That's weird (the not a device bit is freaky weird). Gotta love hardware.. (I've got an AliExpress board, and let's just say the BIOS is unique).

[orsib78]

Thanks. BTW, the reason I'd rather "insist" on the unprivileged container is that I'm planning to expose this container to the internet, so I can access jellyfin remotely. Although it may still a bad idea even the container is unprivileged. What do you think?

[cricalix]

Thanks. BTW, the reason I'd rather "insist" on the unprivileged container is that I'm planning to expose this container to the internet, so I can access jellyfin remotely. Although it may still a bad idea even the container is unprivileged. What do you think?

Depending on your view on privacy and security, you might want to consider using a VPN on both the container and the client. VPN options I'd consider are wireguard and Tailscale; with the latter being a web UI and other tooling around the former, making the key distribution easy. You can even run your own Tailscale headend via https://github.com/juanfont/headscale. Doing that bypasses any need to punch holes in the firewall of your home router.

Depending on your home router (I use Openwrt on a Raspberry Pi 4), you can put wireguard/tailscale there instead, and connect the client to that, making your whole home network available.

If you're unaware, wireguard and tailscale are based on public key infrastructure; no passwords. Each side has a private and public key, and knows the public key of the other side. There's no concept of a VPN server as such, it's all peer to peer. You keep the private keys secure.

Edit: Exposing Jellyfin .. well, now you're "on the hook" for any bugs in Jellyfin's security. Containers can be escaped from, so my preference would be to never expose any services in my home network to the wider internet directly, and instead rely on a private network built on something like wireguard.