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 - joethefox - 2012-05-21

Thanks for the suggestion. JSONRPC.Ping could be perfect for my purpose, but even this seems unresponsive. At the moment I believe that I'm sending one request that is blocked because of the filesystem access before the JSONRPC.Ping, I will continue to do tests.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Livin - 2012-05-21

(2012-05-21, 21:41)Montellese Wrote:
(2012-05-21, 20:42)Livin Wrote: I hope you will consider adding some more usable info here. I'd like to track the usage for kids/guest/etc and better info is necessary to do so. Even something simple like passing <filename> as ' title' and properly identifying 'type' as "video file" or "audio file" (identifying anything unknown as "movie" causes tracking problems)
If JSON-RPC can't determine what kind of item is being played it should return "type": "unknown" unless the addon (or whatever you use to watch content that is not in the library) provides false information which leads to JSON-RPC using that for notifications.

Generally notifications should be as short as possible because they are messages that are "forced" on the client, it's not something a client manually requests. Furthermore they take up the transport medium for the time of the transport and no response to a (manual) request can be sent while a notification is being sent to the client.
Definitely agree. This is why I put in TRAC Feature Request #12830 to customize the JSON notifications, which in turn would allow many apps to reduce communication needs, I believe.
Also,

(2012-05-21, 21:41)Montellese Wrote: That being said I'm always open to specific ideas what could enhance Player notifications for non-library files. When this feature was requested during v3 we narrowed the most important properties down to what JSON-RPC currently sends. For a (non-library) movie the title and year should be enough to identify the movie with google or on IMDb or TMDb if getting more info is that important to a client.

I think there are more use cases for JSON beyond using it for 'lookup' info... which, even in this case, is not 100% viable if playing a 'file', since JSON is not sending a filename or media type.

Take my use case, for example:
I want to track and control (aka parental controls) the shows my 3 year old watches (yes, he knows how to use the media center). Most of his shows and movies cannot be scraped properly, they don't show up in standard media sites - and they change often (as he grows and becomes interested in new things) so manually adding library data is not viable.
I'd like to have JSON send me simply the media type (video, music) and the file name. This is usable data for tracking... and "actionable" in case he has reached his daily limit for a given genre of video or such. I can do this with my home automation (EventGhost & MiCasaVerde Vera) to control the entire entertainment center - media software and equipment.

This is just one example... I'm sure others will find more use cases. Hope this helps?

thx!



RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Martijn - 2012-05-21

I'm playing with the VideoLibrary.SetMovieDetails but need some help on how to get started with updating that info.

You got an example for me when i want to update the trailer field?



RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-05-22

(2012-05-21, 23:02)joethefox Wrote: Thanks for the suggestion. JSONRPC.Ping could be perfect for my purpose, but even this seems unresponsive. At the moment I believe that I'm sending one request that is blocked because of the filesystem access before the JSONRPC.Ping, I will continue to do tests.
Unfortunately I can't test this myself because all of my harddiscs are in the same machine and they never shut down completely while the machine is running. So file access is never really blocking.

(2012-05-21, 23:31)Livin Wrote: I think there are more use cases for JSON beyond using it for 'lookup' info... which, even in this case, is not 100% viable if playing a 'file', since JSON is not sending a filename or media type.

Take my use case, for example:
I want to track and control (aka parental controls) the shows my 3 year old watches (yes, he knows how to use the media center). Most of his shows and movies cannot be scraped properly, they don't show up in standard media sites - and they change often (as he grows and becomes interested in new things) so manually adding library data is not viable.
I'd like to have JSON send me simply the media type (video, music) and the file name. This is usable data for tracking... and "actionable" in case he has reached his daily limit for a given genre of video or such. I can do this with my home automation (EventGhost & MiCasaVerde Vera) to control the entire entertainment center - media software and equipment.

This is just one example... I'm sure others will find more use cases. Hope this helps?
Yes for non-library and non-addon items (i.e. if there is no meta data available whatsoever) providing the filename makes sense.

(2012-05-21, 23:34)Martijn Wrote: I'm playing with the VideoLibrary.SetMovieDetails but need some help on how to get started with updating that info.

You got an example for me when i want to update the trailer field?

Try
Code:
{ "jsonrpc": "2.0", "method": "VideoLibrary.SetMovieDetails", "params": { "movieid": 1234, "trailer": "some/path/to/the/trailer.avi" }, "id": 1 }
(and obviously replace the dummy values with the ones you need.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Martijn - 2012-05-22

(2012-05-22, 08:56)Montellese Wrote: Try
Code:
{ "jsonrpc": "2.0", "method": "VideoLibrary.SetMovieDetails", "params": { "movieid": 1234, "trailer": "some/path/to/the/trailer.avi" }, "id": 1 }
(and obviously replace the dummy values with the ones you need.

Did that last night but got error:

movieid wrong type (or something, can't remember exactly)
So i thought i was doing something wrong. Will try again and let you know


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-05-22

(2012-05-22, 08:58)Martijn Wrote:
(2012-05-22, 08:56)Montellese Wrote: Try
Code:
{ "jsonrpc": "2.0", "method": "VideoLibrary.SetMovieDetails", "params": { "movieid": 1234, "trailer": "some/path/to/the/trailer.avi" }, "id": 1 }
(and obviously replace the dummy values with the ones you need.

Did that last night but got error:

movieid wrong type (or something, can't remember exactly)
So i thought i was doing something wrong. Will try again and let you know

Just tested it with the latest nightly and it works perfectly fine for me. The exact error and version of XBMC you use would be useful Wink


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Millencolin007 - 2012-05-22

(2012-05-20, 10:48)Montellese Wrote:
(2012-05-20, 03:54)jonib Wrote:
(2012-05-19, 22:08)Montellese Wrote: Can you create a bug report for this on Trac? I won't have time to look into it in the next few weeks but it's certainly something that should be fixed.
Ticket 13050 created. Hopefully it has all needed info.

jonib

And fixed. Was actually easier than I thought. Back when I introduced notifications the old behaviour was the only way but someone must have adjusted/fixed the internal logic in the meantime so now Player.OnStop should always contain details independent of whether playback stops automatically or through user interaction.

With this change I loose my current way to distinguish if playback was stopped automatically or through user interaction. Any chance this info can be added back to the notification using an additional parameter or by sending a different notification if playback was stopped automatically or through user interaction?





RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Livin - 2012-05-22

(2012-05-22, 10:27)Millencolin007 Wrote: With this change I loose my current way to distinguish if playback was stopped automatically or through user interaction. Any chance this info can be added back to the notification using an additional parameter or by sending a different notification if playback was stopped automatically or through user interaction?

I agree this is valuable to know... specifically for Home Automation.

Example: The HA lighting system would do different things based on the method of playback stoppage...
a) stopped by user... lighting levels dim up a bit
b) stopped due to end of video... lighting levels go to normal/full

... etc




RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - mikebzh44 - 2012-05-25

Hello.

I'm looking to make a pictures slideshow when clicking on a widget. But I cannot use SlideShow() because pictures can be stored in differents directories.

So I'm using JSON and Playlist.Add to add differents pictures to playlist and play it.

But I can't add picture to playlist Sad

My code :
Code:
xbmc.executeJSONRPC('{"jsonrpc": "2.0", "method": "Playlist.Add", "params": {"playlistid": 1, "item": {"type": {"file" : "C:\Photos\Leane_20111207_195415.jpg"}, "id": 0}}, "id": 1}')

Error in LOG :

09:46:03 T:3736 ERROR: JSONRPC: Failed to parse '{"jsonrpc": "2.0", "method": "Playlist.Add", "params": {"playlistid": 1, "item": {"type": {"file" : "C:\Photos\Leane_20111207_195415.jpg"}, "id": 0}}, "id": 1}'
09:46:03 T:3736 NOTICE: ('JSON=', {u'jsonrpc': u'2.0', u'id': None, u'error': {u'message': u'Parse error.', u'code': -32700}})

I have also try :

Code:
xbmc.executeJSONRPC('{"jsonrpc": "2.0", "method": "Playlist.Add", "params": {"playlistid": 1, "item": {"file" : "C:\Photos\Leane_20111207_195415.jpg", "id": 0}}, "id": 1}')

As in this post : http://forum.xbmc.org/showthread.php?tid=68263&pid=1050628#pid1050628

But same parse error ?

Where is my mistake ? Does JSON playlist is the solution for playing picture slideshow from differents directories ?

Thanks.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - N3MIS15 - 2012-05-25

mikebzh44, playlistid: 2?


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-05-25

Yes using Playlist.Add is the right way but there are three errors in your request. First of all the first request is wrong, as there's no "type" property in the "item" parameter. The second request you posted looks better but the "playlistid" for picture playlists must be 2 and not 1 (1 is for video), you need to escape the backslashes in your path and the first "id" property in the "item" parameter does not belong there either. So it should look like this:
Code:
xbmc.executeJSONRPC('{ "jsonrpc": "2.0", "method": "Playlist.Add", "params": { "playlistid": 2, "item": { "file": "C:\\Photos\\Leane_20111207_195415.jpg" } }, "id": 1 }')



RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - mikebzh44 - 2012-05-25

Thanks guys.

Now pictures can be added to playlist and slideshow is played Wink

I thought that "type": and "id": was needed because if this :

Code:
{
  "type": [
    {
      "additionalProperties": false,
      "type": "object",
      "properties": {
        "file": {
          "required": true,
          "type": "string",
          "description": "Path to a file (not a directory) to be added to the playlist"
        }
      }
    },
  ],
  "id": "Playlist.Item"
}

http://wiki.xbmc.org/index.php?title=JSON-RPC_API/v4#Playlist.Item

Sorry to say but sometimes your JSON schema descriptions are hard to read and understand Sad


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - N3MIS15 - 2012-05-25

(2012-05-25, 10:40)mikebzh44 Wrote: Sorry to say but sometimes your JSON schema descriptions are hard to read and understand Sad

I agree, i had trouble understanding the schema at first. The descriptions seem to be taken straight from the introspect, maybe a few examples in the wiki could save some headaches/questions.


RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - mikebzh44 - 2012-05-25

I start the slideshow with :

Code:
xbmc.executeJSONRPC('{"jsonrpc": "2.0", "method": "Player.Open", "params": {"item": {"playlistid": 2, "position":0}}, "id": 1}' )

The slideshow start with the right picture but other pictures seem to be played in random mode.

Is there a way to play playlist in item order ? Those parameters cannot be used with playlistid ?

Code:
{
          "additionalProperties": false,
          "type": "object",
          "properties": {
            "path": {
              "required": true,
              "type": "string"
            },
            "random": {
              "default": true,
              "type": "boolean"
            },
            "recursive": {
              "default": true,
              "type": "boolean"
            }
          }



RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-05-25

I agree that JSON schema is not always easy to read (and sometimes even harder to write) but it's the best "standardized" way out there to describe JSON/JSON-RPC interfaces. For the easy parts of the JSON schema it's enough to just look at it to understand what it means but for more complex things like the definition of Playlist.Item you'll have to take a look at the definition of JSON schema.

I agree that a few examples wouldn't hurt but just updating the wiki page of the JSON-RPC API with the latest changes takes a while because the API has become huge and our wiki is so slow that I usually have to try it 10-15 times (with a 30 second wait between every try) until it accepts my changes.

If someone writes up some examples I'm more than happy to put them in there.