[cyborg5]

I recently created a small webpage that communicates with kodi using JSON-RPC. It's just a simple remote control with arrow keys, play/pause, fast-forward, rewind etc. I made it because existing web interfaces do not get along sorry about that is that very well with my dictation software Dragon NaturallySpeaking which I use because of my disability. My custom webpage is working well but I'm surprised that it works differently than keyboard commands. Here are just a few of the things I've noticed…

1. During playback, pressing left arrow or right arrow on the keyboard makes the video jump backwards or forwards 30 seconds. This is really handy skipping commercials when playing back PVR recordings. However when using arrow keys via JSON-RPC it doesn't work.

2. During playback pressing the key "i" for "info" brings up the OSD. One of the things visible in the OSD is the time at which the current program will conclude. However calling up the OSD using JSON-RPC does not include this feature.

There may be other inconsistencies that I haven't discovered yet. I suppose what I would really like is the ability to send keystrokes using JSON-RPC rather than having to use web sockets. The JSON method is much easier to implement in plain-vanilla JavaScript and HTML. Web sockets are a little bit beyond my skill level.

[Montellese]

This is a design decision that some people made a while ago. The problem is that sending a key (e.g. "i") instead of an action (e.g. "info") results in Kodi checking the keymap and resolving the keypress to an action. Therefore the resulting action depends on the keymap and that is a very odd thing for a well defined API where behaviour should be as deterministic as possible and independent from any user-specific settings.

PS: Using WebSockets won't change anything concerning the behaviour of JSON-RPC (except that you also receive notifications) but they are very easy to use nowadays with JavaScript. If you really want key presses you need to use the EventServer but that's purely UDP based and won't work from regular JavaScript.

[cyborg5]

I can understand not wanting to implement keypresses through the JSON-RPC as a design decision. My real issue as the subject of this message says is the inconsistency. The way to bring up the on screen display using keypresses is to press "i" and the way to bring up the on screen display is to call the "Input.ShowOSD" method. But those give different results depending on whether you do keypress or method calls. Similarly with the arrow keys causing a 30 second jump in the video. They ought to work the same course assuming you haven't redefined the keypresses. The default behavior should be the same. It's inconsistent.

I thought that if I used web socket I would be able to send keypresses from JavaScript. Thanks for telling me that it cannot be done. I would've wasted a lot of time trying to figure it out. Of course that's just all the more reason that we ought to be able to somehow simulate the keypresses or have the behavior be consistent.

[Montellese]

That's odd. The OSD is simply a dialog implemented by the skin and all that JSON-RPC's Input.ShowOSD does is issue the action that opens the OSD which should be the same as used by the keymap.

But I think the confusion is about what the OSD is. To bring up the OSD you need to press Enter, Return or "m" in the fullscreen video player which is the same you will get when using Input.ShowOSD. Pressing "i" opens up the info dialog and for that you need to use Input.ExecuteAction with the "info" action.

[Montellese]

Moved the thread to the JSON-RPC development board.

[cyborg5]

… you need to use Input.ExecuteAction with the "info" action.

Ah-ha!! I did not see all of those Input.ExecuteAction options available. I'm using a package called JSON-RPC browser v. 0.92 browse around the commands. When I looked at the Input class I saw that it had up, down, left, right commands directly and then I saw that there was the ExecuteAction method and there was a drop-down list that showed the commands within that. I thought it was just a different way to do up, down, left, right and did not see that there were 20 or 30 different sub commands under ExecuteAction. Among the ones I now see there that I had missed are the "stepforward" and "stepback" commands which solves my other problem regarding 30 second jumps for skipping commercials.

It's going to make my user interface a little more complicated because pressing the right arrow on a keyboard will move a menu selection to the right when not playing and will skip forward while playing however the Input.ExecuteAction.right command only works when not playing and Input.ExecuteAction.stepforward only works while playing. I'm either going to have to switch to web sockets so that I can get return information to know if I'm currently playing or not I'm going to have to implement my menu right arrow in my skip forward commands separately. For now I think I will just add separate buttons on the webpage for skipping and for navigation. Later when I have more time I will dip into web sockets and notifications.

I knew there had to be some way to do this. I just couldn't figure out what it was. I should've look deeper into Input.ExecuteAction.

I'm not sure how you do it, but you can mark this thread "Solved".

[Tolriq]

Be careful as someone can display the OSD or the full interface while the media is playing and then you should send normal left and not player left

And currently it's complicated if not impossible to know if osd is displayed over the player.

I really wish Kodi team changed it's mind and understand why being able to send keyboard and / or remote codes is wanted and normal so users have a consistent experience.

Event Server is working for that but having to use 2 interface for the same purpose is well not optimal at all.

And to quote montellese :

This is a design decision that some people made a while ago. The problem is that sending a key (e.g. "i") instead of an action (e.g. "info") results in Kodi checking the keymap and resolving the keypress to an action. Therefore the resulting action depends on the keymap and that is a very odd thing for a well defined API where behaviour should be as deterministic as possible and independent from any user-specific settings.

The fact is that if the user have changed it's keymap so it does something specific he perfectly know it and wanted it so he want the behavior to be consistent with all his remoting controls.

It's the remote maker job to label the button i and not info so the user know what will happens, but this is not normal to prevent users to get the keymap configuration or to use it.

If you really do not want for obscure reason to allow users to use the configuration they chose at least open the api so remote makers can read it to apply it (even if not 100% possible due to some configuration that are not known by remote makers).