Server Version#: 1.32.6.7468
Player Version#: 4.108.0
Sep 11, 2023 21:31:46.262 [140065406950200] ERROR - [Req#72e/Transcode] [FFMPEG] - Failed to initialise VAAPI connection: -1 (unknown libva error).
Sep 11, 2023 21:31:46.295 [140065406950200] ERROR - [Req#72e/Transcode] [FFMPEG] - libva: dlopen of /data/plex/Library/Caches/PlexMediaServer/va-dri-linux-x86_64/radeonsi_drv_video.so failed: Error loading shared library libzstd.so.1: No such file or directory (needed by /data/plex/Library/Caches/PlexMediaServer/va-dri-linux-x86_64/radeonsi_drv_video.so)
As seen above, radeonsi_drv_video.so (downloaded by the server from some mysterious source and not packaged, which I find absolutely unacceptable, but I digress) needs libzstd.so.1, which is not provided by either the download or the libraries from the distribution (using .deb).
And why did Plex switch to musl libc, for crying out loud? Are you actively trying to prevent users from fixing your mess ourselves? FYI AMD has been making graphics cards for quite a while, nor is Linux some weird esoteric platform…
It is Gentoo, but that hardly matters as Plex carries its own operating system^W^W libraries
It is spat out to log whenever transcoding using amdgpu is attempted, in my case Radeon RX 7600S, I can’t try HDR tonemapping when the support is just broken, just getting any transcoding would be a good start I see no point in any logs because:
Looking at rsv-21-linux-x86_64/dri/radeonsi_drv_video.so:
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2’s complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x0
Start of program headers: 64 (bytes into file)
Start of section headers: 49510272 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 11
Size of section headers: 64 (bytes)
Number of section headers: 25
Section header string table index: 24
While some libraries seem to be in place in /usr/lib/plexmediaserver/lib, libzstd.so.1 is not, nor can I find it in the .deb package (in case ebuild didn’t install it for some reason), nor is it downloaded on demand along with the radeonsi_drv_video.so file. I imagine it will be asking for libgallium_drv_video.so next (which is also not there) so please package that as well next time.
Sorry for being slightly annoyed - last time I tried HW transcoding with amdgpu I failed but at least I could try (the problem was in my broken IOMMU/motherboard and stuff), now I finally get a non-broken hardware and discover that Plex has crippled it by switching to musl (which most people don’t run, so no copying of current libraries from the OS like we used to be able to do). I have no idea why Plex packages don’t simply depend on ffmpeg/libdrm/whatever from the distribution where support for new hardware or codecs can simply be plugged or patched in but rather make it a blackbox with crippled functionality. If I had to guess then someone strategically decided “let’s make containers because it’s supposed to be cool now”.
I don’t want you to support my distro. I want you to support your software.
Those libraries and their dependencies have nothing to do with the distro, except for kernel (so feel free to tell me how my kernel tricked your musl libc into thinking it needs libzstd).
Are you telling me that you don’t see libstd.so as a dependency for rsv-21-linux-x86_64/dri/radeonsi_drv_video.so?
Anyway, either you can use the OS and its libraries and then you are free to claim “we don’t support distro XY” because you don’t test that combination, OR you can decide to carry half the OS and libraries with you, thus decoupling it from OS and making it work the same everywhere (within reason), which is what you did. Because by doing that, you took the responsibility of having that stack working, which you clearly don’t. And even if this case was somehow my (distro’s) fault the simple fact that we had to rely on hacks and cobbled-together docker containers to have an actually working HW transcoding on amdgpu and similiar is still on you.
But I actually have to thank you in a way. I decided to take the time, check one little box in Jellyfin and hardware transcoding works there just fine, HDR and all. What a surprise!
the problem with that, which I fought for but didn’t get.
The NAS boxes have vastly outdated GLIBC and required libraries. I wanted to have GLIBC built and included , along with other libs, just as you suggest. Engineering overruled. I still hold out hope to change that.
Plex’s configuration premise is to provide everything needed and be independent of the host OS (almost like AppImage).
What most don’t realize, while the installed package is tiny, there’s a lot more which gets downloaded on first-run (codecs and GPU drivers are an example).
Metadata and posters are the obvious big hitters here.
As a very unhappy owner of a QNAP NAS, I understand the point here somewhat, though I doubt using a more lightweight libc has any benefits besides “it’s betterer”
Right, I get that
I actually didn’t even know about the possibility of something getting downloaded until I hit this bug, I even looked up this in docs and was quite surprised that this was possible and desired https://support.plex.tv/articles/203088737-dynamically-updated-server-components/
In this case, the “driver” download is broken, the radeon driver is linked against libzstd which is not downloaded nor included in the .deb package, so the build environment for those two things is not consistent (I guess the Jenkins build for the Radeon driver has libzstd installed and mesa in that environment wasn’t built --without-zstd). Please pass this along to engineering. It IS broken.
Or, if you at least want to help me, then get me libzstd.so from your build environment and I will “fix” it myself.
