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 - jmarshall - 2013-11-05

This is possibly a NULL versus empty issue perhaps?


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Milhouse - 2013-11-06

(2013-11-05, 23:38)jmarshall Wrote: This is possibly a NULL versus empty issue perhaps?

Presumably you mean in C++ terms, as specifying a null filter value isn't valid for JSON. It most likely is something like that though, or perhaps it's down to a join query, as I'm surprised that "value != '@@@@@'" manages to ignore all those movies where set == "" as in theory these should also be returned but aren't.

Edit: I should add that "startswith/endswith" are both working as expected, contrary to my previous comment about only contains/doesnotcontain working, however neither are useful for what I'm trying to achieve, indeed is/isnot works with everything but an empty string, but support for empty strings would be most welcome! Smile

Edit2: Just to be sure, I went back to a version with v6.6.2 API (so prior to all the recent JSON API updates) and the is/isnot filter with an empty string is also not working there, so this doesn't appear to have been introduced recently.


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

Looking at the code it seems that we throw away filters that contain no or an empty value which could explain this behaviour.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Milhouse - 2013-11-06

(2013-11-06, 18:46)Montellese Wrote: Looking at the code it seems that we throw away filters that contain no or an empty value which could explain this behaviour.

Yes it would! Smile

Hopefully it can be fixed, I'd have thought it would be be quite useful to know when a value is set (isnot "") or unset (is ""), but you don't know (or care) what value it is. Another example might be to obtain a list of movies that have a "lastplayed" value set, presumably a 'lastplayed isnot ""' query would fail (be ignored) too.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Regss - 2013-11-06

I'm trying to get watched movies:

Code:
{"jsonrpc": "2.0", "method": "VideoLibrary.GetMovies", "params": {"properties": ["playcount"]}, "filter": {"operator": "greaterthan", "field": "playcount", "value": 0}, "id": 1}

but get list of all movies with unwatched.

Frodo 12.2


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Milhouse - 2013-11-06

(2013-11-06, 20:19)Regss Wrote: I'm trying to get watched movies:

Code:
{"jsonrpc": "2.0", "method": "VideoLibrary.GetMovies", "params": {"properties": ["playcount"]}, "filter": {"operator": "greaterthan", "field": "playcount", "value": 0}, "id": 1}

but get list of all movies with unwatched.

Frodo 12.2

Try passing value as a string ("0") - this works for me in Frodo (v6.0.3 JSON API) and Gotham (v6.12.0), but passing "value" as an integer (0) causes an error in both - the following is from Frodo/v6.0.3, first an integer then a string:
Code:
REQUEST: {"jsonrpc": "2.0", "params": {"filter": {"operator": "greaterthan", "field": "playcount", "value": 0}, "properties": ["playcount"]}, "method": "VideoLibrary.GetMovies", "id": "libMovies"}
RESPONSE {"error":{"code":-32602,"data":{"method":"VideoLibrary.GetMovies","stack":{"message":"Received value does not match any of the union type definitions","name":"filter","property":{"type":"string"},"type":"object"}},"message":"Invalid params."},"id":"libMovies","jsonrpc":"2.0"}

REQUEST: {"jsonrpc": "2.0", "params": {"filter": {"operator": "greaterthan", "field": "playcount", "value": "0"}, "properties": ["playcount"]}, "method": "VideoLibrary.GetMovies", "id": "libMovies"}
RESPONSE {"id":"libMovies","jsonrpc":"2.0","result":{"limits":{"end":10,"start":0,"total":10},"movies":[{"label":"Ocean's Eleven (2001)","movieid":286,"playcount":1},{"label":"Ocean's Thirteen","movieid":287,"playcount":1},{"label":"Ocean's Twelve","movieid":288,"playcount":1},{"label":"Electroma","movieid":604,"playcount":1},{"label":"Stargate","movieid":605,"playcount":1},{"label":"Man on Wire","movieid":607,"playcount":1},{"label":"Battlestar Galactica: Blood & Chrome","movieid":609,"playcount":1},{"label":"Oblivion","movieid":632,"playcount":1},{"label":"Now You See Me","movieid":633,"playcount":1},{"label":"Iron Man 3","movieid":635,"playcount":1}]}}



RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Regss - 2013-11-06

Thanks, I see mistake now. I wrong created a query. Filter must be pass as params.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Milhouse - 2013-11-07

Another example of the null filter ignored problem - filtering GetTextures returning just those artwork items without a hash, ie. 'lasthashchecked is ""' - this too returns everything. Obviously I can accomplish this query if hitting the Textures db directly with SQLite, but not via the new JSON API.

Not sure why this hasn't cropped up before...


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Milhouse - 2013-11-08

On the Addons.ExecuteAddon method there's a "wait" parameter, however the "wait" parameter doesn't appear to have any effect.

For instance:
Code:
{"jsonrpc": "2.0", "method": "Addons.ExecuteAddon", "params": {"addonid": "script.artwork.downloader", "params": ["silent=true", "mediatype=movie"], "wait": true}, "id": "1"}

doesn't wait for the addon to complete, it returns immediately after starting the addon - is this correct?


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Milhouse - 2013-11-10

@Montellese: It's been a bit of a saga and this post may be a little long winded, but I hope you can bear with me... Smile

I've become aware of at least two addons that are "mangling" urls in the media library by creating urls with a mixture of forward and backwards slashes, for instance (and I think this was caused by Artwork Downloader):
Code:
"art": {
      "banner": "image://I:\\Filmes\\007 Collection\\22.James.Bond.007.Quantum.of.Solace/banner.jpg/",
      "clearart": "image://I:\\Filmes\\007 Collection\\22.James.Bond.007.Quantum.of.Solace/clearart.png/",
      "clearlogo": "image://I:\\Filmes\\007 Collection\\22.James.Bond.007.Quantum.of.Solace/logo.png/",
      "discart": "image://I:\\Filmes\\007 Collection\\22.James.Bond.007.Quantum.of.Solace/disc.png/",
      "fanart": "image://http://d3gtl9l2a4fn1j.cloudfront.net/t/p/original/hfZVY8lMiE7HH1cDc2qzSFF6Kbt.jpg/",
      "landscape": "image://I:\\Filmes\\007 Collection\\22.James.Bond.007.Quantum.of.Solace/landscape.jpg/",
      "poster": "image://http://d3gtl9l2a4fn1j.cloudfront.net/t/p/original/fuQuV4JF6WflG22mgszXuAaaQVb.jpg/"
    },

Note the banner, clearart, clearlogo, discart and landscape urls with the Unix-style forward slash between the last directory and artwork filename, even though the urls are clearly for a Windows system.

Although not right, these mangled urls don't seem to be a problem for the GUI - despite the media library referencing a "mangled" url, the GUI will locate the artwork successfully and then cache it without any problem, creating a similarly mangled url entry in the texture database.

Now comes the problem: when requesting artwork with mangled urls via the webserver, it appears that the webserver is correcting the forward/backward slashes in the url and will create an entry in the texture database that is not mangled. Consequently, the GUI cannot find this cached item (as the GUI is looking for the mangled version of the url) and will proceed to create another cache entry, this time using the mangled url as it appears in the media library.

Is there any way that the webserver can be made to stop correcting mangled filenames on-the-fly whenever it creates (or possibly even looks up) a row in the texture cache? This no-touch behaviour would then be consistent with the GUI caching behaviour. Alternatively I suppose the GUI could correct urls on the fly, but I'm guessing that's going to cause more overhead and is not ideal.

Here's a worked example:
Code:
[
  {
    "art": {
      "clearart": "image://http://assets.fanart.tv/fanart/movies/19908/movieart/zombieland-4fd8c70fd673c.png/",
      "clearlogo": "image://http://assets.fanart.tv/fanart/movies/19908/hdmovielogo/zombieland-5145e97ed73a4.png/",
      "fanart": "image://nfs://192.168.0.3/mnt/share/media/Video/MoviesHD/Zombieland (2009)[BDRip]-fanart.jpg/",
      "poster": "image://nfs://192.168.0.3/mnt/share/media/Video/MoviesHD\\Zombieland (2009)[BDRip]-poster.jpg/"
    },
    "file": "nfs://192.168.0.3/mnt/share/media/Video/MoviesHD/Zombieland (2009)[BDRip].mkv",
    "label": "Zombieland",
    "movieid": 667,
    "title": "Zombieland"
  }
]

Note how the poster has a Windows-style backslash between the directory and filename.

Having removed all trace of the poster from Textures13.db, the poster is downloaded using JSON and the webserver:

JSON "Files.PrepareDownload" Request:
Code:
{"jsonrpc": "2.0", "params": {"path": "image://nfs%3a%2f%2f192.168.0.3%2fmnt%2fshare%2fmedia%2fVideo%2fMoviesHD%5cZombieland%20(2009)%5bBDRip%5d-poster.jpg/"}, "method": "Files.PrepareDownload", "id": "preparedl"}

JSON "Files.PrepareDownload" Response:
Code:
{"id":"preparedl","jsonrpc":"2.0","result":{"details":{"path":"image/image%3a%2f%2fnfs%253a%252f%252f192.168.0.3%252fmnt%252fshare%252fmedia%252fVideo%252fMoviesHD%255cZombieland%2520(2009)%255bBDRip%255d-poster.jpg%2f"},"mode":"redirect","protocol":"http"}}

Webserver (HTTP) Request:
Code:
GET image/image%3a%2f%2fnfs%253a%252f%252f192.168.0.3%252fmnt%252fshare%252fmedia%252fVideo%252fMoviesHD%255cZombieland%2520(2009)%255bBDRip%255d-poster.jpg%2f

All of the above urls contain the backward slash from the original url (ie. they're all "mangled" urls).

Having downloaded the item, the following row appears in Textures13.db:
Code:
031637|9/9993f35a.jpg|2013-11-10 03:32:41|2013-11-10 03:32:41|nfs://192.168.0.3/mnt/share/media/Video/MoviesHD/Zombieland (2009)[BDRip]-poster.jpg

Note the corrected forward slash between directory and filename - the url is no longer mangled!

Now browse to the same poster in the GUI, and the following row appears in Textures13.db:

Code:
031638|b/ba80e1ed.jpg|2013-11-10 03:34:20|2013-11-10 03:34:20|nfs://192.168.0.3/mnt/share/media/Video/MoviesHD\Zombieland (2009)[BDRip]-poster.jpg

Note how the url is as it appears in the media library, ie. mangled. The row inserted by the webserver (#31637) is ignored by the GUI.

The webserver caching behaviour should be consistent with the GUI, but it's not - any chance of a fix? I can't think how changing the webserver caching behaviour would break an existing addon or script, but I guess that's always something to be considered. Happy to help test... Smile

Obviously it would be better if addons didn't create mangled urls, but ultimately the mangled urls they produce are not a problem for the GUI, only the webserver, and I can't see how it will be possible to prevent addons from continuing to create mangled urls, particularly those that insert rows directly into the database (JSON could perhaps fix urls as they are passed over?)

Many thanks for your consideration! Smile


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2013-11-10

Thanks for the detailed description. The problem is not in the webserver but in the way the paths are handled by the texture caching logic. I'll try to get jmarshall to look into it.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Milhouse - 2013-11-11

(2013-11-10, 19:02)Montellese Wrote: Thanks for the detailed description. The problem is not in the webserver but in the way the paths are handled by the texture caching logic. I'll try to get jmarshall to look into it.

That would be great, thanks.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - learningit - 2013-11-11

I'm trying to update my addons to make full use of the json rpc but I can't figure out how to set the properties of a playlist item.

I can use:
{"jsonrpc": "2.0", "method": "Playlist.Getitems", "params": {"playlistid": 1, "properties": ["title", "album", "artist", "plot", "year", "genre","season", "episode", "duration", "showtitle", "tvshowid", "thumbnail", "file", "fanart", "streamdetails"]}, "id":1}

to read the playlist items properties, even if they're not in the library, but I can't get the Playlist.Add method to set the properties and can't find another method which does it.

{"jsonrpc": "2.0", "method": "Playlist.Add", "params": {"playlistid": 1, "item":{"file":"C:/Users/TV/AppData/Roaming/XBMC/userdata/something.mp4"}}, "id":1}
works to set the playlist item file, but how do you set the other properties?

I'm trying to change the following existing code to the json interface:

u=sys.argv[0]+"?url="+urllib.quote_plus(url)+"&mode="+str(mode)
liz=xbmcgui.ListItem(name, iconImage=dir_image, thumbnailImage=iconimage)
liz.setInfo( type="Video", infoLabels={ "Title": name, "Plot": description, "Genre": genre, "Year": date } )
liz.setProperty( "Fanart_Image", fanart )
liz.addContextMenuItems(contextMenu_)
xbmc.PlayList(1).add(u, liz)

How can I accomplish this with the json rpc api? Thanks in advance.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2013-11-11

JSON-RPC can't do that. You'll have to stick with python to be able to set properties when adding an item to a playlist.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2013-11-11

(2013-10-29, 16:18)tiago Wrote: Hi everyone,

I'm a Ph.D. student in the Netherlands researching the evolution and maintenance of web APIs. The XBMC project got my attention when I noticed that there's actually a JSONRPC API and a few Android (and I presume iOS) clients which connect to it.

What I was wondering is whether the developers who are the most familiar with the JSON-RPC API would be willing to do a 30~45 minute Skype interview with me on the design choices of the XBMC web API. Is this something the devs would be willing to participate on?

Also, similarly, if there's any client developers in this thread, the invitation is also extended to them as we would like to get insight from both the developers of the server-side code as well as those on the client-side.

Thanks in advance for your cooperation!

Best,
Tiago

Sorry for the late reply. I am the main developer and maintainer of XBMC's JSON-RPC API. Unfortunately I've been very short on time in the last couple of weeks/months and that's not gonna change anytime soon. If you have a list of questions, feel free to email me (montellese@xbmc.org) or send me a PM and I will try to answer them ASAP.