View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002430 | MMW v4 | Other | public | 2006-03-18 21:07 | 2022-04-29 01:07 |
Reporter | peke | Assigned To | |||
Priority | immediate | Severity | trivial | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 3.1 | ||||
Target Version | 3.1 | Fixed in Version | 3.1 | ||
Summary | 0002430: Handling Multimedia Keyboard APPCOMMAND_MEDIA Keys sometimes misses | ||||
Description | With Genius KB-19e Multimedia Keyboard which have SEARCH button. When SEARCH Key is pressed MM reacts and opens Search Form, but also Windows opens its search form. Note: MM is on Top. On some keyboards even Standard Next key is not recognized when MM is not in focus, also Advanced APPCOMMAND_MEDIA_* keys do not work. | ||||
Additional Information | Example App and source is on FTP And MiscAPI.pas should be corrected and updated merged with UnitRawInput.pas from example app. http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=1176 http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=980 http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=2064 | ||||
Tags | No tags attached. | ||||
Fixed in build | 1243 | ||||
related to | 0003841 | closed | rusty | MMW v4 | Multimedia Keyboards are not working correctly |
parent of | 0005972 | closed | Ludek | MMW v4 | Party Mode: Prevention from switching to another app no longer works (regression) |
has duplicate | 0002495 | closed | rusty | MMW v4 | Firewall (Zone Alarm) can cause MM to crash and/or not rip tracks correctly |
related to | 0003916 | feedback | rusty | MediaMonkey Addons | Command line App that control MediaMonkey Player |
related to | 0004305 | closed | rusty | MMW v4 | Shortcuts are Triggered in Edit Mode |
related to | 0004962 | closed | rusty | MMW v4 | Modify KB article re. Multimedia keyboard workarounds |
related to | 0005259 | closed | Ludek | MMW v4 | MediaMonkey fails to start on Win2K (regression) |
related to | 0004369 | closed | Ludek | MMW v4 | Global hotkeys stop working after locking & unlocking (regression) |
related to | 0005517 | closed | Ludek | MMW v4 | Multimediakeys repeat 2-3 times on some systems |
related to | 0000388 | closed | Ludek | MMW 5 | MMHelper.dll sometimes prevents uninstallation/installation (regression in MM5) |
related to | 0003279 | closed | Ludek | MMW v4 | back and forward mouse buttons should work for navigating |
related to | 0006257 | closed | Ludek | MMW v4 | Pause/Break key can't be used as hotkey |
related to | 0006616 | assigned | Ludek | MMW v4 | HID: Sometimes RAW HID codes are assigned instead of actual Key code |
|
Assigning to Peke, check out what exactly is going on. |
|
I need to get that keyboard for test from friend of mine. Then I'll make more though tests with it. |
|
According to MS and handling multimediakeys MM do not handle Application message completely and by the specs which results in double handling of keys like search. Will make list of all needed keys and fix it. |
|
MM do not handle keyboard commands/events like it should especially in Minimized mode, also there is no MM support for APP_Commands, remote controlers, Virtual Scrollers (Some touch pads, Drawing pads/boards), HID,... Another reason for making Global hook is the ability to make Service application that will make all needed keyboard hooks for MM and also will make ability that MM be supported in Limited accounts and multiple account environments. Second reason is that several MM users reported that they had problems with their firewalls and Anti-Virus softwares that complained on MM. Which Will be avoided if used this way. Lots of applications use that features thrum Service Hook (Cyberlink, Ahead Nero Home, ATi MMC,...) and it is fully supported for WinXP and above and recomended for use in Win MCE and Vista. Source and example application is sent To Jiri on review and finding way how can we use it. |
|
Most recent Forum Topic regarding issue: http://www.mediamonkey.com/forum/viewtopic.php?t=22117 |
|
Assign to Ludek if needed. |
|
Reminder sent to: jiri, rusty What will be state of this after MM3 release. There is increase of bug reports which will be solved by solving this? I have added [2430] to several topics on Forum. |
|
Related issue: MultiMedia Keys stop working when USB drive is powered off, if MM is playing Description: I store all music on a portable hard drive connected through USB to the monitor’s hub. When I leave the computer I turn of the screen’s power which cuts the power to the portable hard drive (portable device still connected but powerless). MM is still running and looses connection to hard drive. When I power the screen again, it is not possible to use the play/pause/next/prev keys on my keyboard. If MM is restarted, the keys will work again, without a reboot of the computer. However, if I stop playing the music before powering down, but keep MM running, it is possible to use the buttons after the drive has connected once powered up again. This is my system: Win XP Pro SP2 2 GB internal memory 200 GB internal hard drive 250 GB external, WD Passport II DELL 20” Wide Monitor with built-in USB hub diNovo Edge Keyboard MediaMonkey 3.0.1.1127 (Gold) |
|
I do not think it is related to This bug but rather windows Management of available devices and Device Status availability in Keyboard Hooks. Never the less it is very possible that fixing this issue it will be possible that we will not have problems with this due to nature of fix. |
|
I have updated My util on SVN until this issue is resolved and add additional support to Labtec Keyboards and possibly to all keyboard drivers that do not support parsing Command line Parameters in Custom Configuration. Reference Forum Topic post: http://www.mediamonkey.com/forum/viewtopic.php?p=123877#123877 |
|
Raising priority to immediate due to the number of issues cropping up related to this. We need to either: a) include a fix in 3.0.2 b) put together a single faq article that makes it easy to understand how to fix this Peke, is it possible to do b) ? Or is it just not simple to get it working? |
|
Current Hotkey management can't support HID hook and Raw WM_INPUT. Until we were able to completely revise Our Hotkey Management I've completed small Application that will watch only multimedia keys that current hotkey management do not handle and making different Key Hook for making and completely solve issues with Hotkeys and Anti Virus warnings. |
|
SVN Updated With Latest Sources Of hidhook App. Rusty, Please can you revise Icon File Supplied so that I could Change it accordingly to needs of plugin or leave it as is? Note: I changed icon Color to be different than MMs. To-Do: 1. Setup Sheet so that user can Initiate key learn on Windows XP/MCE and 2000 as they can't accept background WM_APPCOMMANDS, which is most likely limited to Vista+. |
|
Fixed and Added Option Sheet to "Tools -> Options -> General -> Multimedia Hotkeys" so that Windows 2000/XP Users can Assign key even their Systems do not support Extended Background APPCOMMAND_MEDIA commands introduced with Vista Notes: 1. Not tested under Win98SE but it should also work 2. This is basic Implementation that support only basic Extended commands PLAY, PAUSE, FASTFORWARD, REWIND (fyi. PLAY/PAUSE in Single Key is handled differently) and there is functions we can also support/use in futture (see UnitRawInput.pas) 3. This is standalone fix the longer and stable approach would be to implement new revised Hotkey Engine that will not raise Anti-Virus Applications warning that MediaMonkey Wants to log keyboard and mouse inputs. 4. When Learn ??? Key is used on user can make hotkey with custom key code specifically made for that device which windows do not recognize yet. |
|
Integrated directly to MM in build 1200. |
|
No changes, Implementations of HID hook do not Work and none of my remotes are detected. |
|
Should be fixed in 1201, but I have only one keyboard to test. Jiri and Peke are going tro test it. |
|
Added complete APPCOMMAND handling in build 1202. |
|
Build 1202: added more default APPCOMMAND hotkeys: Media Play, Media Pause, Media Fast Forward, Media Rewind. Build 1203: Fixed: APPCOMMAND and HID keys works only if are defined as global. |
|
Testing in 1202 1. Several Actions Missing: Multimedia: Play Multimedia: Pause Multimedia: Fast Forward Multimedia: Rewind Multimedia: Volume Up Multimedia: Volume Down Multimedia: Volume Mute Multimedia: Record 2. All extended VKey keyboard Codes are not detected (If you need more info I'll be glad to provide screenshots from App I have sent you) 3. HID Raw codes are not translated to common recognizable codes (Check What Codes are Reported by my app as that codes are generated better to determine Key Down/Up) 4. HID Raw Codes detection also Detect Key up which Result in unavailability of assigning keys due the fact that Key Up is mostly same unless they are translated (like in 3.) 5. Keyboard Arrows are detected as NUM 8,2,4,6 and not as arrow keys. 6. On XP ZoneAlarm Still complain about Low Level Keyboard/Mouse Hook it looks that A is still initialized even there is no need for that. |
|
- LLHook for Party Mode: I have investigated, it should be easy to Prevent System keys handling thru VKey Codes by setting handled. |
|
1. They are there as: Playback: Play Playback: Pause Playback: Skip 5 seconds Forward Playback: Skip 5 seconds Backward (these 4 are dafault) Playback: Volume Up Playback: Volume Down Playback: Volume Mute Tools: Burn CD/DVD 2. Fixed in 1203. 3. Yes, I use combination of Device ID and HID code ID as a hash value (ID Hotkey), I don't think that user need to see the <Device ID, PIO, CODE> triple. Just one ID hash is enough. 4. Fixed in 1203. 5. Fixed in 1203. 6. No, A (Low level keyboard hook) is not initialized. Maybe C (shell hook for WMAPPCOMMAND handling) causes this. Could you test 1201 where WMAPPCOMMAND was not handled and see if 1201 works fine on XP ZoneAlarm. If that works in 1201 then it is the WMAPPCOMMAND handling. |
|
Mostly it seems to work fine. Some issues: 7. Some multimedia commands have 'Media ' prefix and others don't (e.g. 'Stop' vs 'Media Pause'. I mean hotkeys, not actions here. 8. Some IR keys still produce that effect of blinking text in Hotkey edit line. For example pressing 'Previous' IR button shows: 'HID key id: 123' for 0.1 sec and then it correctly shows 'Previous'. 9. I'm not sure whether this is on purpose and whether it was in MM 3.0, but bringing focus to Hotkey edit line causes the current shortcut to be removed, i.e. the line is cleared. Shouldn't it better stay there? 10. 'Multimedia: *' actions are still present, they should be mapped to existing 'Playback: *' actions, as discussed offline. |
|
11. As indicated in 1: Playback: Volume Up Playback: Volume Down Playback: Volume Mute are missing from default hotkeys. They should be added as non global default hotkeys. 12. If Playback: Volume Up is not defined and MM is on top then it doesn't take effect and no longer shifts the master volume, reported also here: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=34951 |
|
7. 'Stop' exist in VKey and 'Media Pause' is only mapped thrum APPCOMMAND I'm guessing that is why they are added that way to evade confusion. |
|
I agree with Jiri that actions should be the same (item 10. ), but I agree with Peke that the hotkeys names need to be differentiate (item 7). |
|
7. Why would they need to be different? E.g. that example above ('Stop' vs 'Media Pause') looks weird. I'd suggest to name all these playback related keys as 'Media *'. We could also leave 'Media' word out, but I'd rather keep it there, since some hotkey titles ('Next', 'Forward') could be confusing without it. |
|
7. You are right, adding Media as prefix should cover all. |
|
Issues 7,8,9,10,11,12 fixed in build 1203 too. |
|
Confirming that the issues I reported work fine now. Few more minor issues: 13. Cursor remains at weird positions in Hotkey edit line. E.g., if I press 'Up' key, the cursor is shown correctly after 'p' character. If I press 'Down' key then, cursor is shown between 'o' and 'w'. It should probably always be after the last character? Any other idea? 14. 'Ctrl' (and others) key isn't remembered. If I press and hold 'Ctrl', then press '1' and then press '2' (while still holding Ctrl), there is only '2' shown, instead of correct 'Ctrl+2'. 15. 'Ctrl' (and others) key isn't registered with Media keys, so it isn't possible to press 'Ctrl+Media Play' (at least not of AC messages). I think that it's technically possible and could be useful sometimes. |
|
16. When assigning hotkey to "Browser back" MM execute action and return focus to Library Tree Node |
|
Fixed issues 13,14,15,16 in build 1204. |
|
Brief testing shows that it all seems to be working fine on my machine. |
|
17. when assigning "Browser search" to hotkey Search form is shown. 18. When Virtual Key $FF (KEYBOARD OVERRUN CODE) is detected, Extended code contain Hotkey value for two byte hotkey. pressing Pause/Break key contain one of those extended VK_ codes. Also Keyboard Power key Contain KEYBOARD OVERRUN CODE($FF)+$5E (extended code) if we want to block turning off PC in Party mode, WakeUp from stanby uses $FF+$63,... Same thing goes with CTRL+ALT+DEL. I'll see to Modify My catcher app to catch all extended codes. |
|
13, 14, 15 fixes verified in 1204 16. 1204 Not fixed, "Browser Back" is still executed while Assigning hotkey |
|
16, 17 fixed in build 1208. Re: 18: In party mode we still prevent from using system keys by using Low Level Keyboard hook. I guess that CTRL+ALT+DEL can't be protected by using KEYBOARD OVERRUN CODE. I use another trick (implemented in 0003475). |
|
19. There are some issues on W2k and MM keyboards and W2k -> XP wrapper should fix that see http://win2kgaming.site90.com/phpBB2/viewtopic.php?f=6&t=7 |
|
20. Some additional LOG Msgs should log what Method is successfully Registered (eg. RIDEV_EXINPUTSINK, RAW_Input, RIDEV_INPUTSINK, ...) when MM initializes Hotkey Engine |
|
Re: 20) I added several debug messages: 'Hotkeys: Going to install hotkeys hook:' and then 'Low Level Keyboard Hook installed successfuly' 'RIDEV_INPUTSINK registered successfuly' 'RIDEV_EXINPUTSINK registered successfuly' 'RIDEV_INPUTSINK failed' 'RIDEV_EXINPUTSINK failed' In addition I added a hidden config 'PreferLLKeysHook'. If you add PreferLLKeysHook = 1 to the [options] section of MM.INI file then Low Level Keyboeard hook is preffered. Added in build 1213. Re: the problem on Win2K, did they try to learn MM the hotkey via Options -> Hotkeys and hitting the key? Does MM obtain the key? |
|
There have been several complaints in the forums about broken multimedia keyboard functionality. Would it be worth buying e.g. an MS keyboard to test? http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=37882 http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=22117 |
|
I do not have any Issues With MS Keyboards, The only issue maybe due the fact that intellitype does not See MM as registered media application and thus it does not send Media Commands. I just tested MM on ACER Laptop 7250 and ACER Driver correctly sees MediaMonkey as media application. The only thing missing is that Play/Pause, Next, Prev, Stop needs to be reapplied, after which all is working correctly even with MM in Background. But like I already stated it is Windows XP issue not MMs if we want to it right way. Ludek, is MediaMonkey Main form registered to Receive HID commands or we do it from separate thread in background? I would only change that if user click on Hotkey name it is cleared which will indicate that MM is waiting new key, which will then applied only if Apply is Clicked and while not apply is clicked Hotkey Name should be in different color than saved one so that users see key is not yet applied. |
|
Reminder sent to: peke Peke, no, MediaMonkey Main form is not registered to Receive HID commands, we use the thisWnd window handle from InstanceManager.pas Do you think it could be the reason why intellitype does not See MM as registered media application and thus it does not send Media Commands? Does your test app work fine with intellitype? If yes I could change the window handle to the Main Form's handle. |
|
Rusty, based on the last Peke's note it look likes we should add this to doc/help. Currently media monkey understands various key codes and therefore the keys needs to be sometimes reapplied as Peke wrote, this way MM "learns" this key codes in order to understand them later. In order to learn MM the key code you need to go to Options -> Hotkeys and type the shortcut. I also agree with Peke that the need to click [Apply] and then [Ok] in Options dialog is quite user unfriendly. This way I several times didn't change the hotkey although I wanted, but I forgot to click the [Apply] button. It would be more intuitive if just hitting [Ok] would do the think (without need to hit [Apply]). Or as Peke suggested there should be a sort of indication that the hotkey has not been applied when user tries to click [Ok] button. If you agree then open a new issue for this. |
|
As discussed over IM: a. It really doesn't work on my MS 4000 keyboard, at least not with MM default hotkeys. It can be configured in Options. b. We should properly map APPCOMMAND messages to VK codes, so that there won't be any need for user to configure this. Ludek will implement b. |
|
Implemented in build 1230. |
|
Tested and works correctly on MS 4000 keyboard (after a clean install of MM). |
|
Re-opening based on user tests at: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=37882 |
|
Added more debug messages that could clarify this strange issue until I buy the same keyboard to test or until Jiri is available with his MS 4000 keyboard. Debug messages added in build 1242. |
|
I have tested the keyboard (Microsoft Ergonomic Natural Keyboard 4000) and there is an issue with the supplied software (MS IntelliType Pro). The app eats the APPCOMMAND messages and MM doesn't get them. There is surely a bug in the software, because if you kill the iType.exe process then everything works fine. Also WinAmp 5 doesn't react on the Play/Pause key at all until the iType.exe process is killed. I was able (by using a trick) to fix this when MM is in minimized mode (fixed in 1243), but when MM is in system tray or as MicroPlayer then I cannot do more, because MM just doesn't get the play command, the IntelliType app eats it and strangely enough transforms it to "activate app" message that causes MM to be restored from system tray. The problem is that iType seems to filter the APPCOMMAND_MEDIA messages and sends them only to registered applications and if iType finds that no media application is active in order to receive the message (e.g. when MM is in the system tray) then it seems to send the "activate app" command instead of the APPCOMMAND_MEDIA message which causes another instance of MM to launch. So the only full solution that I see is to uninstall IntelliType or assign the macro as the software offers. This should be added to our KB articles. |
|
Ludek as you already have keyboard that observes the issue Can you check how iType.exe process is acting when using with WMP? |
|
It is acting same way as with MM, because both WMP and iTunes don't have the ability to be hidden in system tray so it works like when MM is minimized or maximized, but e.g. Winamp 5 has problems with iType even if is maximzed. Note that you don't need the keyboard to test, just install MS IntelliType Pro and any keyboard with the Play/Pause media key should act same way. |
|
I found the reason why iType translates it. It simply do not find Window (it do not search for hidden windows) and Send App start to open Media Application just like when mediamonkey is not started it sends App start and MM start up. It is not our issue and should be considered closed. Anyway I'm not completely sure but after 3.1 is out I will test if App start could be intercepted like I've done in maximize issue inside http://www.ventismedia.com/mantis/view.php?id=5442 bug, as that approach would not MM go back to front when receives App start. |
|
Verified Fix with iType regarding Minimized mode in 1244 |
|
Cheek seems to be true that the conflict with iType driver is a kind of regression, see: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=37882&p=203815#p203815 MM 3.0.3 worked with iType even if MM was in system tray. The reason is that we used Low Level keyboard hook in the versions prior to 3.0.6. But we had some reasons to not use the LLKeysHook. There is a hidden config in MediaMonkey.ini file. Adding PreferLLKeysHook = 1 to the [options] section of MediaMonkey.ini file will prefer Low Level Keyboeard hook and the hotkey will work like in MM 3.0.3 It looks like we should consider all pros and cons and decide whether LLKeysHook shouldn't be preffered by default: ------------------------ Here is a summary of the methods that we uses for this purpose, together with their problems: A) Low level Windows keyboard hook (WH_KEYBOARD_LL) - that's what we have used up to MM 3.0. Generally speaking it works fine, just: A1. It's a low level hack, for example some antivirus apps don't like it. A2. Are there other problems, like not detected keys. B) Raw input WinAPI - that's what we have just added to MM 3.1. It seems to work well so far, possible problems are: B1. It doesn't seem to add more functionality to MM that A) does. Although it can intercept data for things like remote controls (via HID key codes), it doesn't really understand them - they needs to be set in options. Really well working default processing depends on C). B2. It's a little higher level than A), which causes problems with the MS IntelliType driver as described above (see my note 0017684) B3. It's only WinXP+, for older systems we uses A). C) Receiving WM_APPCOMMAND message. It notifies about special multimedia related actions, like Play/Pause button press. We use it starting from MM 3.1, e.g. for some remote controls, this seems to be the only way how to work. How do we use these methods? In MM 3.0 we use A) In MM 3.1 we use C) in combination with B) and for Windows versions prior Win XP (or with the PreferLLKeysHook = 1) in combination with A). Question is, shouldn't we try to use combination of A, B, C ? Probably too late at this point if we want to have MM 3.1 as stable as possible, but on the other hands I think the combination of A,B,C should work like this A) would be used for common VK keys. B) would be used for raw HID keys (some remote controllers require this) C) remain for APPCOMMAND messages But as discussed offline A) is low level hook that has many disadvantages. => We should add KB article that would explain how to solve the conflict with MS IntelliType app. Eventually we could add an MMIP that would contain a small script that would modify MediaMonkey.ini file in order to enable Low Level Keyboard hook. i.e. The only known problem is that media keys don't work when MM is in system tray and iType is running. Possible solutions are: a) Uninstall IntelliType PRO (or remove iType.exe from RunOnce registry via RegEdit). This way all Media Keys will work as expected. b) Add value PreferLLKeysHook = 1 to the [options] section of MediaMonkey.ini file c) Assign macro as IntelliType PRO offers. Run the app, select Play/Pause from the keys list and click the [Assign/Manage Macro...] button. Assign e.g. 'Ctrl+P' as macro and make 'Ctrl+P' as global hotkey in MediaMonkey options. Note that you don't need the MS 4000 keyboard to test, just install MS IntelliType Pro and any keyboard with the Play/Pause media key should act same way. Resolving for now with todoc tag. |
|
More to doc at: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=36208&start=30 http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=43492 |
|
Re-Verified 1378 |