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

(2012-03-30 06:45)Chip Moody Wrote:  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?

Well in the future there might be more players available than now. Currently there is DVDPlayer, PAPlayer and Slideshow but there also is a branch with a DSPlayer and maybe there will be more in the future and they may have different playerid's.

(2012-03-30 06:45)Chip Moody Wrote:  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?

Correct. I would look at one of the available JSON(-RPC) library (even if it's not in the programming language you'd like to use) and try to port their parsing to your programming language.

(2012-03-29 23:39)Montellese Wrote:  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

Although I tend to agree with you people might have a directory with a bunch of singles in and even though the sort has worked correctly by file name it looks wrong by label name as I said. If the file isn't in the library you get the file name, for consistency I think it would make more sense for the label to always be the file name whether in the library or not. You can check the properties for other info if it's in the library. But if you don't feel so inclined as you say I can trim it from the file property.

I see that point that when requesting something from Files.GetDirectory that the real label actually is the filename. What I'm not sure about is if there's a way for the client to build a meaningful label for every media type JSON-RPC might return as part of Files.GetDirectory based on the other properties that are available and can be retrieved by a client.

If I understand you correctly I don't find it a problem as you can ask for everything and FilesGetDirectory won't give you an error if something is missing. For example; when I query any playlist with GetDirectory I ask for artist, album, showtitle, title and episode. Then going by the "type" I check if the relevant properties are empty or not. Or if there is an id it's in the library so you can do a normal fooDetails.

I don't think you understood correctly. What I meant is if I change the "label" for files to be the filename (which is then duplicate because it's also part of the "file" property) I'm not sure if it is possible to put together a meaningful label based on the other properties that can be retrieved. For movies, episodes etc this is no problem because you can use the "title" property. This becomes a problem when a client tries to access addons through XBMC's VFS. If the addon script does not provide the "title" property but instead only sets the "label" property and XBMC overwrites the "label" property there's no way for the client to present the items returned by the addon with a meaningful label because JSON-RPC overwrote it with the item's path (which is probably not very useful in the case of a addon).

It's rather difficult to describe so here's an example. Let's consider a user accessing the youtube addon through the VFS (this is not possible yet but someone is working on it) so that would be a call to Files.GetDirectory with some plugin-specific path. When using the addon in XBMC it would e.g. return the following list of items:
- Label: Categories, Path: <basepath>/group1 Title: <empty>
- Label: Education, Path: <basepath>/group2 Title: <empty>
- Label: Feeds, Path: <basepath>/group3 Title: <empty>
- Label: Movies, Path: <basepath>/group4 Title: <empty>

So now JSON-RPC takes that data and replaces the "label" properties with the filename and returns a list like this:
- Label: group1, Path: <basepath>/group1 Title: <empty>
- Label: group2, Path: <basepath>/group2 Title: <empty>
- Label: group3, Path: <basepath>/group3 Title: <empty>
- Label: group4, Path: <basepath>/group4 Title: <empty>

So now what would the client use as a label to present those items to the user? The meaningful labels set by the addon have been replaced by JSON-RPC in favor of the filename (which can already be extracted from the "file" property) and the "title" property will be empty so the original label information is forever lost to the client and the user will be represented with a list of items named group1, group2, group3 and group4 but has absolutely no clue what they actually mean or do.

So the problem is that Files.GetDirectory can be used for a lot more than retrieving information about files that are in XBMC's library. For items returned by an addon there's no GetFooDetails method which will allow to retrieve extra information that wasn't provided by Files.GetDirectory. Therefore I don't think it's a good idea to abuse the "label" property for the filename just to get better/easier sorting.

With you. I didn't think of Addons.

(2012-03-30 08:45)Montellese Wrote:  Well in the future there might be more players available than now. Currently there is DVDPlayer, PAPlayer and Slideshow but there also is a branch with a DSPlayer and maybe there will be more in the future and they may have different playerid's.

Got it - thanks. I also hadn't paid enough attention that GetActivePlayers returned not only the ID, but the type. My bad.

(2012-03-30 08:45)Montellese Wrote:  Correct. I would look at one of the available JSON(-RPC) library (even if it's not in the programming language you'd like to use) and try to port their parsing to your programming language.

Probably going to have to tough this one out solo - the "examples" I've come across so far all seem to show how to massage data into a format that some pre-existing library will work with. Wish XML was an option. JSON seems nice and compact, but - and I'm probably missing something here - programmatically it's not efficient to parse when you're using a transport that doesn't guarantee you a complete message packet.

Thanks for the feedback, Montellese.

- Chip

---

I was doing some investigating with messages generated on the JSON-RPC TCP connection while using different parts of XBMC though the GUI. I got things like play/stop/pause notifications when using the video and audio players, but when I go and view something in the photo library or start a slideshow - nothing. Am I missing a notification setting?

Thanks,
- Chip

Using Files.GetDirectory with a smart playlist of 10 random movies it's returning a set as a movie; the "type" is "movie" but the "filetype" is "directory" whereas it's "file" for an actual movie. Is this a JSONRPC or more a smart playlist thing? I'm thinking either the smart playlist shouldn't return any movie sets or the "type" should be "movieset". Although you could use the "filetype" == "directory" = "movieset". Thoughts?

Just noticed the smart playlist is always putting the movie sets and then 10 random movies so there is a problem there as well.

(2012-04-01 00:45)Chip Moody Wrote:  I was doing some investigating with messages generated on the JSON-RPC TCP connection while using different parts of XBMC though the GUI. I got things like play/stop/pause notifications when using the video and audio players, but when I go and view something in the photo library or start a slideshow - nothing. Am I missing a notification setting?

Nope the slideshow is very badly integrated into XBMC as a whole and does work completely different than the music and video player and therefore you don't get any notifications from it. It also requires a lot of hacks to get all the other JSON-RPC Player and Playlist methods to work for slideshows.

(2012-04-01 01:47)Mizaki Wrote:  Using Files.GetDirectory with a smart playlist of 10 random movies it's returning a set as a movie; the "type" is "movie" but the "filetype" is "directory" whereas it's "file" for an actual movie. Is this a JSONRPC or more a smart playlist thing? I'm thinking either the smart playlist shouldn't return any movie sets or the "type" should be "movieset". Although you could use the "filetype" == "directory" = "movieset". Thoughts?

Just noticed the smart playlist is always putting the movie sets and then 10 random movies so there is a problem there as well.

That's probably because this was changed sometime during Eden feature freeze to the behaviour that a movie smartplaylist returns sets if it contains multiple movies belonging to the same set. I don't really like this behaviour either but apparently there are people who can't live without that feature being part of smartplaylists. And as Files.GetDirectory just reads everything as if it were a filesystem and doesn't really know what it gets it can't go about and look for things like movie sets etc.

(2012-04-01 10:03)Montellese Wrote:  

(2012-04-01 00:45)Chip Moody Wrote:  I was doing some investigating with messages generated on the JSON-RPC TCP connection while using different parts of XBMC though the GUI. I got things like play/stop/pause notifications when using the video and audio players, but when I go and view something in the photo library or start a slideshow - nothing. Am I missing a notification setting?

Nope the slideshow is very badly integrated into XBMC as a whole and does work completely different than the music and video player and therefore you don't get any notifications from it. It also requires a lot of hacks to get all the other JSON-RPC Player and Playlist methods to work for slideshows.

Ewww - bummer! Maybe I'll stick to integrating just the video & music players then. Thanks!!

- Chip