Syncplay crashed while add file to sharedplaylist using MPC-HC

[vikyi]

Describe the bug
When i add file to sharedplaylist, Syncplay will loop try to open the file, then disconnect from server and retry.
And MPC-HC can't open the file correctly.

To Reproduce
Steps to reproduce the behavior:

1. Open the Syncplay client and connect to the server correctly
2. Rightclick the empty sharedplaylist and choose video files or drag files into sharedplaylist
3. See error in the chatbox and then Syncplay will crashed

Expected behavior
MPC-HC open the file correctly and Syncplay run as normal, wait everyone ready

Screenshots
the loop message like this

Version and platform:

• OS: Windows 10 64-bit
• Syncplay version and build type: Syncplay 1.7.1 (Stable)
• Media player and version: MPC-HC 2.1.3.37 (64-bit)

Additional context
MPC-HC using madvr and lav splitter
Only if i set the empty file path will see this bug, like this screenshot

While i give it a filepath, the chatbox will still show warnings, but then i can use Syncplay correctly.

the chatbox warning message

<class 'twisted.python.failure.Failure'>
[Failure instance: Traceback: <class 'syncplay.players.mpc.MpcHcApi.PlayerNotReadyException'>:
twisted\python\log.pyc:80:callWithContext
twisted\python\context.pyc:117:callWithContext
twisted\python\context.pyc:82:callWithContext
syncplay\vendor\qt5reactor.pyc:160:_read
--- <exception caught here> ---
syncplay\vendor\qt5reactor.pyc:153:_read
twisted\internet\tcp.pyc:248:doRead
twisted\internet\tcp.pyc:253:_dataReceived
twisted\internet\endpoints.pyc:151:dataReceived
twisted\protocols\basic.pyc:549:dataReceived
syncplay\protocols.pyc:55:lineReceived
syncplay\protocols.pyc:26:handleMessages
syncplay\protocols.pyc:211:handleSet
syncplay\client.pyc:1823:changeToPlaylistIndex
syncplay\client.pyc:1798:loadDelayedPath
syncplay\client.pyc:608:openFile
syncplay\players\mpc.pyc:410:openFile
syncplay\utils.pyc:79:f_retry
syncplay\players\mpc.pyc:436:setPosition
]
[('', 'syncplayClient.py', 17, (), ()), ('main', 'syncplay\ep_client.pyc', 8, (), ()), ('run', 'syncplay\clientManager.pyc', 16, (), ()), ('start', 'syncplay\client.pyc', 894, (), ()), ('run', 'syncplay\vendor\qt5reactor.pyc', 303, (), ()), ('read', 'syncplay\vendor\qt5reactor.pyc', 166, (), ()), ('callWithLogger', 'twisted\python\log.pyc', 96, (), ()), ('callWithContext', 'twisted\python\log.pyc', 80, (), ()), ('callWithContext', 'twisted\python\context.pyc', 117, (), ()), ('callWithContext', 'twisted\python\context.pyc', 82, (), ()), ('_read', 'syncplay\vendor\qt5reactor.pyc', 160, (), ())]

.syncplay.log

MPV failed with returncode 0.
MPV start failed.
Traceback (most recent call last):
File "syncplay\vendor\python_mpv_jsonipc\python_mpv_jsonipc.pyc", line 462, in _start_mpv
File "syncplay\vendor\python_mpv_jsonipc\python_mpv_jsonipc.pyc", line 218, in init
File "syncplay\vendor\python_mpv_jsonipc\python_mpv_jsonipc.pyc", line 239, in _start_process
syncplay.vendor.python_mpv_jsonipc.python_mpv_jsonipc.MPVError: MPV not started.
(loop)
syncplay.vendor.python_mpv_jsonipc.python_mpv_jsonipc.MPVError: MPV not started.
:259: UserWarning: You are using cryptography on a 32-bit Python on a 64-bit Windows Operating System. Cryptography will be significantly faster if you switch to using a 64-bit Python.
:259: UserWarning: You are using cryptography on a 32-bit Python on a 64-bit Windows Operating System. Cryptography will be significantly faster if you switch to using a 64-bit Python.
WNDPROC return value cannot be converted to LRESULT
TypeError: WPARAM is simple, so must be an int object (got NoneType)
(loop)

[Et0h]

Thanks for letting me know of this issue. I've double checked and can confirm that there is a problem with running MPC-HC (and MPC-BE) without any file.

The MPC-HC code is some of the oldest code in Syncplay and I had very little to do with its development. As such, I'm not entirely sure why the error is happening.

However, having had quick look over the code my best guess is that the issue arises from the code having been written for Python 2, then ported into Python 3, and then we moved to a newer version of Python 3. Also, originally people were generally expected to run Syncplay with the file to be played which was how things worked before shared playlists.

If someone can figure out how to get it to work and makes a pull request containing a fix then we can continue to support MPC-HC and MPC-BE for the timebeing.

Otherwise, it might be time for Syncplay to drop MPC-HC and MPC-BE support and encourage people to use mpv or mpv.net instead as those work far better with Syncplay (not least because they support chat messages and Syncplay commands to be written straight into the player UI).

[Et0h]

I think I've fixed the issue. You can download the latest development build with the patch at https://github.com/Syncplay/syncplay/actions/runs/7732159464 and let me know if it works

P.S. As there is no official Syncplay maintainer for MPC-HC support my recommendation is that people move to mpv/mpv.net (which in any case has better Syncplay integration/support).

[vikyi]

Thanks for your reply. I have tried this 1.7.2 development, but the bug is still exist.
Now I always add an arbitrary file path when I startup the Syncplay client, so that I can use MPC-HC as usual. (However, the filename after username will be unreadable)
If Syncplay update to 1.7.2 stable and drop MPC-HC support. At that time I will choose mpv.

[Et0h]

@vikyi I've hopefully fixed your MPC-HC issue with https://github.com/Syncplay/syncplay/actions/runs/7820071508 - if you still have the issue then tell me precisely which version of MPC-HC you are using. I am using mpc-hc.2.1.3.x64 for testing although just checked https://github.com/clsid2/mpc-hc/releases and there is now a version 2.1.4.

[vikyi]

@Et0h I've test this new version and everything works properly. Thanks for your fix.