madVR Support

[Ooglogput]

As it stands, if you use madVR, other people can play and skip just fine, but they can't pause. I'm pretty sure this is a known issue, but formal reports are always good.

[Et0h]

Yes, it is a known issue and is noted on the troubleshooting page available at http://syncplay.pl/guide/trouble/ ("If you are using MPC-HC and have set the video filter to madVR then you will need to revert to the default filter. madVR is currently incompatible with Syncplay.")

As the issue has yet to be resolved there's nothing wrong with prompting me to give it some further consideration. User reports are a valuable tool to help prioritise the use of limited development resources.

I seem to recall that it was madVR either not listening properly to the MPC-HC API or giving it incorrect information and that we can't make madVR work with Syncplay from our side. However, I will look into:

• The precise cause of the issue, and whether it can be overcome via a workaround within Syncplay;
• Whether this issue has been reported to the relevant MPC-HC/madVR developers, and whether a fix has already been developed;
• Whether MPC-HC can be told not to use madVR with Syncplay (e.g. through a command-line argument), and whether this would cause more problems than it solves; and
• If it is not fixed from Syncplay's side, making it clearer on the Syncplay website that madVR is not supported (or is only supported in newer version of the related software if it gets fixed), and if possible detecting madVR messing things up so Syncplay can give an appropriate warning message.

[Ooglogput]

You can pause the video with through your own Syncplay client though; does that use a different function from when someone else wants to pause?

[schoerg]

madVR has a network interface, from which you can control the clients playback, described in "net-protocol.txt". If the bug is not fixed you could look at this.

[Et0h]

Ooglogput: I'll look into the relevant behaviour to see if I can obtain a better understanding of what is happening. It was a long time ago that it was last investigated.

schoerg: Thanks for the heads up. It could potentially be very useful, although hopefully it won't be necessary to support yet another API (which could result in its own compatibility issues and would need maintaining).

[Ooglogput]

Might also be worth mentioning that MPC-HC's own web interface does work with madVR; at least for everything I've tested.

[Et0h]

I just tried and wasn't able to replicate. Could you please let me know if the problem occurs with the latest version of madVR and MPC-HC. If so, do you have any other changes from the default, e.g. a different subtitle renderer, and if that is disabled does that make a difference?

[Ooglogput]

Latest version of both; I do use xy-VSFilter, but it seems to have no effect. I tried uninstalling madVR, which made it work, with or without xy-VSFilter. With madVR it doesn't work, even without xy-VSFilter. I did make some progress, though, by resetting madVR's settings, and so far it seems to work. I will try fiddling with it and report back.

Edit: It was kind of obvious as soon as I skimmed through the settings. "delay playback start until render queue is full" can't be on, which makes a lot of sense. This would probably be a lot harder to implement support for, and also it's not really that big of a loss to disable it, at least on faster machines. From a quick glance there doesn't seem to be any other setting that would cause the same problem, so it might be worth updating the FAQ with this info.

Also, my bad for not mentioning that it actually does manage to pause the video, but the madVR user will start it immediately again. This is what happens when I take too much time before reporting an issue.

[Et0h]

Thanks for the detective work Ooglogput, I'll look into whether there is an easy workaround, and if I can't get it to work then I'll update the website to let users know of the issue.

[Et0h]

See https://github.com/Syncplay/syncplay/issues/73