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)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226

- jasonvp - 2011-09-03

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

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

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 Smile (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

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

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

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

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

Code:
login as: root
[email protected]'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

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

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

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.

JSON bracket counting - othrayte - 2011-09-06

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.TraktUtilities/blob/master/notification_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.

- gertjanzwartjes - 2011-09-06

Montellese Wrote: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.

I'm using Window.IsActive(), to figure out whether some window is currently showing and active, using Window IDs as specified in guilib/Key.h.

- Montellese - 2011-09-06

gertjanzwartjes Wrote:I'm using Window.IsActive(), to figure out whether some window is currently showing and active, using Window IDs as specified in guilib/Key.h.

Thanks for the feedback. Wrapping part of the GUI is on the TODO list so checking active windows will most likely be available directly in the future.

- dann0 - 2011-09-07

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.

Thanks for your reply Montellese.

I made a feature request and copied you and topfs2 in. I realise it may not interest many users, so i won't be holding my breath Wink i just thought i would throw it out there anyways.

Expose Scrapers to JSON - Jeff17 - 2011-09-07

I've created a patch to expose some of the scraper methods. Right now this is using the "Scraper." namespace, but after reading this ticket, it looks like it might be better to rename it.

So far I've created three methods:

Scraper.GetScrapers(type) will return a list of active, installed scrapers (file=scraperid, label=scrapername) filtered by the type specified

Scraper.FindMovie( scraperid, file ) will use a specific scraper and return a list of matching results (file=scraperurl, label=movie name). Filename can be the path to the file or search terms.

Scraper.GetMovieDetails( scraperid, url, fields ) will query a scraper and return a list of movie details.

The existing code is mostly just a proof-of-concept. I'm interested in hearing what functionality we want to expose over JSON and what naming conventions I should be using for this.

Thanks!

-- Jeff

- gertjanzwartjes - 2011-09-07

Montellese Wrote:Thanks for the feedback. Wrapping part of the GUI is on the TODO list so checking active windows will most likely be available directly in the future.

Ok, that's good to hear, thanks. When something is available I'll be able to test it out and report back.

One more thing, the current nightly JSON-RPC API provides methods for movement (Left, Right, Up, ...). I was wondering whether more generic keyboard input is planned as well? Mostly to be able to provide keyboard functionality to edit setting strings, or when adding a source, etc. I'm still relying on the HTTP API for that, but I'm wondering if I should make the switch to EventServer or not.