topfs2 Wrote: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

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

othrayte Wrote: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.)

gertjanzwartjes Wrote: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

HardcoreWR Wrote: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)

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

• 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.