For anyone wondering why this is out of date.
I've been trying to make the latest version of plex-desktop work here. But sadly have an issue with it getting stuck at the first loading screen with no error logs anywhere. If anyone can help out, please do! They have updated FFMPEG, MPV (and maybe QT) and their forks are no longer binary compatible with the arch packages, requiring the use of the forked versions included in the package.
(The same issues are valid for plex-htpc since they're essentially the same app)
Pinned Comments
mrgrim commented on 2024-10-01 05:16 (UTC) (edited on 2024-10-01 05:20 (UTC) by mrgrim)
The Qt 6.7 problem is an issue where
xdg-open
inherits the environment of the Plex app causingkde-open
to try to load the Qt 6.6 libraries from/opt/plex-desktop/lib
due to theLD_LIBRARY_PATH
set inPlex.sh
.This can be solved by editing the
RUNPATH
of the binaries usingchrpath
then removing theLD_LIBRARY_PATH
line fromPlex.sh
. It turns out The main Plex library has a workingRUNPATH
but includes a bunch of automation cruft. The transcoding binary does NOT have it set, andQtWebEngineProcess
needs no changes. In/opt/plex-desktop/bin
run:However, this only exposes additional issues with all of the Qt environment variables set in this script. I couldn't find a super clean way to fix this, but interestingly enough KDE uses a little utility for their AppImage deployments to deal with this exact problem:
https://invent.kde.org/brauch/appimage-exec-wrapper/
Compile it and copy the
exec.so
file into/opt/plex-desktop/lib
then alterPlex.sh
like this:https://gist.github.com/mrgrim/1357da402f8ceccaf8224e145fa6acc3
This could even allow using
LD_LIBRARY_PATH
and not usingchrpath
. The choice is yours. Usingchrpath
seems cleaner but pulls in a dependency.