JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC

  Thread Rating:
  • 7 Votes - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Post Reply
RobertMe Offline
Junior Member
Posts: 5
Joined: Jul 2012
Reputation: 0
Post: #2111
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.
find quote
Montellese Offline
Team-XBMC Developer
Posts: 2,787
Joined: Jan 2009
Reputation: 20
Location: Switzerland
Post: #2112
(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.

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

[Image: badge.gif]
find quote
Montellese Offline
Team-XBMC Developer
Posts: 2,787
Joined: Jan 2009
Reputation: 20
Location: Switzerland
Post: #2113
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).

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

[Image: badge.gif]
(This post was last modified: 2012-08-06 13:38 by Montellese.)
find quote
tim2005 Offline
Junior Member
Posts: 8
Joined: Sep 2008
Reputation: 0
Post: #2114
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: websockets.png]

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.
(This post was last modified: 2012-08-06 19:48 by tim2005.)
find quote
Montellese Offline
Team-XBMC Developer
Posts: 2,787
Joined: Jan 2009
Reputation: 20
Location: Switzerland
Post: #2115
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.

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

[Image: badge.gif]
find quote
tim2005 Offline
Junior Member
Posts: 8
Joined: Sep 2008
Reputation: 0
Post: #2116
I enabled Debug logging, and found the following in the xmb.log file.
Quote:18:36:36 T:1284478048 DEBUG: JSONRPC Server: New connection detected
18:36:36 T:1284478048 INFO: JSONRPC Server: New connection added
18:36:36 T:1284478048 INFO: WebSocket [RFC6455]: invalid "Upgrade" received
18:36:36 T:1284478048 INFO: WebSocket: No frame expected in the current state
18:37:06 T:1284478048 INFO: JSONRPC Server: Disconnection detected
Looks like XBMC and .NET do implement RFC6455 in a different way. Maybe it is because in the working connection the upgrade is "websocket" and in the non-working it is "Websocket", capital use issue?


Edit/Update:
I continued my research and made a small .NET program wich does not use the WebSocket class but the TcpClient class. I copied the working HTTP request to the testapplication and let it send. I succesfully received a 'Switching protocols' response. Then I changed the HTTP request a bit, "Upgrade: websocket" became "Upgrade: Websocket" (capital W). Suddenly it does not work Smile Tried the same with the original request from .NET, modiefied it to not use a capital and then it works fine. Looks a capital issue to me.

Protocol says it should be case-insensitive, see Page 18 subject 2.
http://tools.ietf.org/html/rfc6455#page-18

Edit/Update 2:
I made a bug report for this issue in TRAC: http://trac.xbmc.org/ticket/13231
(This post was last modified: 2012-08-06 20:07 by tim2005.)
find quote
Montellese Offline
Team-XBMC Developer
Posts: 2,787
Joined: Jan 2009
Reputation: 20
Location: Switzerland
Post: #2117
(2012-08-06 18:39)tim2005 Wrote:  I enabled Debug logging, and found the following in the xmb.log file.
Quote:18:36:36 T:1284478048 DEBUG: JSONRPC Server: New connection detected
18:36:36 T:1284478048 INFO: JSONRPC Server: New connection added
18:36:36 T:1284478048 INFO: WebSocket [RFC6455]: invalid "Upgrade" received
18:36:36 T:1284478048 INFO: WebSocket: No frame expected in the current state
18:37:06 T:1284478048 INFO: JSONRPC Server: Disconnection detected
Looks like XBMC and .NET do implement RFC6455 in a different way. Maybe it is because in the working connection the upgrade is "websocket" and in the non-working it is "Websocket", capital use issue?


Edit/Update:
I continued my research and made a small .NET program wich does not use the WebSocket class but the TcpClient class. I copied the working HTTP request to the testapplication and let it send. I succesfully received a 'Switching protocols' response. Then I changed the HTTP request a bit, "Upgrade: websocket" became "Upgrade: Websocket" (capital W). Suddenly it does not work Smile Tried the same with the original request from .NET, modiefied it to not use a capital and then it works fine. Looks a capital issue to me.

Protocol says it should be case-insensitive, see Page 18 subject 2.
http://tools.ietf.org/html/rfc6455#page-18

Edit/Update 2:
I made a bug report for this issue in TRAC: http://trac.xbmc.org/ticket/13231

Thanks for tracking this down. I already suspected that it would come down to a case-sensitivity problem. I've pushed a fix. Please let me know whether it solves the problem or not. I have to admit I'm too lazy to write a program to send a websocket header and all the existing ones in firefox, chrome do/did not have this problem.

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

[Image: badge.gif]
find quote
tim2005 Offline
Junior Member
Posts: 8
Joined: Sep 2008
Reputation: 0
Post: #2118
(2012-08-06 22:01)Montellese Wrote:  
(2012-08-06 18:39)tim2005 Wrote:  I enabled Debug logging, and found the following in the xmb.log file.
Quote:18:36:36 T:1284478048 DEBUG: JSONRPC Server: New connection detected
18:36:36 T:1284478048 INFO: JSONRPC Server: New connection added
18:36:36 T:1284478048 INFO: WebSocket [RFC6455]: invalid "Upgrade" received
18:36:36 T:1284478048 INFO: WebSocket: No frame expected in the current state
18:37:06 T:1284478048 INFO: JSONRPC Server: Disconnection detected
Looks like XBMC and .NET do implement RFC6455 in a different way. Maybe it is because in the working connection the upgrade is "websocket" and in the non-working it is "Websocket", capital use issue?


Edit/Update:
I continued my research and made a small .NET program wich does not use the WebSocket class but the TcpClient class. I copied the working HTTP request to the testapplication and let it send. I succesfully received a 'Switching protocols' response. Then I changed the HTTP request a bit, "Upgrade: websocket" became "Upgrade: Websocket" (capital W). Suddenly it does not work Smile Tried the same with the original request from .NET, modiefied it to not use a capital and then it works fine. Looks a capital issue to me.

Protocol says it should be case-insensitive, see Page 18 subject 2.
http://tools.ietf.org/html/rfc6455#page-18

Edit/Update 2:
I made a bug report for this issue in TRAC: http://trac.xbmc.org/ticket/13231

Thanks for tracking this down. I already suspected that it would come down to a case-sensitivity problem. I've pushed a fix. Please let me know whether it solves the problem or not. I have to admit I'm too lazy to write a program to send a websocket header and all the existing ones in firefox, chrome do/did not have this problem.

Thank you for the very fast fix, 92 minutes after submit. I am downloading the most recent night windows build containing this fix. Had to wait for it, will report back soon.

Update: The connection succeeds now Smile Great job! Keep up the good work.
(This post was last modified: 2012-08-07 11:34 by tim2005.)
find quote
N3MIS15 Offline
Fan
Posts: 461
Joined: Jul 2010
Reputation: 12
Location: Melbourne, VIC
Post: #2119
Using the latest windows build (20120806) VideoLibrary.GetMovieDetails returns "set": "\u0000" for every movie.
I removed the nfo files and rescraped the movies on my test setup just in case it was a conflict with old nfo files but its still happening (even for movies without sets). Am i missing something? Or is this a bug?

[Image: all-fanart.jpg]
find quote
Montellese Offline
Team-XBMC Developer
Posts: 2,787
Joined: Jan 2009
Reputation: 20
Location: Switzerland
Post: #2120
(2012-08-07 11:40)N3MIS15 Wrote:  Using the latest windows build (20120806) VideoLibrary.GetMovieDetails returns "set": "\u0000" for every movie.
I removed the nfo files and rescraped the movies on my test setup just in case it was a conflict with old nfo files but its still happening (even for movies without sets). Am i missing something? Or is this a bug?

Thanks for the report. Stupid copy & paste errors. Fixed in https://github.com/xbmc/xbmc/commit/bf51...b99245715f

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

[Image: badge.gif]
find quote
Post Reply