Generic Keyboard/Remote Input Plugin (2 Viewers)

[enanno]

Hi, I'm using the plugin since January or so, and it has worked very well until now, but since I updated to MediaPortal 1.2.1, I'm having some troubles, and I suppose it has to do with the plugin (I'm using the last version 2.4.3).

The problem is that, in random occasions, when I push the buttons on my remote, they do the real functions for what they were originally programmed.

For example, my remote has a button called "Fullscreen" wich originally send "Alt+Enter" to windows, but I reprogrammed it with the plugin for changing the aspect ratio of movies. The thing is that almost all the times, the aspect ratio is successly changed, but in random occasions, MediaPortal gets "windowed" (because it thinks that I push Alt+Enter).

Any suggestion?

Thank you very much for all your hard work.
Wonderful plugin!!

Edit:

My remote is the showed below, and it has a dedicated thread in the forum (https://forum.team-mediaportal.com/remotes-116/good-mce-remote-w-mouse-9-mapping-included-89908/)

 

[rsenden]

Hi, I'm using the plugin since January or so, and it has worked very well until now, but since I updated to MediaPortal 1.2.1, I'm having some troubles, and I suppose it has to do with the plugin (I'm using the last version 2.4.3).

The problem is that, in random occasions, when I push the buttons on my remote, they do the real functions for what they were originally programmed.

Hi, do you remember which version of the plug-in you were using before upgrading to MediaPortal 1.2.1? I didn't change anything in the keyboard handling code, so key/remote button presses are intercepted in the same way as version 2.4.2. There have been other versions around however that used different key interception mechanisms. It could also be related to changes in MediaPortal itself.

When you're saying it sometimes works, sometimes not, it could be that the keyboard interception handler is temporarily disabled by Windows. Please check the mediaportal.log file for the following line: 'KeyboardInputPlugin: KeyboardHandler seems to be inactive; restarting'. This is a known issue, especially with Windows 7; see https://forum.team-mediaportal.com/...te-input-plugin-25755/index27.html#post626721 for a work-around. If anyone knows a better solution for this, please let me know.

I don't think the following will work for the Alt+Enter combination, but if it is defined as a configurable key mapping in MediaPortal, you can try to modify the key mapping or remove [MP userdata]\keymap.xml to prevent MediaPortal from handling this key combination altogether.

Please let me know whether the above helps; if not, please set your MediaPortal log level to Debug (MP Config->General) and check the mediaportal.log file after you encounter this issue. The plugin logs every key combination that it intercepts, so please check whether it actually sees the Alt+Enter key combo when your issue occurs.

 

[enanno]

Hi, do you remember which version of the plug-in you were using before upgrading to MediaPortal 1.2.1?

When you're saying it sometimes works, sometimes not, it could be that the keyboard interception handler is temporarily disabled by Windows. Please check the mediaportal.log file for the following line: 'KeyboardInputPlugin: KeyboardHandler seems to be inactive; restarting'.

I don't think the following will work for the Alt+Enter combination, but if it is defined as a configurable key mapping in MediaPortal, you can try to modify the key mapping or remove [MP userdata]\keymap.xml to prevent MediaPortal from handling this key combination altogether.

Please let me know whether the above helps; if not, please set your MediaPortal log level to Debug (MP Config->General) and check the mediaportal.log file after you encounter this issue. The plugin logs every key combination that it intercepts, so please check whether it actually sees the Alt+Enter key combo when your issue occurs.

Hi again, thank you for you help, but the problem seems to persist.

I really can't remember the plugin's version I had before updating to MP 1.2.1, sorry, but if this can help you to deduce it, the very first version of MP I installed in my system was de 1.1.3. There, I installed your plugin. And later through months, I updated MP to 1.2.0 alpha, and then 1.2.0 beta, 1.2.0 final and finally 1.2.1 final.

About the line 'KeyboardInputPlugin: KeyboardHandler seems to be inactive; restarting', YES, it does appear sometimes in my mediaportal.log file.

I've just tried removing the "Toggle between gui and fullscreen" action in keymap.xml as you told me, but it hasn't worked either.

And I've also tried the regedit hack you linked, without success.

I attach my debug View attachment 92700 file and my View attachment Keyboard.xml file.
The actions in the log file are:

1. Open MediaPortal
2. Push Left button and then Enter button to enter in Videos
3. Push Down button twice and then Enter button to choose and enter in "Peliculas" folder
4. Push Right button and then Enter button to choose and play "El origen del Planeta de los Simios (2011) [480p].avi" video
5. Push Fullscreen button to change the aspect ratio of the video, and it works as desired.
6. Push Fullscreen button again but MediaPortal or your plugin -I don't know- catch the real code of the button, which is "Alt+Enter", and because of that, MediaPortal gets windowed.
7. Close MediaPortal as I close any window.

Sorry if I extened myself too much.
Hope we can find a solution.
Thank you!

View attachment 92700
View attachment Keyboard.xml

 

[rsenden]

Hi Enanno,

Did you reboot after the registry change? If not, please do so and retry.

I can see that the plugin captures the first Alt+Enter; on the second Alt+Enter it detects that the keyboard handler is disabled and as such could not capture it. I guess if you would press Alt+Enter multiple times after that, it will again sometimes be handled by the plugin, sometimes by MediaPortal itself. Currently the only known work-around is the registry hack unfortunately.

I think the plug-in could be improved to prevent the keyboard hook time-out. Currently all processing (looking up the key mapping and actually executing the related action) is done on the same thread as the keyboard hook itself. In order to improve this, the following steps should be taken:

• Add functionality to InputHandler to store all mapped keycodes in a simple HashSet for quick lookup, and add a method IsMapped(keycode). For performance reasons, we could ignore conditions (e.g. once a key is defined in the mapping, the plugin will always 'eat' it independent of whether it is actually mapped under the current conditions).
• KeyboardInputPluginMain.KeyboardHandler_KeyPressHandler currently calls _inputHandler.MapAction, which will both look up whether there is a mapping for the given key/button code, and if so, execute the corresponding action. This should be changed such that actually executing the action is performed on a separate thread. So, the relevant code in KeyboardHandler_KeyPressHandler could for example look something like this:

  bool isMapped = InputHandler.IsMapped(keycode); 
  if ( isMapped) { postToActionThread(keycode); }
  return isMapped;

Unfortunately, I lack the C#/.NET experience needed to quickly implement the threading mechanism (and I don't have time to delve into this). Anyone willing to help implement this? The source code can be found in the MP-Plugins SVN at https://mp-plugins.svn.sourceforge.net/svnroot/mp-plugins/trunk/plugins/KeyboardInputPlugin/ (see https://forum.team-mediaportal.com/mediaportal-plugins-47/plugin-development-svn-15863/ for information on getting write access).

 

[Markos]

I think the plug-in could be improved to prevent the keyboard hook time-out. Currently all processing (looking up the key mapping and actually executing the related action) is done on the same thread as the keyboard hook itself.

The real issue is not that the plugin is slow. The keyboard hook timeout is long enough to process the lookup, this has been discussed many times.

What actually happens is that when Windows is low on resources, it starts to page data, which occurs in thrashing. Even if the plugin processes each message in few milliseconds, the thrashing can cause mediaportal to stop responding for few seconds. If that happens, windows decides to stop posting messages (without even knowing that windows' paging mechanism itself caused the slow response).

If you want to read little bit more about this, check winapi - Did MS change something about keyboard hooks in Windows Vista or 7? - Stack Overflow and the top answer.

 

[enanno]

Did you reboot after the registry change? If not, please do so and retry.

Thank you again, and yes, I did it.

What you explain would be a good solution. I'm really a Computer Science Technician Engineer, but I don't have time enough to learn all about MediaPortal, plugins, etc. programming. What I don't understand is why it perfectly worked before, and now don't.
I would get back to MP 1.1.3, but... you know, f-ing spare time... I wish a day could have 48 hours.

By the way, my Fullscreen button is just an example. The issue is happening with many other buttons in my remote, like for example the Enter button which I use to Pause/Play Live TV and Movies... it will show the mini-guide sometimes. This is simply annoying.

The real issue is not that the plugin is slow. The keyboard hook timeout is long enough to process the lookup, this has been discussed many times.

What actually happens is that when Windows is low on resources, it starts to page data, which occurs in thrashing. Even if the plugin processes each message in few milliseconds, the thrashing can cause mediaportal to stop responding for few seconds. If that happens, windows decides to stop posting messages (without even knowing that windows' paging mechanism itself caused the slow response).

Really???
It's very weird. Because I haven't change anything recently in my system.
And my system isn't so bad, you know...and this happens all the times (even after booting).

 

[1stdead]

enanno: just want to say that this has happened to ever since i changed from vista to win7. So in all versions i had this problem.

 

[enanno]

enanno: just want to say that this has happened to ever since i changed from vista to win7. So in all versions i had this problem.

I am on Win7 x64 since the first day.
Never happened this.

 

[1stdead]

You're just been lucky then

 

[rsenden]

I think the plug-in could be improved to prevent the keyboard hook time-out. Currently all processing (looking up the key mapping and actually executing the related action) is done on the same thread as the keyboard hook itself.

The real issue is not that the plugin is slow. The keyboard hook timeout is long enough to process the lookup, this has been discussed many times.

What actually happens is that when Windows is low on resources, it starts to page data, which occurs in thrashing. Even if the plugin processes each message in few milliseconds, the thrashing can cause mediaportal to stop responding for few seconds. If that happens, windows decides to stop posting messages (without even knowing that windows' paging mechanism itself caused the slow response).

The problem is that the hook gets disabled even when Windows is not low on resources. I've done some more testing; I actually already implemented the faster key mapping lookup and temporarily disabled actually executing the action. This results in the keyboard hook being disabled less frequently, although still quite often. It looks as if the hook gets disabled whenever a key is pressed while MediaPortal is doing 'something' (for example while loading a new screen).

According to LowLevelKeyboardProc callback function, the hook is called in the context of the thread that created it by sending a message to that thread. As I don't do any thread management myself in the plug-in, I guess the hook is installed in the main MediaPortal UI thread. Could it be that MediaPortal blocks the message queue while 'doing' something, resulting in the hook not being called in time?

Maybe we could install the hook in a separate thread, with its own message loop? However, I'm not sure on how to implement that, and whether that would actually work. For example, maybe each thread will then handle key presses independent from the other, resulting in a situation that MediaPortal still sees the key press on the main thread even when it was handled by the hook in the second thread?

I'm no Windows expert (usually I only do Java development), so I'm just guessing here...