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

jasonvp · 2011-09-03 11:25

Montellese Wrote:Hey everyone

For the ones wondering why not much has happend in the JSONRPC department during the last few weeks here are finally some updates. I was on a long holiday trip but now I'm back in the game and working hard on improving JSONRPC again.

Commits: ae691d390c87365087ff, 491764e6aa4f8a96ab7b

Added optional parameter "albumartistsonly" to AudioLibrary.GetArtists. If the parameter is not passed or is passed with a value of null the result will consider the GUI setting "Include artists who appear only on compilations" (Settings -> Music -> Library). Providing the parameter with a boolean value (true/false) overrides the GUI setting. If the GUI setting is unchecked or the parameter is passed with a value of false, the returned list will contain an artist named "Various artists". That artist has an "artistid" which cannot be used in AudioLibrary.GetArtistDetails but it can be used in AudioLibrary.GetAlbums and AudioLibrary.GetSongs.

Changed the return value of the "set" field, which can be requested for movies. Up until now the return value was a comma-seperated string of set names. It has now been changed into an array of set names which should make parsing the sets a lot easier for clients.

The following optional fields have been added to some media objects:

"setid" to movies

"tvshowid" to episodes

"artistid" to albums

"artistid" and "albumid" to songs

This will make it easier to access "parent objects" of a retrieved media objects.

Hi Guys,

Are these added to the Nightly Builds?

I'm using the Windows 01-Sep-2011 10:28 version and I tried:

Code:

{"jsonrpc":"2.0","id":1,"method":"AudioLibrary.GetSongs","params":{"fields":["artistid","albumid"]}}

Response:

Code:

{"error":{"code":-32602,"data":{"method":"AudioLibrary.GetSongs","stack":{"message":"array element at index 0 does not match","name":"fields","property":{"message":"Received value does not match any of the defined enum values","type":"string"},"type":"array"}},"message":"Invalid params."},"id":1,"jsonrpc":"2.0"}

Cheers
Jason

**topfs2** · 2011-09-03 11:30

jasonvp Wrote:I'm using the Windows 01-Sep-2011 10:28 version and I tried:

Check if the revisions mentioned are in the source used to compile that nightly, its not possible to derive this information simply from date Smile

(likely is that you just missed it in that nightly so take a newer version)

jasonvp · 2011-09-03 14:14

topfs2 Wrote:Check if the revisions mentioned are in the source used to compile that nightly, its not possible to derive this information simply from date (likely is that you just missed it in that nightly so take a newer version)

Installed XBMCSetup-20110902-312d2c3-master.exe and all is working fine.

Thanks topfs2. You guys do a great job.

Cheers
Jason

samdret · 2011-09-04 10:33

Montellese Wrote:Not directly but what you can try is to call Files.GetDirectory with the path to the directory in which your file is. You will also have to provide the media type of the file so that JSONRPC is able to check the right database for the details of the file.

Tried that, but only got back fanart, label and file - none of which are of particular interest Sad

**Montellese** · 2011-09-04 11:12

samdret Wrote:Tried that, but only got back fanart, label and file - none of which are of particular interest

What version of XBMC are you running?
Have you stated in your request to Files.GetDirectory which optional fields you would like to retrieve?

rflores2323 · 2011-09-04 22:57

rflores2323 Wrote:I was running xbmc before. Closed it and did what you said above. here you go below.

Code:

login as: root root@192.168.1.7's password: Apple-TV:~ root# netstat -ln Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 52 192.168.1.7.22 192.168.1.17.3872 ESTABLISHED udp4 0 0 192.168.1.7.123 *.* udp4 0 0 *.64240 *.* udp4 0 0 *.* *.* udp4 0 0 *.* *.* udp4 0 0 *.* *.* udp4 0 0 *.62980 *.* udp4 0 0 *.5353 *.* udp4 0 0 127.0.0.1.123 *.* you udp4 0 0 *.123 *.* Active LOCAL (UNIX) domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 8192 8192 0 0 0 0 0 #0 4096 2048 0 8458e980 0 8458e998 0 #0 4096 2048 0 8458e8e8 0 8458e900 0 #0 4096 2048 0 83fc1ab0 0 83fc1ac8 0 #0 4096 2048 0 84382be0 0 84382bf8 0 #0 4096 2048 0 835df558 0 835df570 0 #0 4096 2048 0 8458eab0 0 8458eac8 0 #0 4096 2048 0 83fc1980 0 83fc1998 0 #0 4096 2048 0 83fc1be0 0 83fc1bf8 0 #0 4096 2048 0 83fc1260 0 83fc1278 0 #0 4096 2048 0 83fc14c0 0 83fc14d8 0 #0 4096 2048 0 84382260 0 84382278 0 #0 4096 2048 0 84382000 0 84382018 Apple-TV:~ root#

Any help

**Montellese** · 2011-09-05 21:33

We are currently working hard to get a stable and future-proof jsonrpc API which we can extend in the future without having to remove any unneeded stuff so I am working on cleaning up all the namespaces so that we won't have to do that at a later point.

Monday, September 5th 2011: Major cleanup
Commits: 8 commits from 2a33c5f4696d2c079625 to 2968c9b8faf821f70e97
Ok these 8 commits contain all kinds of cleanup in the jsonrpc API to make it more future-proof. From now on everything that resides in the XBMC namespace is either very XBMC-specific or is something that is more of a hack than anything else (like GetInfoLabels and GetInfoBooleans)

JSONRPC.GetNotificationFlags and JSONRPC.SetNotificationFlags have been refactored and renamed to JSONRPC.GetConfiguration and JSONRPC.SetConfiguration
XBMC.Log has been removed
GetProperties has been added to the System namespace. It currently provides the values of the properties "canshutdown", "cansuspend", "canhibernate" and "canreboot".
SetVolume, ToggleMute and Quit have been moved from the XBMC to the new Application namespace
XBMC.GetVolume has been replaced by System.GetProperties which currently provides the values of the properties "volume" and "muted".
GetInfoLabels and GetInfoBooleans have been moved from the System to the XBMC namespace and are considered deprecated. Please let us know which data you retrieve most using these methods so that we can provide better access to those values.
The field album_label for albums has been renamed to albumlabel to match the naming convention
The field streamDetails for videos has been renamed to streamdetails to match the naming convention

dann0 · 2011-09-06 04:15

testing a nightly build on the weekend i ran into an issue connecting to the JSON-RPC server via TCP.

the build i was using was XBMCSetup-20110902-312d2c3-master.exe 03-Sep-2011 10:28

i suspect the issue was the lack of a 'new line' character at the end of the data stream.

to test i connected to xbmc's (nightly) json-rpc server using telnet, sent a request and observed the response, the cursor remained positioned at the end of the data stream.
i then connected to version 10.1 and sent the same request, at the end of the response the cursor was positioned on a new line.

**Montellese** · 2011-09-06 09:56

dann0 Wrote:testing a nightly build on the weekend i ran into an issue connecting to the JSON-RPC server via TCP.

the build i was using was XBMCSetup-20110902-312d2c3-master.exe 03-Sep-2011 10:28

i suspect the issue was the lack of a 'new line' character at the end of the data stream.

to test i connected to xbmc's (nightly) json-rpc server using telnet, sent a request and observed the response, the cursor remained positioned at the end of the data stream.
i then connected to version 10.1 and sent the same request, at the end of the response the cursor was positioned on a new line.

IIRC this has been reported before by someone else but it is not a bug. If you use jsonrpc over TCP and you don't use a json(rpc) library to parse the data stream you cannot rely on something like "a response ends when there is a } followed by a newline character". All you can do is count how many { and } there are. We changed the internal json library we use in XBMC since Dharma because that one had some flaws and the new json implementation does not send a newline character at the end of a request but in jsonrpc everything that is not encapsulated between { and } is garbage and has to be thrown away so leaving it away in the beginning is even better.

othrayte · 2011-09-06 12:55

Montellese Wrote:IIRC this has been reported before by someone else but it is not a bug. If you use jsonrpc over TCP and you don't use a json(rpc) library to parse the data stream you cannot rely on something like "a response ends when there is a } followed by a newline character". All you can do is count how many { and } there are. We changed the internal json library we use in XBMC since Dharma because that one had some flaws and the new json implementation does not send a newline character at the end of a request but in jsonrpc everything that is not encapsulated between { and } is garbage and has to be thrown away so leaving it away in the beginning is even better.

I believe I was the person that brought it up originally in relation to my work on Trakt Utilities.

@dann0
I implemented the bracket counting in python at the time and we have been using it in TU for a while now without problems, but I don't guarantee that it is perfect.

Your welcome to use the code (it is GPLv2 licensed) and you can see it in context here https://github.com/Manromen/script.Trakt...service.py.

Not sure if your using python or something else but the general idea should work the same in different languages.

The important part is this bit:

Code:

if bCount == 0:

                        notification = ""

                        inString = False

                    [index, match, raw] = tn.expect(["(\\\\)|(\\\")|[{\"}]"], 0.2) #note, pre-compiled regex might be faster here

                    notification += raw

                    if index == -1: # Timeout

                        continue

                    if index == 0: # Found escaped quote

                        match = match.group(0)

                        if match == "\"":

                            inString = not inString

                            continue

                        if match == "{":

                            bCount += 1

                        if match == "}":

                            bCount -= 1

                    if bCount > 0:

                        continue

                    if bCount < 0:

                        bCount = 0

                    data = json.loads(notification)

This code runs inside a loop, it waits for some partial data and goes back to the start of the loop to wait for more when it hasn't reached the end and continues through to the json.loads when it finds a whole block, this is where you would handle the data itself.

I hope this helps, if you have any questions I'm happy to answer them, but a pm would probably be best.

jasonvp Member Posts: 57 Joined: Jul 2011 Reputation: 0	2011-09-03 14:14 Post: #1173 topfs2 Wrote:Check if the revisions mentioned are in the source used to compile that nightly, its not possible to derive this information simply from date (likely is that you just missed it in that nightly so take a newer version) Installed XBMCSetup-20110902-312d2c3-master.exe and all is working fine. Thanks topfs2. You guys do a great job. Cheers Jason
	find quote