New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

madVR Support #52

Closed
Ooglogput opened this Issue Jan 31, 2015 · 9 comments

Comments

Projects
None yet
3 participants
@Ooglogput

Ooglogput commented Jan 31, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Jan 31, 2015

Contributor

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.
Contributor

Et0h commented Jan 31, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Ooglogput

Ooglogput Feb 1, 2015

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?

Ooglogput commented Feb 1, 2015

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

This comment has been minimized.

Show comment
Hide comment
@schoerg

schoerg Feb 1, 2015

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.

schoerg commented Feb 1, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Feb 1, 2015

Contributor

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).

Contributor

Et0h commented Feb 1, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Ooglogput

Ooglogput Feb 2, 2015

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

Ooglogput commented Feb 2, 2015

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

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Feb 2, 2015

Contributor

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?

Contributor

Et0h commented Feb 2, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Ooglogput

Ooglogput Feb 3, 2015

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.

Ooglogput commented Feb 3, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Feb 18, 2015

Contributor

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.

Contributor

Et0h commented Feb 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Jul 7, 2016

Contributor

See #73

Contributor

Et0h commented Jul 7, 2016

See #73

@Et0h Et0h closed this Jul 7, 2016

@Et0h Et0h added the duplicate label Jul 7, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment