SyncPlay AppImage not working with Mpv (Latest versions) on Manjaro

[EnderCrypt]

Describe the bug
When launching SyncPlay with MPV as the media player, it crashes with this gui error message:

Media player error: "MPV process retry limit reached." The reason mpv cannot start may be due to the use of unsupported command line arguments or an unsupported version of mpv.

To Reproduce

1. Install SyncPlay and MPV
2. Configure Syncplay to use MPV
3. Click connect
4. Observe error message dialog

Expected behavior
No error message and a functional SyncPlay session.

Screenshots

Version and platform:

• OS: Manjaro (Linux) [latest version]
• DE: KDE Plasma 5.24.5 [latest version]
• Syncplay: 1.7.0-Beta1 x86_64 (AppImage) [latest version]
• MPV: 1:0.34.1-4 [latest version]

Additional information
Strace log of Syncplay when pressing the "Run syncplay" button: https://pastebin.com/SRNaBu7w

[Et0h]

I just tried the latest Windows build of mpv at https://sourceforge.net/projects/mpv-player-windows/files/64bit/mpv-x86_64-20220619-git-c1a46ec.7z/download and it ran with Syncplay fine. Is mpv running for you fine if you run it separately to Syncplay?

[EnderCrypt]

Good day, yes mpv seems to work perfectly fine alone, both launching it alone and dragging files in, aswell as double clicking files to open with mpv and other methods, i seen no errors or issues with this (including in the terminal), only when trying to play from inside the syncplay session.

i also wanna note that i also have problems with VLC, albeit slightly different type of problem
while VLC works perfectly fine outside of syncplay, if i try to use it as a player to syncplay, at first all seems to work, it opens up.
but the moment i add a .mp4 to SyncPlay playlist, i get this message from VLC itself:
Codec not supported: VLC could not decode the format "h264" (H264 - MPEG-4 AVC (part 10))
i was planning to, but had not made a an issue post about this yet (i assume that it is a different issue and so will make an post separately about it, but it MAY be related to this issue so probalbly a good idea i mentioned it here first)

its possible that i lack certain libraries and such perhaps.. although i cant think of what, considering both mpv and vlc work perfect while launched standalone

a few other details which may or may not be relevant:

• this machine is rather freshly installed, its less than a week old (both the hardware and software)
• i used SyncPlay alot on my previous computer, also with Manjaro Linux and had none of these issues
• the SyncPlay server im using is quite old, i set it up on one of my 24/7 comptuter i ages ago and havent really touched it since then (possibly years back)

[EnderCrypt]

btw, in the log (pastebin in my first post), it mentions

/usr/bin/mpv: symbol lookup error: /usr/lib/libgobject-2.0.so.0: undefined symbol: g_atomic_rc_box_release_full
MPV failed with returncode 127.
MPV start failed.

and looking at the code for that message:
https://github.com/Syncplay/syncplay/blob/master/syncplay/vendor/python_mpv_jsonipc/python_mpv_jsonipc.py#L239

this whole failure to launch was most likely caused by return code 127, now doing a quick google on this exit code shows:

127 - command not found
but it can also mean that the command is found,
but a library that is required by the command is NOT found.

and looking at the top line, mpv was found, and when it tried to load the required library "/usr/lib/libgobject-2.0.so.0" it failed with an error from the library:
undefined symbol: g_atomic_rc_box_release_full

also, when i did run SyncPlay under strace, it did not detect that it did execute the mpv binary, this all seems to imply that while syncplay DID try launch mpv, mpv never actually got started due to that library error

[daniel-123]

I've failed to encounter the issue on my machine (Debian Unstable) with latest Syncplay AppImage/deb and both master/latest release of mpv. This would possibly narrow down the issue to some interaction between our AppImage build and Manjaro?

Or possibly mpv build in Manjaro somehow differs from what I'm geting from mpv-build

[zocker-160]

the issue is caused here

syncplay/syncplay/vendor/python_mpv_jsonipc/python_mpv_jsonipc.py

Line 221 in f555c1d

self.process = subprocess.Popen(args, env=env)

where env is getting passed to the subprocess command.

ENV on Manjaro inside the Appimage contains LD_LIBRARY_PATH which in my case points to appimagepath/usr/lib.

That on the other hand (when used for calling mpv) causes mpv to crash, because it cannot find libgobject-2.0.so.0 which obviously is not part of the Appimage.

Unsetting that variable by adding del env["LD_LIBRARY_PATH"] after line 220 and before subprocess:Popen solves this issue.

[frei0]

I'm facing a similar issue. I think it may be a regression after #432.

By bundling libgthread-2.0.so.0, libglib-2.0.so.0 is also automatically bundled, but not the rest of libglib, for whatever reason. I'm still not exactly sure how AppImage decides what to bundle. If I remove -l /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 from appimage-script.sh it stops bundling libglib-2.0.so.0.

The bundled libglib-2.0.so.0 prevents the system libglib-2.0.so.0 from being used. Then, when system libgobject is loaded, it wants some symbols that should be in system libglib, but cannot be found in the bundled libglib:

 % LD_DEBUG=bindings mpv 2>&1 | grep g_atomic_rc_box_release_full
    130303:     binding file /lib/x86_64-linux-gnu/libgobject-2.0.so.0 [0] to /lib/x86_64-linux-gnu/libglib-2.0.so.0 [0]: normal symbol `g_atomic_rc_box_release_full'
    130303:     binding file /lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 [0] to /lib/x86_64-linux-gnu/libglib-2.0.so.0 [0]: normal symbol `g_atomic_rc_box_release_full'
 % LD_DEBUG=libs ./Syncplay-1.7.0-Beta1-x86_64.AppImage 2>&1 | grep libglib-2.0
    130451:     find library=libglib-2.0.so.0 [0]; searching
    130451:       trying file=/tmp/.mount_Syncpl6mK5Tb/usr/lib/libglib-2.0.so.0
    130451:     calling init: /tmp/.mount_Syncpl6mK5Tb/usr/lib/libglib-2.0.so.0

I think the fix here is to either bundle all of the libraries in the libglib package, (libgio, libglib, libgmodule, libgobject, libgthread) together, as they are usually distributed together, not separately. Or not bundle any of them, but then we have a missing dependency on some systems again (#431).

[Et0h]

Unsetting that variable by adding del env["LD_LIBRARY_PATH"] after line 220 and before subprocess:Popen solves this issue.

We tried to fix the Manjaro LD_LIBRARY_PATH issue along those lines with #546 but it ended up creating other problems.

[Et0h]

I think the fix here is to either bundle all of the libraries in the libglib package, (libgio, libglib, libgmodule, libgobject, libgthread) together, as they are usually distributed together, not separately. Or not bundle any of them, but then we have a missing dependency on some systems again (#431).

As @teohhanhui produced #432 it might be helpful for them to offer a view on the proposal from @frei0.

(I am a Windows user so generally leave it to @daniel-123 and others to comment on Linux-related matters.)

[daniel-123]

@EnderCrypt can you try an AppImage built in newer environment? There is a few in result of this action. I'm particularly hopeful that the one built on Ubuntu 20.04 will work, but the 22.04 might also be a second option worth checking.

[notdysthymia]

Has this issue been resolved or at least anyone came up with a solution? I just downloaded the AppImage (v1.7.0 b1) in my Linux Mint 21.1 Cinnamon. Whenever I also install it via terminal, and clicked Run Syncplay with a video and mpv set, I also encounter the same message.

Media player error: "MPV process retry limit reached." The reason mpv cannot start may be due to the use of unsupported command line arguments or an unsupported version of mpv.

Take Note: I'm really new to Linux and I switched from Windows due to my laptop being slow nowadays. I've been using Syncplay on Windows and I don't think I've encountered this before with MPC-BE.

UPDATE: It seems that installing Syncplay 1.6.9 is another solution as of now in order for the app to work properly.

[Et0h]

I am closing this issue because Syncplay has now discontinued AppImage support. See: #643 for more details. If an issue recurs with the Deb package or Tarball then please re-open this comment and let us know of the details.