[samdret]

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

10.0 r35647 and yes, I tried to ask for more fields. Sorry for taking so long to respond.

Edit: Just realized that 10.1 is out. I'll update and see if that helps with anything

[Montellese]

10.0 r35647 and yes, I tried to ask for more fields. Sorry for taking so long to respond.

Edit: Just realized that 10.1 is out. I'll update and see if that helps with anything

10.1 won't help you on this one because there aren't any changes in JSONRPC in there. What I proposed only works with the latest nightly builds. So unless you switch to a recent nightly build you will have to wait till the release of Eden (11.0) to get what you want.

[othrayte]

I noticed that when items are removed from the library there is a VideoLibrary.OnRemove but when they are added there is a more generic VideoLibrary.OnUpdate, is there any reason why there isn't a VideoLibrary.OnAdd notification for this case?

[othrayte]

Also, when I receive a VideoLibrary.OnRemove I can't really do anything as the id that it points to has already been removed and as such I can't get any info about what was removed.

[topfs2]

I noticed that when items are removed from the library there is a VideoLibrary.OnRemove but when they are added there is a more generic VideoLibrary.OnUpdate, is there any reason why there isn't a VideoLibrary.OnAdd notification for this case?

OnAdd is OnUpdate but with previously nonexistant id. If you receive an OnUpdate and you do not have the ID in your cache its OnAdd for you, its hard for us to track if you have it or not so we don't really

OnRemove gives ID, its a method which is meant to be used by someone with a cache, so you should store the ID so you know what was removed. ID's are considered static between sessions.

[othrayte]

OnAdd is OnUpdate but with previously nonexistant id. If you receive an OnUpdate and you do not have the ID in your cache its OnAdd for you, its hard for us to track if you have it or not so we don't really

I had thought that it OnAdd would be called when an item had been added to xbmc's library, so it wouldn't matter if I had it yet or not. What I need is more like OnAddedToXBMC.

OnRemove gives ID, its a method which is meant to be used by someone with a cache, so you should store the ID so you know what was removed. ID's are considered static between sessions.

I can see why you have it arranged this way, and that it would be hard to do it any other way so I suppose it makes sense. It's a bit of a shame though that I'll have to add a cache to TU just for storing info encase the item gets removed from XBMC's library.
(I have a partially worked idea for caching all of TU's data, but it is much larger in scope, won't be finished for ages and doesn't currently store the local item id; because TU doesn't care if you have multiple copies only that you have one, so it stores by the imdb or equivalent.)

[topfs2]

I had thought that it OnAdd would be called when an item had been added to xbmc's library, so it wouldn't matter if I had it yet or not. What I need is more like OnAddedToXBMC.

Its better to just send OnUpdate, as you might have missed the OnAdd due to being offline. IMO its better if we "force" you to do a full fetch (i.e. update the cache) on first launch, then its easy for you to find out which is added.

An example, say you connect, we add X, you disconnect, we remove X, you connect, we add X. In this case its for you OnUpdate but we send OnAdd, so you need to coop with this case, might aswell always coop with OnUpdate

I can see why you have it arranged this way, and that it would be hard to do it any other way so I suppose it makes sense. It's a bit of a shame though that I'll have to add a cache to TU just for storing info encase the item gets removed from XBMC's library.
(I have a partially worked idea for caching all of TU's data, but it is much larger in scope, won't be finished for ages and doesn't currently store the local item id; because TU doesn't care if you have multiple copies only that you have one, so it stores by the imdb or equivalent.)

Yeah we are kindof required to do this. As stated elsewhere in this thread we have had the option of either send everything or send just minimal amount for queries in notifications and we have opted for the minimal route. Most often a client which listens to onremove has some form of cache, for you that would be on first connect do a full req on ID and imdb-id, then you keep listening to OnRemove. If you do that full request on startup you'd know when OnUpdate means newly added

[slash]

Hi,

Just to validate, VideoLibrary.GetMovieSets will return only the sets that have at least 2 movies assigned. Right ?

I believe it's a an XBMC standard behavior.

Can anyone confirm ?

Thanks

/

[gertjanzwartjes]

I noticed a difference between the AudioLibrary and VideoLibrary namespaces with a fresh XBMC instance without any database for video or audio. VideoLibrary.GetTVShows as well as GetSeasons and GetEpisodes nicely return a result object flagging there are no TV shows. However, AudioLibrary.GetArtists or GetAlbums, GetSongs return a result object being "null".

Is this deliberate? Maybe nobody noticed it, so I just wanted to share my experience. It's of course easy to guard against, but I thought maybe XBMC's JSON-RPC interface would or should always return a non-null result object for valid requests.

Thanks

[Montellese]

I noticed a difference between the AudioLibrary and VideoLibrary namespaces with a fresh XBMC instance without any database for video or audio. VideoLibrary.GetTVShows as well as GetSeasons and GetEpisodes nicely return a result object flagging there are no TV shows. However, AudioLibrary.GetArtists or GetAlbums, GetSongs return a result object being "null".

Is this deliberate? Maybe nobody noticed it, so I just wanted to share my experience. It's of course easy to guard against, but I thought maybe XBMC's JSON-RPC interface would or should always return a non-null result object for valid requests.

Thanks

Thanks for the report. Could you please create a bug ticket on http://trac.xbmc.org and CC me so that I don't forget.

[HardcoreWR]

Could someone please help me with Application.GetProperties

Code:

"Application.GetProperties": {
    "type": "method",
    "description": "Retrieves the values of the given properties",
    "transport": "Response",
    "permission": "ReadData",
    "params": [
      { "name": "properties", "type": "array", "uniqueItems": true, "required": true, "items": { "$ref": "Application.Property.Name" } }
    ],
    "returns": { "$ref": "Application.Property.Value", "required": true }
  },

translates for me to

Code:

'{ "jsonrpc": "2.0", "method": "Application.GetProperties", "params": [{ "properties": "volume" }], "id": 1 }'

I really can't figure this out ... Busy with this single JSON rule for like 6 hours now, and getting pretty annoyed by not getting it to work..

If someone could point me in the right direction, I would appreciate it ..

I'm using XBMC PRE-11.0 Git:Unknown (Compiled: Sep 11 2011)

[Montellese]

Could someone please help me with Application.GetProperties

Code:

"Application.GetProperties": {
    "type": "method",
    "description": "Retrieves the values of the given properties",
    "transport": "Response",
    "permission": "ReadData",
    "params": [
      { "name": "properties", "type": "array", "uniqueItems": true, "required": true, "items": { "$ref": "Application.Property.Name" } }
    ],
    "returns": { "$ref": "Application.Property.Value", "required": true }
  },

translates for me to

Code:

'{ "jsonrpc": "2.0", "method": "Application.GetProperties", "params": [{ "properties": "volume" }], "id": 1 }'

I really can't figure this out ... Busy with this single JSON rule for like 6 hours now, and getting pretty annoyed by not getting it to work..

If someone could point me in the right direction, I would appreciate it ..

I'm using XBMC PRE-11.9 Git:Unknown (Compiled: Sep 11 2011)

The "properties" parameter must be an array. What you did is to provide the "params" field as an array and the "properties" value as a simple string property. To achieve your goal you should try:

Code:

{ "jsonrpc": "2.0", "method": "Application.GetProperties", "params": { "properties": [ "volume" ] }, "id": 1 }

The value of the "params" field is an object containing all parameters (in this case only "properties") and the value of "properties" is an array of all properties you would like to retrieve.

[HardcoreWR]

The "properties" parameter must be an array. What you did is to provide the "params" field as an array and the "properties" value as a simple string property. To achieve your goal you should try:

Code:

{ "jsonrpc": "2.0", "method": "Application.GetProperties", "params": { "properties": [ "volume" ] }, "id": 1 }

The value of the "params" field is an object containing all parameters (in this case only "properties") and the value of "properties" is an array of all properties you would like to retrieve.

Mannnnnnnnnnnnnnnnn, I really don't know how to thank you!!!
This indeed does the trick .. thanks for your explanation.

I just started working with JSON, so not everything is very clear to me yet

[Raginn8]

I developed a heads-up version of control for XBMC (HTTP) within the AMX world sometime ago and have been using it with multiple clients for well over a year now. Lately I've been messing around with the JSON protocol in an attempt to create a head-less version of the module, and so far I like what I see however I do have some concerns/requests.

For instance when doing a GetDirectories it would be great to have a parameter that allows to request only directories, only files, or both. Currently the response is rather clunky.

I can also offer insight to what a typical AV client/server solution would include in terms of protocol (queries, system calls, etc).

I feel that the XBMC environment is nothing short of amazing, however from a high-end AV integration stand point it appears a bit stunted. My connections within this forum are none existant as I've only recently posted much of anything, however moving forward I would love to make a larger contribution. That said if there are any persons working within the development environment who would like to team up in this effort please let me know.

[Montellese]

Tuesday, September 13th 2011:
Commits: 6 commits from 0f12ea73fcef4b65ac89 to c93ea68b5428a9109140
Although there is no change in the functionality and the feature set of the jsonrpc API I finally found the time to further improve xbmc's implementation of JSON schema by covering more parts of the JSON schema specification. The newly added functionality include

• minLength and maxLength properties for JSON schema definitions of type "string" (no further explanation needed as they are pretty self-explaining)
  
• additionalProperties property for JSON schema definitions of type "object". This property can either have the value "false", which means that it is not allowed to provide additional properties (i.e. properties that are not explicitly defined in the types JSON schema definition) as part of the defined JSON object, or it can be a JSON schema definition which must be valid for any property that has not been explicitly defined.
  
• extends property for JSON schema definitions of any type. This new functionality is a bit more complicated than the others already present in xbmc's JSON schema implementation. It is similar to inheritance in object-oriented programming languages as it allows one type to extend the JSON schema definition of one or multiple already existing types. The specialty about "extends" is that an actual JSON object must validate both against the extended JSON schema definition(s) and against the extending JSON schema definition. That an extended type should never use "additionalProperties": false because otherwise the extending type cannot provide additional parameters.
  As a simple example let's look at the optimized JSON schema definition of "Player.State" and "Player.State.Extended":
  
  Code:

  "Player.State": {
    "type": "object",
    "properties": {
      "playing": { "type": "boolean", "required": true, "description": "" },
      "paused": { "type": "boolean", "required": true, "description": "" }
    }
  },
  "Player.State.Extended": {
    "extends": "Player.State",
    "properties": {
      "partymode": { "type": "boolean", "required": true, "description": "" }
    }
  }
  As you can see using the "extends": "Player.State" feature the "Player.State.Extended" definition inherits the "playing" and "paused" properties of "Player.State" and therefore won't have to define them itself (which up until now was necessary so that resulted in quite a bit of duplicate code).
  
• union type definitions: Up until now the "type" property of a JSON schema definition could either be a string defining a single type (boolean, integer, number, string, array, object, null) or an array of single types (e.g. [ "integer", "string" ] which means that the type is either an integer or a string). Additionally to that functionality it is now possible to use whole JSON schema definitions as part of the "type" property. To explain this let's look at the definition of "Playlist.Id":
  
  Code:

  "Playlist.Id": {
    "type": [
      { "type": "object", "properties": { "id": { "type": "string", "minLength": 1, "description": "Identification of a virtual playlist", "required": true } }, "additionalProperties": false },
      { "type": "object", "properties": { "file": { "type": "string", "minLength": 5, "description": "File from which to load a playlist", "required": true } }, "additionalProperties": false }
    ]
  }
  As you can see the definition only consists of the "type" property which is an array of two differing JSON schema definitions. That means that any JSON object which must be a "Playlist.Id" type can now either have a property "id" or a property "file" but a JSON object having both an "id" AND a "file" property is not a valid "Playlist.Id" object. Up until now this kind of definition was not possible and it was possible to provide both an "id" and a "file" property although it doesn't make any sense to provide both. This feature is also used in "Playlist.Item.Video" where (up until now) it was possible to provide an object containing not only a "movieid" property but also a "musicvideoid" property although "VideoPlaylist.Add" (which takes a parameter of type "Playlist.Item.Video") only allows to add a single video to the playlist.
  

For all those who find my explanations confusing (including myself) you can also take a look at the official JSON schema specification to read up on what those properties really do.