Plexmediaserver libcuda and nvidia transcoding

@tamas IIRC you were at Plex? are you still able to influence the snap package at all?

The plexmediaserver snap cannot perform nvidia-based transcoding because it doesn’t know where libcuda.so.1 is located. This file is accessible from /var/lib/snapd/hostfs/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/libcuda.so.1. The directory is not listable by the snap, but it can read libcuda from that location without any additional plugs. Therefore it seemingly needs either a symlink or an LD_LIBRARY_PATH override to allow plex to see it?

HTH.

for reference, here is the error that it prints to the log:

Oct 02, 2021 10:44:28.745 [0x7f8b8279cb38] ERROR - [Transcode] [FFMPEG] - Could not dynamically load CUDA
Oct 02, 2021 10:44:28.746 [0x7f8b8279cb38] ERROR - [Transcode] [FFMPEG] - Failed to initialise VAAPI connection: -1 (unknown libva error).
Oct 02, 2021 10:44:28.746 [0x7f8b8279cb38] ERROR - [Transcode] [FFMPEG] - Cannot load libcuda.so.1

Host system is Ubuntu 21.04 (server) with nvidia-headless-470 as the driver package installed.

$ snap version
snap    2.51.7
snapd   2.51.7
series  16
ubuntu  21.04
kernel  5.11.0-37-generic
1 Like

Thanks for highlighting that. I’ll file an internal issue and look into it when I can (no promises on ETA).

1 Like

thinking on this, the library location will be dependant on the host os, if not ubuntu. I’m unsure where the correct location is on other systems. Might be worth getting snapd devs involved to get a well-known location for the library implemented.

aha. snap-confine is making a well-known location for the libraries at /var/lib/snapd/lib/gl. This looks to be added to LD_LIBRARY_PATH in your command-plexmediaserver.wrapper script (from SNAP_LIBRARY_PATH), so I’m unsure why the transcoder isn’t picking it up…

This might be a snapd bug - the gl directory is empty from within the snap:

$ snap run --shell plexmediaserver
$ ls -l /var/lib/snapd/lib/gl
total 0

looks like this might be my fault. I’ve been digging in and looking at the code of snap-confine. When deciding to mount the Nvidia libraries it checks for the presence of libnvidia-glcore.so.?, which isn’t installed by the headless packages. You can get the library with the Debian package libnvidia-gl-470. There is also a libnvidia-encode-470 package that can be installed.

I went with the -headless packages because I didn’t want nor need the x11-related packages explosion. I suspect this is a popular way to set up Nvidia on a server, so maybe the headless packages should depend on these two extras.

1 Like

@tamas, I wanted to ask you, if you’re refactoring or changing some of the snap logic, would it also be possible to migrate the snap to core18/20? This would also give you the ability to use the latest desktop extensions. I can help, of course :slight_smile:

Yeah, sooner or later we’ll have to move to one of the new base images because we are running snapcraft in legacy mode still. Can you share some docs about the desktop extensions that would be useful to use with PMS?

This is the documentation:

And this is the list of current extensions:

1 Like

Thanks. On a first glance none of these look like they would be useful for PMS. or am I missing something? (not that I’m against updating the base, we’ll have to do it anyway as I stated above).

Hey @tamas, they would be useful in ensuring you keep consistency and simpler set of dependencies you need to maintain for PMS. Thus, if you need themes, icons, certain libraries or environment variables, or to align with releases of GNOME or KDE, you can do that with the extensions declarations.

Another bonus can be the slimming down of the actual snap, which can help with your end users.

PMS is a server application, it doesn’t need to align with any kind of DE (in fact, it runs completely headless).

Reducing the size is a tangible bonus but given that we don’t depend on a desktop environment, do extensions really help with that?

I thought this may apply to some of the labs extras, or potentially community plugins. But if everything is done server side, you won’t then gain as much. But you may still some benefits, perhaps environment variables, plugs declarations, etc.