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)



- carmenm - 2011-04-04

i just tested the tcp Notification system and i think is great.
Two things though:
- I think that it would be great to send a playing/paused status report when a client connects to XBMC and XBMC is playing. That would prevent form having to ask and we would be sure to have the good state when connecting.
- When i stop playing a movie i get a notification
Quote:{"jsonrpc":"2.0","method":"Announcement","params":{"data":{"movieid":12,"speed":1},"message":"PlaybackSpeedChanged","sender":"xbmc"}}
is that normal?

THanks


- topfs2 - 2011-04-04

While it is arguably nice to get the state on connect its hard to justify it being sent. Its not really xbmc's job to make sure the state is correct at the client, i.e. xbmc doesn't necessarily know what the client wants.

For example say you make a client which allows you to manipulate the library but handles nothing playback worthy, is it sane sending that even then, how can xbmc know this.

What initial states should we send, if playback then it might make sense making sure that the library state is correct, which essentially means sending every item id in the library.

As you see from these examples its not possible really. If xbmc knew what states the client is indeed interested in then yes, we could. but it may need a redesign of the API, for very little benefit. Most RPC's out there assumes that the client gets the initial states afaik.


- carmenm - 2011-04-04

topfs2 Wrote:For example say you make a client which allows you to manipulate the library but handles nothing playback worthy, is it sane sending that even then, how can xbmc know this.
But you send it to any client when play state changes. You dont let the client ask for it!
To me if you notify the client of state change, you should first notify it of the initial state.

But it s not a big deal for me Laugh.


- topfs2 - 2011-04-04

Well we send only state changes, which is by far less bandwith in the library case. And atm we do set those on by default for easy development, that might change at some point.


- Montellese - 2011-04-04

carmenm Wrote:But you send it to any client when play state changes. You dont let the client ask for it!

You can use JSONRPC.SetAnnouncementFlags() to tell XBMC which notifications you would like to receive. But (according to the specification) notifications/announcements are something every client receives and not something you send to only one connected client. So you should not send a notification to a single (newly connected) client anyway because you'd have to send it to every client available.


- carmenm - 2011-04-04

@Montellese: ok i get the way it works for Notifications. My state machine will ask for playing state on connection. Thanks for taking the time to explain.


- carmenm - 2011-04-05

Montellese Wrote:First call "Player.GetActivePlayers" to determine the currently active player (audio, video or picture). If it is audio or video call Audio/VideoPlaylist.GetItems and read the "current" field to get the position of the currently playling item in the playlist. The "items" field contains an array of all items in the playlist and "items[current]" is the currently playing file. You can also tell jsonrpc which fields to return for every item in the playlist and therefore you'll have all the information you need.

finally had the time to test this. It works great expect that most fields i ask for are not returned.
For example tagline, season, episode, imdbnumber, runtime.
In fact movieid would be enough but i cant get this one either.
I tried to create an issue on trac but didnt find where to register Confused
will try again tomorrow.


- Montellese - 2011-04-05

Everyone interested in JSON RPC please read http://forum.xbmc.org/showthread.php?p=767487 carefully.


- ppic - 2011-04-05

thanks for the infos Smile


- Kabooga - 2011-04-05

Thank you for the hard work. Been waiting for this Big Grin

Cheers.


- carmenm - 2011-04-05

Great. You did an amazing job!


- carmenm - 2011-04-05

i am now playing with the new json. It is really really great!
I especially love the new introspect and the error responses!!!

Now time for the questions:
-VideoPlaylist.GetItems : is there a way to get the Library.Id if there is one? That could be very useful if we then want to do something like VideoLibrary.GetMovieDetails

-about sending multiple request a the same time. If i take the example of VideoLibrary.GetMovies and VideoLibrary.GetTVShows. WOuld it make responses time shorter if sending both at the same time ( i am taking that example as i suppose they access the database, and that you say in introspect that cast and set may make response time longer)

Thanks a lot for that big update. It helps a lot while developing.


- topfs2 - 2011-04-05

carmenm Wrote:i am now playing with the new json. It is really really great!
I especially love the new introspect and the error responses!!!

Now time for the questions:
-VideoPlaylist.GetItems : is there a way to get the Library.Id if there is one? That could be very useful if we then want to do something like VideoLibrary.GetMovieDetails

-about sending multiple request a the same time. If i take the example of VideoLibrary.GetMovies and VideoLibrary.GetTVShows. WOuld it make responses time shorter if sending both at the same time ( i am taking that example as i suppose they access the database, and that you say in introspect that cast and set may make response time longer)

Thanks a lot for that big update. It helps a lot while developing.

If you send two requests at the same time they will be done in sync, they will have less overhead (as you only have one httpheader for both requests). So it depends a bit on your needs.

For example the webserver can execute more than one request at a time so if you send A which takes 1 minute and B which takes 30 s, doing that in sync will take 1min and 30s. if you send them seperate with extra overhead it will take roughly 1 min in total for both.

So consider it as transactions in normal databases, if you need them to be in sync use that feature, otherwise you can do them at the same time. As said, if overhead is an concern it can also be useful (getmovies + gettvshows return so much data overhead is of no concern). Say you want time of playback you can bundle that in with something else as the return is almost the same as the overhead probably Smile


- carmenm - 2011-04-05

ok i get it. I see the point of no use for Getmovies or gettvshows now.
I also get the idea of something like playback time at the same time as something else.
i just dont know how to implement it on my side Wink

A remark on getPlaylistItems. WIth the new version all fields return something. But some fields are empty for tvshows even if the info exists on xbmc.
It happens for runtime, rating, tagline, genre

Do i add a bug for that?

Thanlks


- Montellese - 2011-04-05

carmenm Wrote:A remark on getPlaylistItems. WIth the new version all fields return something. But some fields are empty for tvshows even if the info exists on xbmc.
It happens for runtime, rating, tagline, genre

Do i add a bug for that?

Do you mean info of tv episodes? Because a playlist item can not be a tv show, but only a tv episode. "genre" and "tagline" are no valid fields for a tv episode but "runtime" and "rating" are. Please create a bug ticket so I don't forget about it.

EDIT: I just tested it and it works fine for me. For some reason I get an empty string for "runtime" but that also happens when calling VideoLibrary.GetEpisodes. The "rating" values show fine on VideoPlaylist.GetItems for me.