Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[hulkss]

I been experimenting with ROHQ which uses madVR when possible.
How do I see the madVR "statistics" window? I've been trying "ctrl J" but nothing happens ?

[BryanC]

You need to activate the window from the tray icon and then use ctrl-j.

[jmone]

MC is grabbing the ctrl-j key code so you need to have marVR with the focus, another way of doing it is just:
- right click when the video is playing (see if ctrl-j works now)
- right click --> direct show filters --> madVR (see if ctrl-J works now)

I found that once I have it working it always works after that.

[hulkss]

Thanks,

right click --> direct show filters --> madVR

Click madVR window to make it active --> Ctrl+J

[Hendrik]

I would love for the Ctrl-J key to work during playback without tricks and not trigger an update check .... really, why does check for updates have a hotkey anyway.

[Sandy B Ridge]

I would love for the Ctrl-J key to work during playback without tricks and not trigger an update check .... really, why does check for updates have a hotkey anyway.

+1

SBR

[Matt]

It's not the Ctrl+J shortcut that checks for updates (which I agree seems unnecessary).

There's some conflict where madVR stops working after we call RegisterRawInputDevices(...).  Media Center requires WM_INPUT, so we can't really remove that call.

I'm guessing madVR is also using WM_INPUT for some reason, but I don't know why.  It would be better for us if the statistics could be toggled with a custom interface on the madVR control, or if the madVR display window just listened for simple WM_KEYDOWN to avoid fighting with anything else.

I'll send this to madshi and see if he has any advice.

[Hendrik]

Ctrl+R works with madVR (resets its statistics), just Ctrl+J doesn't to toggle the stats.

[madshi]

Actually madVR uses a WH_KEYBOARD_LL hook to get keyboard presses. I know, it's a bit overkill, but anyway. I don't really know why Ctrl+J doesn't work in MC, unless there's somebody else "consuming" this key combination before madVR gets access to it. I plan to make all keyboard shortcuts adjustable in a future madVR version, just didn't get around to doing it yet.

[Matt]

Actually madVR uses a WH_KEYBOARD_LL hook to get keyboard presses. I know, it's a bit overkill, but anyway. I don't really know why Ctrl+J doesn't work in MC, unless there's somebody else "consuming" this key combination before madVR gets access to it. I plan to make all keyboard shortcuts adjustable in a future madVR version, just didn't get around to doing it yet.

I wonder if supporting WM_INPUT (which we must do) breaks WH_KEYBOARD_LL handling?

Would it be possible to also handle WM_KEYDOWN in madVR?  Or to expose the commands through an interface and disable the custom keyboard handling?

I don't think this is specific to Ctrl+J, so allowing user customization won't help.

Thanks for any advice.

[madshi]

Well, nevcairiel just said that Ctrl+R still works, so it seems specific to Ctrl+J. I can only imagine that someone else is already hooking and consuming Ctrl+J, so madVR doesn't see it. FWIW, on my PC Ctrl+J works just fine in MC17.

Since it seems to be specific to Ctrl+J: You do have a Ctrl+J shortcut in MC? Can you try removing it to check if that fixes the problem with madVR? In any case it would be very easy for me to add an alternative key combination in addition to Ctrl+J, e.g. Ctrl+Shift+Alt+F12 or so, until I get around adding key customizations.

I've never used WM_INPUT before, but I have a hard time believing that it totally breaks WH_KEYBOARD_LL. If all else fails we can do a custom interface or whatever else is necessary, but since (according to nevcairiel) the problem is specific to Ctrl+J that shouldn't be necessary.

[Hendrik]

It works on my Dev PC too, but not on the HTPC where i really care.  ? Yet again, Ctrl+R works (just confirmed)
The big difference is that the HTPC has only one screen and has a remote control attached, otherwise i have no idea what would cause the difference.

Edit:
You know what, now it started to work on the HTPC as well.
But apparently i'm not the only one, someone else seemed to have the same problem in this thread. :p

[Matt]

It works on my Dev PC too, but not on the HTPC where i really care.  ? Yet again, Ctrl+R works (just confirmed)
The big difference is that the HTPC has only one screen and has a remote control attached, otherwise i have no idea what would cause the difference.

To test my theory, go into Options > Remote Control > Devices & Options and uncheck all the devices.  Then restart.

I expect this to make Ctrl+J work.

For me, Ctrl+J does not work if we register for WM_INPUT which we do to support remotes and shortcuts.  It is the registering that causes problems, not the handling (because I have tested commenting out all the handling code).

[madshi]

@Matt, do the other madVR key combinations not work for you, either? E.g. try "Ctrl+Shift+Alt+P" to check the source primaries. Does that work or also fail?

[Matt]

@Matt, do the other madVR key combinations not work for you, either? E.g. try "Ctrl+Shift+Alt+P" to check the source primaries. Does that work or also fail?

It's the same deal as Ctrl+J.

It works for the first ~5 seconds of the program run.

Then we call RegisterRawInputDevices(...) and it stops working.

Restarting playback (which reloads madVR) doesn't make any difference.

[madshi]

Bah, that's really bad. So the question is: What to do? I guess I could try a different way of getting the keyboard presses. I'm not sure but I think I had a reason for choosing the solution I chose. I think for exclusive mode I'd have trouble getting the key presses without the hook, but I'm not sure. Of course one option would be to add an interface so MC can feed the key presses to me directly. But I would really prefer if the media player wouldn't have to do so many madVR specific things.

[Matt]

Bah, that's really bad. So the question is: What to do? I guess I could try a different way of getting the keyboard presses. I'm not sure but I think I had a reason for choosing the solution I chose. I think for exclusive mode I'd have trouble getting the key presses without the hook, but I'm not sure. Of course one option would be to add an interface so MC can feed the key presses to me directly. But I would really prefer if the media player wouldn't have to do so many madVR specific things.

I would expect a simple WM_KEYDOWN handler to work.

What happens if you handle WM_KEYDOWN on your main (top-level window) and do this:
if ((wParam == 'J') && (GetKeyState(VK_CTRL) & 0x8000))
{
   ... statistics toggle code here ...
}

This will require the madVR window to have the focus to get keystrokes, but that's pretty reasonable.

[madshi]

My memory says I had already tried this at one point in time and it didn't work as well as expected, but it's so long ago, I don't remember the details. Maybe I should just try that again. There's one complication, though: The next madVR build will have a freeze reporting feature, which can be activated by pressing Ctrl+Shift+Alt+Pause/Break. I fear that if there's a freeze, the madVR window itself and maybe also the media player's GUI threads may be frozen and WM_KEYDOWN is likely to not work, anymore. The hook I'm using now works just fine in these situations because it runs in its own separate lock-free thread.

[Matt]

Would you be willing to handle keystrokes both ways?  Make a shared ProcessKeystroke(...) method, and use a timer to avoid double-handling.

That way, even if we register for raw input (which we have to for some remote support), keystrokes would still work if you had the focus.

Or any other ideas?  It seems like one of us should be able to tune the API parameters we're using to get it working (like using a different HWND), but I'm not sure what.

[madshi]

Yeah, I guess I should be able to add WM_KEYxxx handling, with some extra code to avoid double activation.

[madshi]

The latest madVR v0.81 now does all the keyboard handling in a separate thread. I don't really think it will improve this specific problem, but it's still worth a try. Can you please double check whether the problem still occurs in v0.81? I've not yet added WM_KEYxxx support.

[hulkss]

The latest madVR v0.81 now does all the keyboard handling in a separate thread. I don't really think it will improve this specific problem, but it's still worth a try. Can you please double check whether the problem still occurs in v0.81? I've not yet added WM_KEYxxx support.

Cntrl+J to toggle the madVR stats and Cntrl+R to reset them both work for me now. No need to open the madVR window.

[madshi]

That sounds promising!    Can the others confirm?

[Matt]

That sounds promising!    Can the others confirm?

Unfortunately, v0.81 is working the same for me.

Ctrl+J works on first startup, and then once we bind in for HID messages a few seconds later with RegisterRawInputDevices(...) it stops working.

[madshi]

Oh man. It's weird that it works for hulkss now, but not for Matt. Well, I guess I have to implement WM_KEYxxx support after all.

[madshi]

P.S: @Matt, would it be possible / difficult for you to call RegisterRawInputDevices() before you create the madVR instance? Maybe you could even call RegisterRawInputDevices() at the very start of MC17 and keep it active all the time? I think that might make the madVR keyboard hook work.

The reason I'm suggesting this is that even if I get the WM_KEYxxx stuff to work, if there's a freeze, the thread owning the madVR rendering window will probably be frozen as well, so WM_KEYxxx will stop working when there's a freeze. Which means that the new freeze report feature (pressing Ctrl+Alt+Shift+Break) will not work...   

[Matt]

P.S: @Matt, would it be possible / difficult for you to call RegisterRawInputDevices() before you create the madVR instance? Maybe you could even call RegisterRawInputDevices() at the very start of MC17 and keep it active all the time? I think that might make the madVR keyboard hook work.

This is already how it works.

RegisterRawInputDevices(...) happens a few seconds after running.

If I run, wait a bit, and play with madVR, Ctrl+J never works.

If I run, play right away, Ctrl+J works for the few seconds until RegisterRawInputDevices(...) is called.

I wonder if the API you're using builds on HID messages, and once we ask for the messages, it breaks the hook API you're using?

[madshi]

This is already how it works.

RegisterRawInputDevices(...) happens a few seconds after running.

I think you misunderstood me. I was asking if you could call RegisterRawInputDevices() *before* creating the madVR instance.

If I run, play right away, Ctrl+J works for the few seconds until RegisterRawInputDevices(...) is called.

This clearly shows that you are currently calling RegisterRawInputDevices() *after* creating the madVR instance.

I think there's a chance that my keyboard hook will work if you call RegisterRawInputDevices() before I install my hook, instead of the other way round.

[Hendrik]

Isn't that what he did in his first scenario there? Run MC17, wait a bit, and then play a movie?
Sounds like it to me.

[Matt]

Isn't that what he did in his first scenario there? Run MC17, wait a bit, and then play a movie?
Sounds like it to me.

Yes, exactly.

We don't load madVR until you play something with it.  This makes it easy to test both orderings, which is what I posted above.

[madshi]

Sorry, seems the misunderstanding was on my side. When you said "happens a few seconds after running" I thought you meant "running the graph".

Anyway. Now we have a problem with the madVR v0.81 freeze reporting feature. My keyboard hook still works even if media player and madVR window thread are frozen (I've already tested that), but I'm 99% sure WM_KEYxxx won't work in that situation. So how can we make the freeze reporting work? Any ideas?

[Matt]

Anyway. Now we have a problem with the madVR v0.81 freeze reporting feature. My keyboard hook still works even if media player and madVR window thread are frozen (I've already tested that), but I'm 99% sure WM_KEYxxx won't work in that situation. So how can we make the freeze reporting work? Any ideas?

What if your keyboard handler thread sent a periodic probe message using SendMessageTimeout(...)?  It might allow you to detect freezes without any user interaction.

[madshi]

Hmmmm... I guess I could check whether the madVR window itself reacts to messages? That might be an option... However, I really wanted to have the ability to create freeze reports via keypress because that would allow us to analyze temporarily frozen situations, too, which might not be 100% frozen, just kinda "stuck" for a few seconds or so. Anyway, I guess regularly checking the madVR window might be a workaround.

Hmmmm... How about your HID input? Does that still work if the main, GUI and graph threads are all frozen?

[Matt]

Hmmmm... How about your HID input? Does that still work if the main, GUI and graph threads are all frozen?

Once we register for HID messages, we receive WM_INPUT messages on the main thread.  So if it freezes, we don't get them.

Also, I got a black screen freeze (same as I get often with madVR) last night.  But Ctrl+Alt+Shift+Break isn't working because of this same problem.

[madshi]

Once we register for HID messages, we receive WM_INPUT messages on the main thread.  So if it freezes, we don't get them.

That's too bad. Would it be possible / difficult to move this to another thread?

Also, I got a black screen freeze (same as I get often with madVR) last night.  But Ctrl+Alt+Shift+Break isn't working because of this same problem.

If you can reproduce this problem, can you create an MC build without HID, so that you can create a freeze report?

[Matt]

That's too bad. Would it be possible / difficult to move this to another thread?

When we get some time, we'll play around with how we register for WM_INPUT to see if anything we do makes a difference.  You might do the same on your side with your hook.

If you can reproduce this problem, can you create an MC build without HID, so that you can create a freeze report?

You can turn HID remote support on and off in Options > Remote Control.  I'll turn it off for a while and try to get a report next black screen freeze.  It's sporadic, so it could be a while.

[madshi]

When we get some time, we'll play around with how we register for WM_INPUT to see if anything we do makes a difference.  You might do the same on your side with your hook.

Already did. In v0.81 I moved the whole hook to its own thread with its own message loop and without any locks. I don't think there's more I can do with the hook I'm using. However, I do plan to add WK_KEYxxx handling and probably also implement your SendMessageTimeout idea.

You can turn HID remote support on and off in Options > Remote Control.  I'll turn it off for a while and try to get a report next black screen freeze.  It's sporadic, so it could be a while.

Ah, cool, didn't know that.