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

Forgot to post this update from sunday

Sunday, March 25th 2012:
Commit: 4d4eac0b4043c99d9794
Add support for WebSockets. Websockets are accessible using the port of the TCP server (by default 9090) and using version 8 (draft) or 13 (final) of the websocket specification. So the URL to access the websocket would be e.g.
For now websockets are only available for JSON-RPC and support the same features as the TCP Server (i.e. notifications but no file download).

And here comes the first (rather big) update for JSON-RPC API v5:

Tuesday, March 27th 2012:
Commit: 32b3b77f9829202e1528

• added Input.ContextMenu and Input.Info
• added System.EjectOpticalDrive and a new permission ControlSystem
• added GUI namespace with the methods ShowNotification, SetFullscreen and GetProperties (current properties are "currentwindow", "currentcontrol", "fullscreen" and "skin")
• added AudioLibrary.GetRecentlyPlayedAlbums and AudioLibrary.GetRecentlyPlayedSongs
• added properties "size", "lastmodified" and "mimetype" to Files.GetDirectory
• added properties "season" and "watchedepisodes" to VideoLibrary.GetTvShows and "watchedepisodes" to VideoLibrary.GetSeasons
• added notification Application.OnVolumeChanged
• extended Application.SetVolume to support "increment" and "decrement"
• added optional "play" parameter to Player.PlayPause
• added optional "enable" parameter to Player.SetSubtitle
• added optional "directory" parameter to (Audio|Video)Library.Scan
• added optional "options" parameter to Player.Open which can have the properties "shuffled", "repeat" and "resume"
• improved properties returned by Player.GetItem for non-library media being played
• added sort methods "country", "dateadded", "listeners" and "bitrate"
  

Nice.

Will any of these additions (plus future ones) make it into an 11.x release? I can imagine a lot of these being very useful and it'll be a shame to have to wait a year or so before using them.

(2012-03-27 19:45)Mizaki Wrote:  Nice.

Will any of these additions (plus future ones) make it into an 11.x release? I can imagine a lot of these being very useful and it'll be a shame to have to wait a year or so before using them.

No they won't any 11.x releases (if there will be any at all) will only contain bugfixes, no new features and especially no API changes. But we are planning to release the next version ealier than in a year.

I just pushed a major refactor of how the webserver works internally. Currently this has only one effect on how it works and that affects JSON-RPC clients using JSON-RPC over HTTP. You need to make sure you set the Content-Type in the HTTP header to "application/json" and not something like "multipart/form-data" because that is plain wrong. The new implementation has the functionality to parse POST data for certain content-types (including application/json and multipart/form-data) and will therefore fail if the content-type does not match the actual POST data.

You are planning:
- improved properties returned by Player.GetItem for non-library media being played
for next release. How come I've got extended properties for radio stations from Radio plugin, when I used Eden-beta. Yesterday I switched to final release and all info from GetItem is url of radio stream. When I was using beta I've also got: genre, thumbnail, path to plugin file etc.
How can it happened?

Chris

IIRC I didn't change anything in that area since the first Eden beta. Maybe something changed in the python/addon area. Can you provide you're JSON-RPC request? But normally you shouldn't get any properties like "genre" etc for items played through plugins. It depends a bit on how it is started and whether you have been in the fullscreen view etc so it might just be that you got lucky when you got that information with Eden beta. This stuff is not very well coded and (as already mentioned) depending on where you have been in the GUI it might affect the information available to JSON-RPC.

Files.GetDirectory might be too helpful with it's label field.

If you list an album directory and sort by file with songs named:
01 - Artist - B song.mp3
02 - Artist - D song.mp3
03 - Artist - A song.mp3
04 - Artist - C song.mp3

that is in the library, you'll return a list of only song names that looks unsorted. Wouldn't it be better for the label to always be the file name and then you can use and others via properties if they are available?

Well IMO "label" never made much sense for Files.GetDirectory but I left it in because every other media type returned has a "label" property as well.
If you want to sort by filename you need to extract it from the "file" property. Furthermore IMO the only sorting method that makes any sense for songs is sorting by tracks

Howdy all. Newest of the n00bs here, with regards to XBMC overall. After spending a few days reading through <shudder> 185 pages of this thread, I think I only have two n00bish questions. If these were answered here or elsewhere and I missed them or I should have gleaned them otherwise, my apologies. (Brain is a little slushy after trying to absorb everything)

1) Working on the most basic of controls (UI nav / transport control) and see that I need to track which player (if any) is in use. I see mention that at some point the values of 0, 1 and 2 for player type may change. What I haven't gathered is what they might change to and why?

2) Since I need to parse responses to make item 1 happen, I also have to write some JSON parsing code. (One of those lucky types that doesn't have libraries available like 99% of the folk here) After looking over the JSON and JSON-RPC specs, it looks like curly braces are legitimate characters to have inside strings. So - just to be sure - aside from having to count curly braces to make sure I'm about to parse a 100% intact packet, I also need to make sure that I'm not counting any braces that might be contained in strings, right?

And yes - I'm intending on using TCP, not HTTP - I realize that HTTP would guarantee me a complete packet.

Thanks,
- Chip