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)



- Montellese - 2011-09-20

Tolriq Wrote:Long time since not posting in this thread Smile

For Yatse i use infolabels :



All in one request this permit to have all the needed information for remotes to display and react to changes without having to make 3 or 4 request every seconds.

I also use :
"System.BuildVersion" and "System.ProfileName" to detect changes in profile and Xbmc version and ask users or auto change database on client side to avoid errors.

Thanks for that list. Some of those values should now be available through Player.GetProperties but others aren't. In case you want to make only one request but need to call multiple methods you might wanna consider using batch requests.

defender013 Wrote:hi all..
this is a really stupid and newb like question... (actually i am one..) but i was looking through the webAPI, which is now deprecated, it has support for changing guisettings.
I have not found this in jsonRPC. I even traced through the code, and i see that the only one actually accessing the gui functions is either through xbmcUtil or the webAPI.

am i missing something? are these in fact no longer supported? sorry for the stupid question, but i've searched for settings/guisettings/audiooutput (the one i'm interested in ) in json related wikis and posts for awhile, and i did not find anything specific.

You are right, there is no access to any settings/guisettings in jsonrpc yet. I have already looked into it a while ago but it's not that easy to do it simple and right. The way the http-api (webapi) does it is more of a hack than a real implementation and might cause some odd behaviour in xbmc's GUI if you change a guisetting at the wrong moment.


- topfs2 - 2011-09-20

Tolriq Wrote:"System.BuildVersion" and "System.ProfileName" to detect changes in profile and Xbmc version and ask users or auto change database on client side to avoid errors.

Oh System.BuildVersion could be a great way to get application specific information into the API, I propose Application.Version or something similair which could return an object containing members: "name", "major", "minor", "revision".

This would give us the opportunity to have clients look for JSONRPC.Version for the actual API version and what should be supported, then it can look at Application.Version to get a hint on what extra namespaces ought to exist (introspect is still the go-to here but nice to have a simply version and name compare). Also gives the possibility to see if its XBMC, Boxee or some other application using the API.


- Montellese - 2011-09-20

Tuesday, September 20th 2011:
Commits: 5abc022c3a353e206f78
  • Added "name" and "version" to Application.GetProperties

This takes care of System.BuildVersion from GetInfoLabels AND it allows to differ between applications (like Boxee using our jsonrpc API).


- topfs2 - 2011-09-20

Montellese Wrote:This takes care of System.BuildVersion from GetInfoLabels AND it allows to differ between applications (like Boxee using our jsonrpc API).

Note to anyone reading this. You should NOT alter any of the already existing methods in any way (looking at you boxee!), doing so voids any and all compatibility with the specification and between applications. Anyone wanting to use our API are free to do so but PLEASE do not alter just extend. Also, equally important, always target a STABLE release of the API (even numbers from JSONRPC.Version).

We will put in a README in the jsonrpc folder for this before eden but please, if anyone ever wish to use our API please consult me or Montellese and we'd be happy to explain what needs to be done to ensure compability.


- sling100 - 2011-09-20

Montellese Wrote:Sunday, September 18th 2011:
Commits: c4f161e177f5e079f2ba and 525833acf0b7fa3a9404
OK these two commits (especially the first one) are a huge step in the current jsonrpc API because they completely refactor the handling of players and playlists. First of all there will be no seperate VideoPlayer, AudioPlayer and PicturePlayer anymore but only one Player namespace. The same goes for VideoPlaylist and AudioPlaylist which has been replaced by a refactored Playlist namespace which even offers limited support for picture playlists (aka slideshows). Furthermore a lot of methods have been merged/refactored/moved. From now on the Playlist namespace simply represents a playlist (i.e. a sorted list of playable items) and does not provide any playback controlling functionalities anymore. Those have all been moved into the Player namespace because the players are responsible for playing items and not the playlists. I'm sure there will be quite a few questions about these changes so don't hesitate to post them here or ask me on IRC. Here is a more or less complete list of all important changes:
  • Merged AudioPlayer, VideoPlayer and PicturePlayer into Player
  • Merged AudioPlaylist and VideoPlaylist to replace Playlist and provide initial support for picture playlists (aka slideshows)
  • Players/Playlists are no longer accessed by their media type (video, audio, picture) but by a unique ID. Active players/playlists (their ID and media type) can still be retrieved using Player.GetActivePlayers/Playlist.GetPlaylists
  • Replaced Playlist.State with Playlist.GetProperties
  • Replaced Player.State, Player.GetTime and Player.GetPercentage with Player.GetProperties
  • Removed Playlist.SkipPrevious and Playlist.SkipNext (use Player.GoPrevious and Player.GoNext instead)
  • The following methods have been moved from the Playlist to the Player namespace: Play (renamed to Open), Shuffle, UnShuffle, Repeat
  • Refactored notifications for the Player namespace
  • Unified naming of position/item/index parameters in Player and Playlist namespaces
  • Merged XBMC.Play and XBMC.StartSlideshow into Player.Open
  • Make Playlist.Add, Playlist.Clear and Player.Open work for picture playlists
  • Replace Rewind and Forward with SetSpeed in Player namespace
  • Replace "value" parameter in "Player.SeekTime" with time struct parameters
  • Merge SeekTime, SeekPercentage and (Small|Big)Skip(Forward|Backward) into Seek in Player namespace
  • Add Player.SetAudioStream, Player.SetSubtitle and the properties "currentaudiostream", "audiostreams", "subtitleenabled", "currentsubtitle" and "subtitles" to Player.GetProperties

Is there a post somewhere listing the general changes to the methods for accessing these?

Thanks

Simon


- Montellese - 2011-09-20

sling100 Wrote:Is there a post somewhere listing the general changes to the methods for accessing these?

I'm not sure I understand. Most methods were either just renamed or moved to another namespace. Some methods were merged and only few methods were changed dramatically like Player.Open or Player.Seek.

In general calling JSONRPC.Introspect will (as usual) provide you with detailed information on which methods are available and what parameters they take.

If you have any specific questions to certain methods I'm happy to help out.


- sling100 - 2011-09-20

Sorry - didn't realise that you had updated the introspect - suppose I should have looked first really ....

I'll have a look later and post anything I can't fathom.

Thanks

Simon


- Montellese - 2011-09-20

sling100 Wrote:Sorry - didn't realise that you had updated the introspect - suppose I should have looked first really ....

I'll have a look later and post anything I can't fathom.

Introspect is always updated because it is part of the whole implementation. It is the interface definition for developers using XBMC's jsonrpc API and we use it to automatically validate parameters in XBMC.


- Tolriq - 2011-09-20

Montellese Wrote:Tuesday, September 20th 2011:
Commits: 5abc022c3a353e206f78
  • Added "name" and "version" to Application.GetProperties

This takes care of System.BuildVersion from GetInfoLabels AND it allows to differ between applications (like Boxee using our jsonrpc API).

Thanks for that Smile

Was hard to handle build with pre and other to load correct plugin to support all Xbmc versions Smile

I forgot one thing that i have remove from my code since it was not working correctly it was GetSystemInfo with param 667 to get the underlying OS but was getting lots of Busy instead of correct value.

This information can be used to display os icons Smile but also to detect changes on xbmc client. Since Yatse permit connexions to multiple Xbmc machine and have local database cache with thumb cache too, i used this to have one more check on if the user connects to the correct xmbc corresponding to the local database and not lost data and do a 1 or 2 GB of thumbs sync.


- Montellese - 2011-09-20

And some more action. Pay special notice to the last change as it will probably affect every client/app using jsonrpc:

Tuesday, September 20th 2011:
Commits: a03c34b37ae64637a9fd, 2a848458dbfd36d87058, 481a6007e899bdba21f2
  • Fixed value of "file" field for videos
  • Renamed "label" field for albums to "albumlabel" for consistency with the name of the returned property
  • Renamed "fields" parameters to "properties" parameters



- lewisc - 2011-09-21

Has anyone tried creating a .net (C#) XBMC remote app in Windows 8 with the new developer preview tools. I've tried creating an app with both dstruktiv's and Montellese's XBMC JSON .Net libraries and it will not connect to XBMC. Not only that it breaks the XAML designer after you reference the dll's (either XbmcJson.dll or XBMCJsonRpcSharp.dll). I've tried this connecting to Dharma and the latest nightly builds also.

Any ideas where I can start with this?


- Montellese - 2011-09-21

My library is far from up-to-date with the latest nightly builds. It should work with Dharma though but obviously I didn't test it on Win8.


- lewisc - 2011-09-21

It must be something to do with the way Windows 8 Metro style apps work differently to traditional Windows apps then as I couldn't get it to work with Dharma (although I could with a quick C#.net console application). I will keep investigating the problems with Windows 8.


- sling100 - 2011-09-21

OK, so I've got my head around the new player/playlist methods and they work really well. The one thing I can't figure is how to obtain the playlist position of the currently playing item. Is this something I can add to the Player.OnPlay notification? It returns the current song ID, but not position.

Thanks

Simon


- Montellese - 2011-09-21

sling100 Wrote:OK, so I've got my head around the new player/playlist methods and they work really well. The one thing I can't figure is how to obtain the playlist position of the currently playing item. Is this something I can add to the Player.OnPlay notification? It returns the current song ID, but not position.

Thanks

Simon

Well you can retrieve the current position using the "position" property in Player.GetProperties. That being said it might make sense to add that to the OnPlay notification. I'll think about it.