Print

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

[Matt]

I installed Windows 8.  Most things work well, but the volume doesn't work on my MCE remote.  It runs the system volume instead of giving Media Center a chance to handle the volume.

This same problem happens on Windows 7 if you install Intellitype.

We're trying to find a solution.

Media Center responds to WM_APPCOMMAND (APPCOMMAND_VOLUME_UP / APPCOMMAND_VOLUME_DOWN).  However, it only receives these when it runs as administrator once Intellitype is installed on Windows 7.  But why?

It's possible to create a shell hook of type HSHELL_APPCOMMAND.  This might catch the key regardless.  But hooks are not ideal, and since our WM_APPCOMMAND works fine until Intellitype is installed (and works even then when running as administrator), why should we have to do this?

I'm hoping somebody might have some clues for us.

[babgvant]

Have you tried handling the remote's input directly? I don't know if that changes anything, but it's lower touch than a hook.

[Matt]

I just tried, and a shell hook gets no calls when pushing the volume keys on the remote or keyboard:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644991(v=vs.85).aspx

Have you tried handling the remote's input directly? I don't know if that changes anything, but it's lower touch than a hook.

We can catch HID commands, but there's no way we've found to avoid double-translating.  In other words, we get the command but so does the OS / Intellitype.


But I'm still confused about why WM_APPCOMMAND isn't working.  This is the right way to handle this stuff, but it's like they decided to break their own rules with the volume keys and not give the application a chance.

[babgvant]

But I'm still confused about why WM_APPCOMMAND isn't working.  This is the right way to handle this stuff, but it's like they decided to break their own rules with the volume keys and not give the application a chance.

Could be a bug.

[Matt]

Could be a bug.

Intellitype has done this for years, and now the same behavior is baked into Windows 8.

[Matt]

And it gets even more confusing.

If we install a low-level keyboard hook (WH_KEYBOARD_LL) and do nothing (other than call the next hook), it makes WM_APPCOMMAND start working again!  So when Intellitype sees a hook, it must start following the rules again?

I'm confused.


(ps. I'm testing Intellitype on Windows 7; it's possible Windows 8 has a different problem)

[babgvant]

Intellitype has done this for years, and now the same behavior is baked into Windows 8.

That doesn't mean that it's not a bug.

[babgvant]

And it gets even more confusing.

If we install a low-level keyboard hook (WH_KEYBOARD_LL) and do nothing (other than call the next hook), it makes WM_APPCOMMAND start working again!  So when Intellitype sees a hook, it must start following the rules again?

I'm confused.


(ps. I'm testing Intellitype on Windows 7; it's possible Windows 8 has a different problem)

It's possible that Intellitype is hooking improperly. I've never tried to detect other LL hooks, but it seems strange to me that this behavior is intentional.

[Matt]

The do-nothing hook fixes the problem with Intellitype on two machines, so we'll make it part of the build.  I'll test Windows 8 tonight at home.

Changed: The keyboard / remote volume keys would not work even when Media Center had the focus on Windows 7 + Intellitype or Windows 8 (seems like a Microsoft bug with a surprising workaround, so feedback appreciated).

It's a weird work-around for a weird behavior.

[Matt]

The do-nothing hook doesn't help Windows 8.

Running as administrator doesn't help in Windows 8 either.

[Matt]

Any and all suggestions welcome.

Not being able to catch volume from a keyboard or remote on Windows 8 is a big problem for users that don't use system volume ( like me ).

[Matt]

I split the discussion about volume modes here:
http://yabb.jriver.com/interact/index.php?topic=75486.0

[fitbrit]

1. Changed: The keyboard / remote volume keys would not work even when Media Center had the focus on Windows 7 + Intellitype or Windows 8 (seems like a Microsoft bug with a surprising workaround, so feedback appreciated).

I thought it was fixed in build 068, but now I see that it was merely changed. I don't understand what was changed though.

[Matt]

I thought it was fixed in build 068, but now I see that it was merely changed. I don't understand what was changed though.

The fix helped Intellitype on Windows 7 but doesn't help Windows 8 (with no Intellitype).

[babgvant]

The fix helped Intellitype on Windows 7 but doesn't help Windows 8 (with no Intellitype).

If you haven't put a call into to MS, it's probably worth a try. At least you'll know the w^5.

[fitbrit]

The fix helped Intellitype on Windows 7 but doesn't help Windows 8 (with no Intellitype).

Thanks for the info. I am on Win7 and was thinking of using Intellitype so I could use Intelliremote. This is good news.

[Matt]

I got a chance to write some code at home tonight to test this more on Windows 8.

It looks like RegisterHotKey(...) works properly for volume keys on Windows 8.  This is really good news.

It means we'll be able to catch the volume keys _always_ on Windows 8, even if we don't have the focus.

With Windows 7 and earlier, you can catch the volume this way but the system still processes it so you get double-volume.

[babgvant]

I got a chance to write some code at home tonight to test this more on Windows 8.

It looks like RegisterHotKey(...) works properly for volume keys on Windows 8.  This is really good news.

It means we'll be able to catch the volume keys _always_ on Windows 8, even if we don't have the focus.

With Windows 7 and earlier, you can catch the volume this way but the system still processes it so you get double-volume.

FWIW, I don't think it's good for you to catch keys when MC's not in focus. I bugged this behavior in MC17 (never heard back, or missed it).

[Hendrik]

If you have a media player running in the background and playing something, it should IMHO catch at least the media keys (Play/Pause/Volume), this is what many people expect to happen.

[babgvant]

If you have a media player running in the background and playing something, it should IMHO catch at least the media keys (Play/Pause/Volume), this is what many people expect to happen.

I disagree with this.

E.g. use case:

- Have MC running to support DLNA streaming
- Open WMC (or SageTV) to watch LiveTV
- MC eats media controls?

The bottom line is that unfocused applications shouldn't handle key presses, it's unneighborly and ultimately leads to poor user experience all around. Applications shouldn't assume that they are the only thing that matters, and that is what they signal when behaving in this way.

[Hendrik]

I said "in the background and playing something"

If i use MC as a music player and use my PC otherwise for browsing, i would hate having to switch back to MC just to lower volume, or skip a track. Why do i have these big media keys on my keyboard if i still have to use the mouse to switch to the application first, and while there might as well just press the button on the UI?

[babgvant]

I said "in the background and playing something"

Yes. I disagree with that design choice. Only focused applications should handle user UI input. While this might seem unintuitive at first, I think it is a much more natural state.

[Hendrik]

While this might seem unintuitive at first, I think it is a much more natural state.

But it destroys the usefulness of the media keys for any kind of music player, which you usually don't keep in focus, because you don't need to.

[babgvant]

If i use MC as a music player and use my PC otherwise for browsing, i would hate having to switch back to MC just to lower volume, or skip a track. Why do i have these big media keys on my keyboard if i still have to use the mouse to switch to the application first, and while there might as well just press the button on the UI?

Because the alternative leads to unpredictable fighting over scarce resources.

Many applications can play audio/video. If they all handle these keys how do I signal to them discretely the behavior I want?

Use case:

- MC plays music
- Watch video in browser
- press mute with browser focused
- press pause with browser focused
- press play with browser focused

In this scenario I would expect the music to continue playing, but if MC is handling unfocused user input that won't happen.

[Hendrik]

I would expect my dedicated media player to handle them, and not a browser. Maybe i'm just too logical. :p I wouldn't press them to control video playback in my browser, i really only use them for music playback while working/developing, and if they stop working in that scenario, thats a big regression for me.

Anyhow, thats why i said it should handle them when its actually playing something. If you play music and watch a video at the same time, something funny is going on anyway.
If you just have MC running to serve DLNA or whatever, but not playing anything locally, it might as well leave the keys for someone else to handle.

[babgvant]

I would expect my dedicated media player to handle them, and not a browser.

Dedicated is a matter of perspective. PC applications run in a shared environment, behaving otherwise is a problem. Stealing focus is a great e.g. of how many applications exhibit improper behavior.

I wouldn't press them to control video playback in my browser, i really only use them for music playback while working/developing.

That was just one use case. I often develop with music (MC) and a soccer match (WMC) going at the same time.

[Hendrik]

In any case, i expect the keys to control my music playback when i'm working, and if they stop doing that, its nearly enough of a reason to use a music player which does that, for me anyway.
And i'm sure there are other people that have a similar use-case.

[Matt]

You can already configure how media keys are handled in Options > General > Media key mode.

Personally I want the keys to always work (they're most useful when I'm _not_ already staring at Media Center), but I understand that some users have different needs here.

[babgvant]

You can already configure how media keys are handled in Options > General > Media key mode.

Personally I want the keys to always work (they're most useful when I'm _not_ already staring at Media Center), but I understand that some users have different needs here.

"Media Key Mode: This setting controls the Media Keys at the top of modern keyboards. The default setting (automatic) should work, but if you are having difficulties, toggle through the other settings here."

Which setting do I choose to handle media keys when MC is focused and ignore all UI input when it's not?

[Matt]

Which setting do I choose to handle media keys when MC is focused and ignore all UI input when it's not?

You should just try the different modes.

App commands are probably what you want, but depending on your OS, keyboard software, and UAC status the behavior can vary.

[babgvant]

You should just try the different modes.

App commands are probably what you want, but depending on your OS, keyboard software, and UAC status the behavior can vary.

Shouldn't the behaviors be documented? It's not a great usability to ask users to figure it out or have an undecipherable matrix.

I can respect that different users want different things, some of which aren't neighborly. That said, I don't think it's a great user story that it's not easy to get MC to play by the usual set of rules.