Kodi Community Forum
JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+---- Forum: JSON-RPC (https://forum.kodi.tv/forumdisplay.php?fid=174)
+---- Thread: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC (/showthread.php?tid=68263)



RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - tanzirc - 2012-08-02

So I guess only way to get actorID is to still run SQL query on the database directly. I will try that later.

Also, is there anyway to write a JSON call to match specific property in the param, like the use of "WHERE" in an sql query? For example, if I want to pull a movie with title "XYZ" on a VideoLibrary.GetMovies call, is it possible to do so?

Thanks!


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-08-02

(2012-08-02, 14:08)tanzirc Wrote: So I guess only way to get actorID is to still run SQL query on the database directly. I will try that later.
JSON-RPC won't allow you to run arbitrary SQL queries.

(2012-08-02, 14:08)tanzirc Wrote: Also, is there anyway to write a JSON call to match specific property in the param, like the use of "WHERE" in an sql query? For example, if I want to pull a movie with title "XYZ" on a VideoLibrary.GetMovies call, is it possible to do so?

Not yet but have already started working on something like that.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-08-02

(2012-08-02, 13:48)Tolriq Wrote: I'm sorry but I must disagree on this one.
Users sets keymaps and use them afterwards so each user know perfectly what key does what action they do on his installation.
You have to remember that xbmc is primarily developed to be used with a remote and not a full keyboard. The custom keymaps are there to allow users to map certain actions to specific keys and then map those keys to some key on their remote.

(2012-08-02, 13:48)Tolriq Wrote: I do agree that remote makers for show OSD or known commands must use the send action. But for advanced user (those same that to use personal keymaps) showing a keyboard for direct access to what they choose to do is much more logical.
I would call myself an advanced user and I'd prefer a few customly defined buttons (ideally with a useful label) on a remote over a full keyboard where I have to remember which action is mapped to which key anytime. Much easier to remember that the button labelled "Show OSD" opens the OSD instead of having to remember that pressing "O" will open the OSD IMO. Sure those custom buttons require some work on the client side but IMO that would be much more user-friendly.

(2012-08-02, 13:48)Tolriq Wrote: A user that is tell to copy a custom keymap for a specific addon will do that but don't really understand what he do.
Giving the user a very complex interface so that he type the command like : Addon.OpenSettings(script.xbmc.boblight) (don't even know if it does work in current implementation).
And I don't talk about the complexity of developing such interface to present a beautiful interface for end user.
Something like that example (Addon.OpenSettings(script.xbmc.boblight)) won't be possible over Input.ExecuteAction and I don't plan to add support for it either because there's no way to do some sanity check before executing such an action. What I meant by providing the user with a configurable interface was that you provide them with buttons that do not have any action applied and then they can choose from a list of available actions (which can be extracted from the introspect of Input.ExecuteAction) and apply those actions to the available buttons. That way there's no need for the user to type in some complex command or having to create a custom keymap.

(2012-08-02, 13:48)Tolriq Wrote: And of course you loose the use of physical phone keyboard (This one is also true for the SendText that can't do direct keyboard to dialog with backspace support).
This is more work for user to start a dialog to put a text send it. Then realize there's an error, and retype it completely. (Yes I can let the old text for next try but then if it's a new dialog the user have a manual action to clear text).
Yesterday I merged a PR which will provide you with the current value of the currently active input box in the Input.OnInputRequested notification. So there's no need for you to remember anything. When you receive the notification pop up the virtual keyboard (or let the user use the hardware keyboard) and let him alter the value of the input box. When he's done he presses Enter (or whatever) and you use Input.SendText to send the text to XBMC. If the user then realizes that he made a mistake he can focus the input box again and just change whatever was wrong with the first value.




RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-08-02

(2012-08-02, 11:08)tanzirc Wrote: Hi there,

I am trying to retrieve Movie information with JSON RPC using the following command:

Code:
xbmc.executeJSONRPC('{"jsonrpc": "2.0", "method": "VideoLibrary.GetMovieDetails", "params": {"movieid": %d, "properties": ["title", "studio", "mpaa", "plot", "genre", "year", "runtime", "streamdetails", "rating", "tagline", "director", "writer", "fanart", "thumbnail", "file", "trailer"]}, "id": 1}' % ( self.ID, ) )

I get all the information except "streamdetails", which just returns an empty string. I have looked at the SQL database "myvideosxx.db" to check whether the stream details were extracted during the library scan, and found that they do exist in the "streamdetails" table. However the JSON call of "streamdetails" still returns an empty string.

I am using the latest nightly build (Pre-Frodo) on mac os x lion.

Am I doing anything wrong in the JSON call? Please help!

Thanks,
tanzirc

I have just merged the PR that fixes this issue so it should be working again soon.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Tolriq - 2012-08-02

So there will be no way to add command like this in custom keymaps.

The sample I give is clearly a common use case, this is the only way to get Boblight configuration during a movie play to activate / disable the addon.
And there's plenty of other samples this is a one of the most (if not the most) common reason for custom Keymaps.

Limiting the ExecuteAction to a very limited sets seems like a big regression over EventServer.

99% of standard commands in remotes use the same action and already have buttons for them (like OSD, ...) the problem is all the others. If you kill EventServer in the current configuration you also kill lots of functionality in all remotes.

I won't debate about making a 100% custom interface with button labeled as Show OSD on a small phone screen and making this beautiful usable this is not the point.
Or the textbox over a direct keyboard to screen since it's personal point of view.

A little about notifications, on phones / tablets all is about speed / battery usage. And from a widget point of view having a permanent thread waiting for notifications is clearly a non sense you can't start stop register to xbmc on each screen on / off.
While this is the correct way to work with a full remote that is started / closed there's some case like widgets and some other where notifications and synchronous work is not suitable.

But the final point is that it's not because Xbmc was not targeted to use full keyboards or X or Y that users don't have them and like to use them, this is one of the beautifulness of Xbmc to allow users to get the max of their installation, and by wanting to limit a lots on inputs and don't give alternatives you definitively kills a big plus of Xbmc.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-08-02

(2012-08-02, 16:56)Tolriq Wrote: So there will be no way to add command like this in custom keymaps.

The sample I give is clearly a common use case, this is the only way to get Boblight configuration during a movie play to activate / disable the addon.
And how many of all the people using xbmc use boblight? Most likely not even 1 in 1000. Adding functionality that can cause problems in the xbmc system to cover a feature that very very very very ... few people use is not the right way IMO. It's not like I have something against Boblight or anything else that requires custom keymaps and I'm arguing against this out of malice but for me making sure that a client cannot accidentally crash xbmc or force it into an unexpected state is more important than just throwing in a lot of features that only few people use.

(2012-08-02, 16:56)Tolriq Wrote: Limiting the ExecuteAction to a very limited sets seems like a big regression over EventServer.
As JSON-RPC is not a replacement for the EventServer it's not a regression. In the input area JSON-RPC simply only implements a subset of the features of the EventServer. One of the main ideas behind JSON-RPC is to be able to control/sanitize the actions that can be performed. With the HTTP-API you can do almost whatever you want (custom SQL queries, execute any action, ...) and you can break a lot of things when using it wrong. In JSON-RPC the whole JSON schema stuff is the first guard against unintended commands/actions being performed because it checks the provided parameters for validity. Once I get time to work and finish the permission system there will be an additional guard against remote clients doing something that the xbmc user doesn't want it to. I/We always try to find a good tradeoff between limiting the functionality available to remote clients against the security and robustness of the xbmc system.

(2012-08-02, 16:56)Tolriq Wrote: 99% of standard commands in remotes use the same action and already have buttons for them (like OSD, ...) the problem is all the others. If you kill EventServer in the current configuration you also kill lots of functionality in all remotes.
Who is talking about killing the EventServer? I certainly won't because it's used for many remotes AFAIK.

(2012-08-02, 16:56)Tolriq Wrote: A little about notifications, on phones / tablets all is about speed / battery usage. And from a widget point of view having a permanent thread waiting for notifications is clearly a non sense you can't start stop register to xbmc on each screen on / off.
While this is the correct way to work with a full remote that is started / closed there's some case like widgets and some other where notifications and synchronous work is not suitable.
Well IMO a widget should never need a full keyboard or anything like that. It's a widget i.e. I place it on one of my homescreens for fast access to simple actions and not to control the world. Furthermore most widget (at least the ones I use) are listeners with callback methods like the music player widget which changes when a new song is played so it either needs to listen to when a song plays or it needs to register with a running app to be notified when something changed. So there's something going on in the background as well. A thread sleeping until a tcp socket has something to read will most likely not drain your battery (depending on how you implement it).

(2012-08-02, 16:56)Tolriq Wrote: But the final point is that it's not because Xbmc was not targeted to use full keyboards or X or Y that users don't have them and like to use them, this is one of the beautifulness of Xbmc to allow users to get the max of their installation, and by wanting to limit a lots on inputs and don't give alternatives you definitively kills a big plus of Xbmc.
We don't limit those inputs, you can still do that using the EventServer. JSON-RPC is an attempt on a (more or less) clean and easy to use API.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Tolriq - 2012-08-02

Well it seems I misunderstood some things when we discussed about support Unicode for EventServer, I was persuaded that EvenServer will be deprecated at one time.

If it's not the case then there's no problems I can just up the trac ticket i made for EventServer so : http://trac.xbmc.org/ticket/12678 (to refresh with discussion here : https://github.com/xbmc/xbmc/pull/675) to drop need for Http counterpart.

And for Keymaps, it's by itself an advanced feature, and if you use it there's 100% chance that you use advanced commands, perhaps just simple one like ActivateWindow(shutdownmenu).
This would have been great to have better integration of all those in JSON for addons controls from remotes.

About Widget it's a little more complicated, a widget by itself in android does not exist this is a RemoteView. You create the view and send it to the launcher. Then the app behind should close and use an alarm manager for example to update later. Of course if the app that play songs runs it can update the widget. This wont consume anything since there's already a wakelock to play the music.

To have a thread listening all times you need to keep Wifi full on and have wakelock to get data this is consuming a lot of battery if no need, you can of course stop start the thread non stop but it's cpu consuming to start a thread then register if the widget is wake up only for 1/4sec due to any user interaction and you'll loose most of the notifications Smile

And of course a widget should not show a full keyboard but a widget as you say have the small needed actions, like left right select sended via Event Server no need for threads or heavy tcp just a little udp packet.
But if Xbmc shows a dialog when the user navigate from the widget (or from their infrared Remote) they can start the full app to fill the dialog, but it's then clearly too late to have the notification so this is no use to detect if dialog or not in this case.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - RobertMe - 2012-08-02

When starting to use the widget you can set up the TCP tocket, send the command over it, and close it after some time, so you would still be able to receive the notification. And in case you were talking about some "real time input" case in one of your first comments, nobody prevents you from calling SendText every time the user presses a button. Just make sure you don't set the "ok/done" flag, as it would otherwise close the dialog (which is the default). And you're also able to use SendText whenever you want, not only after OnInputRequested and before OnInputFinished. So you could as well show the user the keyboard somewhere so he could send text at will. Of course in that case you wouldn't be able to show the correct keyboard (time picker, for example), but the user would still be able to send the text whenever he wants.

A request continuing on this discussion. Would it be possible to have the lists handle SendText? So you would be able to "fast scroll" in a list? So when your browsing the video library you could just press (/SendText) a Z and the list would automatically scroll to the Z.

And another question (/request). Player.GetItems contains a list of subtitles, but I guess those are only the ones which are available, right? Would it be possible to also fetch the list of subtitles which can be downloaded using the subtitle plugin? And/or trigger the automatic download of a Sync subtitle whenever one is found, the same as the Subtitle button does when you're watching a video.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-08-02

(2012-08-02, 20:25)RobertMe Wrote: A request continuing on this discussion. Would it be possible to have the lists handle SendText? So you would be able to "fast scroll" in a list? So when your browsing the video library you could just press (/SendText) a Z and the list would automatically scroll to the Z.
Not sure where this code/logic is located and how it works. If it works character by character it probably won't work with SendText. But if it works on a whole string it would probably be possible.

(2012-08-02, 20:25)RobertMe Wrote: And another question (/request). Player.GetItems contains a list of subtitles, but I guess those are only the ones which are available, right? Would it be possible to also fetch the list of subtitles which can be downloaded using the subtitle plugin? And/or trigger the automatic download of a Sync subtitle whenever one is found, the same as the Subtitle button does when you're watching a video.

Yes it only lists the internal and external subtitles, not the ones being available online. There are at least two problems with your request:
1. Always retrieving all the subtitles available for the currently playing item will slow down the response time considerable as JSON-RPC would have to wait for the addon to do it's magic.
2. AFAIK the whole logic (retrieve a list of available subtitles, display them to the user, download the chosen subtitle, activate the subtitle) is located in the addon. All XBMC does is trigger the addon to do it's work and wait until it returns. There's no feedback from the addon back to XBMC while it is active.

So it is very unlikely to be added unless the whole logic how subtitle addons works is changed (which is also very unlikely). You might be able to trigger the addon once my addon stuff for JSON-RPC has been merged but you'd still have to use a remote to choose the subtitle and download it.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Koying - 2012-08-03

(2012-08-02, 16:27)Montellese Wrote: Yesterday I merged a PR which will provide you with the current value of the currently active input box in the Input.OnInputRequested notification. So there's no need for you to remember anything. When you receive the notification pop up the virtual keyboard (or let the user use the hardware keyboard) and let him alter the value of the input box. When he's done he presses Enter (or whatever) and you use Input.SendText to send the text to XBMC. If the user then realizes that he made a mistake he can focus the input box again and just change whatever was wrong with the first value.

That's great!! I was dreaming of something like that for while Big Grin




RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - RobertMe - 2012-08-03

Thank you for your explanation Smile I didn't think about the "addon boundary" (nor the delay in downloading the information). Only a way to trigger the addon would already be great (combined with the "auto download sync subtible" setting would already make it work quite well), so I'll wait for some work in triggering addon.

And maybe a addon API for JSON-RPC would be nice? So plugins could also add methods (and notifications) to JSON-RPC. But I guess that would require a lot of work. Or is this what you're already working on? As it isn't clear to me whether you mean "a way to trigger addons" or "a way for addons to extend the JSON-RPC api". As in the later case a "request subtitles" method and a "subtitles received" announcement would be possible.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-08-03

(2012-08-03, 18:44)RobertMe Wrote: And maybe a addon API for JSON-RPC would be nice? So plugins could also add methods (and notifications) to JSON-RPC. But I guess that would require a lot of work. Or is this what you're already working on? As it isn't clear to me whether you mean "a way to trigger addons" or "a way for addons to extend the JSON-RPC api". As in the later case a "request subtitles" method and a "subtitles received" announcement would be possible.

The PR I have ready adds the methods Addons.GetAddons, Addons.GetAddonDetails, Addons.SetAddonEnabled and Addons.ExecuteAddon. So you will be able to get a list of installed (enabled or disabled) addons and you will be able to enable/disable addons and execute them (i.e. start them and pass some parameters (which are addon-specific)).

The other way i.e. addons being able to extend the JSON-RPC API with their own methods is on my TODO list as well but I don't know much about the python interface used by addons so I never really found the motivation to look into it yet.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-08-06

Monday, August 6th 2012:
Commits: 8f68fe63bd3c4a1b8b03, 28a085ff623e88084a09

THESE CHANGES BREAK BACKWARDS COMPATIBILITY WITH VERSION 4 OF JSON-RPC API!!!
  • the properties set and setid for movies are no longer arrays but a single string (set) / integer (setid) value because very movie can only belong to one set from now on. This also means that retrieving those two properties does no longer require extra SQL queries and is therefore faster than in the past.
  • a lot of properties which were returned as a concatenated string with a "/" seperator are now returned as arrays of strings instead. This should make parsing the response a lot easier for clients.
  • a tag property (array of strings) has been added for movies
  • the properties productioncode and premiered have been removed from movies because they never belonged there. They are meant for tvshows.
  • a new parameter filter has been added for a lot of (Audio|Video)Library.GetFoos methods. Depending on the method it takes a property like "genreid" or "artistid" etc which were previously available as seperate parameters. Moving them into the "filter" parameter allows more control over the filters because in most cases filters cannot be combined (right now) which was confusing in the past. Furthermore new filters have been added like "genre", "actor", "director", "studio", "artist", "album" etc which do not rely on a database ID but on an actual string/name.

Although some of these changes break backwords compatibility, the move from properties returned as strings to properties returned as arrays can be caught at runtime by checking if a property is a string or an array. If it is a string you interact with an XBMC client using JSON-RPC API v4 (and you need to split the string and extract the seperate items) and if it is an array you interact with an XBMC client using JSON-RPC API v5+ (and you can extract the items directly from the array).


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - tim2005 - 2012-08-06

I am experiencing trouble when using .NET to connect to the JSON-RPC service using WebSockets. Operating System is Windows 8 CP and XBMC is v12 on Raspberry Pi (Alpha 4, OpenElec install) and on the machine itself (Nightly d9ce56e, 20120805).

When making a Windows 8 Metro application and using the MessageWebSocket class to connect to the XBMC instance, an time-out occures. I fired up Wireshark on my machine to capture the network traffic. I can see that a GET request reaches XBMC and beïng ACK-ed. Hower I do not receive any HTTP response, and the connection is not upgraded to use the WebSockets protocol. This results in a timeout on the client, because the server disconnects the session after a certain amount of time. I tried the same with Firefox 12.0 using JavaScript and there where no issues while both are using WebSockets v13. I also captured the firefox traffic, and I found some differences, see this screenshot (click for full size):

Image

Code:
try
{
    // Make a local copy to avoid races with Closed events.
    MessageWebSocket webSocket = _webSocket;

    // Have we connected yet?
    if (webSocket == null)
    {
        webSocket = new MessageWebSocket();

        // MessageWebSocket supports both utf8 and binary messages.
        // When utf8 is specified as the messageType, then the developer
        // promises to only send utf8-encoded data.
        //webSocket.Control.MessageType = SocketMessageType.Utf8;

        // Set up callbacks
        webSocket.MessageReceived += MessageReceived;
        webSocket.Closed += Closed;

        await webSocket.ConnectAsync(server);

        // Code below never reaced because connection fails
        _webSocket = webSocket; // Only store it after successfully connecting.
        _messageWriter = new DataWriter(webSocket.OutputStream);
   }

}
catch (Exception ex) // For debugging
{
    WebErrorStatus status = WebSocketError.GetStatus(ex.GetBaseException().HResult);
    // Here Timeout catched after ~30 secs
}

Someone has an idea where it goes wrong? Looks like XBMC does not handle the WebSocket from .NET in the right way.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-08-06

Have you taken a look into XBMC's log file? There should be a log output starting with "WebSocket" which might contain more information. Didn't see anything missing in the screenshot. The only real difference (apart from the extra header fields from Firefox) is that the "Connection" header from Firefox also contains "keep-alive" which is not necessary.