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 - 2010-10-18

topfs2 Wrote:Hmm, seems like introspect is wrong. will look into it

I just checked the source code and it seems that the only valid parameters are "playlist-virtual" or "playlist-file". If none of these parameters is present it tries CPlayListPtr(). If I understand it correctly CPlayListPtr() should point to the currently active playlist but it seems like it doesn't in my case (although I was listening to a music album while issuing the call).


- topfs2 - 2010-10-18

Montellese Wrote:I just checked the source code and it seems that the only valid parameters are "playlist-virtual" or "playlist-file". If none of these parameters is present it tries CPlayListPtr(). If I understand it correctly CPlayListPtr() should point to the currently active playlist but it seems like it doesn't in my case (although I was listening to a music album while issuing the call).

CPlayListPtr means null shared ptr, i.e. no playlist.

The Playlist is not to be used for playing anymore, at some point it might be that again but needs lots of core redesign for it to work properly (in discussion).

For playing stuff use AudioPlaylist or VideoPlaylist, they should be considered extended Playlists or a special case of them, should have roughly the same features though


- Montellese - 2010-10-18

topfs2 Wrote:CPlayListPtr means null shared ptr, i.e. no playlist.
Ah I should have taken a closer look.

topfs2 Wrote:The Playlist is not to be used for playing anymore, at some point it might be that again but needs lots of core redesign for it to work properly (in discussion).

For playing stuff use AudioPlaylist or VideoPlaylist, they should be considered extended Playlists or a special case of them, should have roughly the same features though

Good to know thanks. Video-/AudioPlaylist support more features apart from Playlist.Create, Playlist.Destroy and Playlist.Swap but these don't look like they would be used regularly.

I'm currently looking into the duplicate PlaybackStopped announcement in the code. If I find anything useful I'll let you know.


- topfs2 - 2010-10-19

Montellese Wrote:Ah I should have taken a closer look.
Hehe, tbh a client creator really shouldn't need to even look through the code at all but its still in development so some bumps is expected Smile


- Montellese - 2010-10-19

topfs2 Wrote:Hehe, tbh a client creator really shouldn't need to even look through the code at all but its still in development so some bumps is expected Smile

I absolutely don't mind looking in the code. If I wouldn't have looked into the code I would have no idea about all the announcements XBMC provides.
Should I edit the JSON RPC wiki article when I find wrong or come up with missing information or is that still to early because the possibility that it will change again is pretty high?


- Montellese - 2010-10-19

EDIT: I'm an idiot. I looked at the trunk source instead of the dharma branch. Well seems like I'll have to hunt down the duplicate PlaybackStopped again. Sorry for the inconvenience.
But I noticed that it doesn't happen all the time. Normally I get a PlaybackResumed (see below) followed by a PlaybackStopped but occasionally I get no PlaybackResumed but two PlaybackStopped.

I hunted the dispensible PlaybackResumed announcement down in the source and found this in PAPlayer.cpp on line 279:
Code:
bool PAPlayer::CloseFileInternal(bool bAudioDevice /*= true*/)
{
  if (IsPaused())
    Pause();                      <-- This is where the PlaybackResumed is announced

  m_bStopPlaying = true;
  m_bStop = true;

  m_visBufferLength = 0;
  StopThread();                <-- This is where the PlaybackStopped is announced

  ...
I guess there is a reason why the playback has to be unpaused first before stopping it.
So what I tried is to move the line "m_bStopPlaying = true" above the pause-check and add a condition for "if(!m_bStopPlaying)" at line 443 right before the PlaybackResumed announcement is initiated.
That seems to work fine but I don't know if it could produce any weird sideeffects. I checked all usages of m_bStopPlaying and didn't see anything "dangerous" but maybe I missed something.
Should I create a patch for this or is there a better way to do it?


- slash - 2010-10-19

topfs2 Wrote:GetSources probably should give tem, via parameter to aggregate autoadded sources (such as optical and dvd) probably.

Files.Download will just give you direction on how to download based on your current transport. Http will just give you a URL you can access, TCP at some point might give you a port and so on.

ScanForContent won't take a parameter of path since its hard / impossible to make proper (other thread regarding this matter).

Refresh might be interesting, not sure how to code it up but definatly a nice thing if possible. Seems perfect to be able to refresh scanned items via the web interface.

As for library manipulations, I'd say its appropriate to do them via httpapi for the time being. It is planned to be doable via jsonrpc at some point. Probably needs the security addition (mostly to display them in gui, a dialog that asks if client foo can have these permissions etc.).

Please add tickets and cc me so we don't forget them.

Thanks,
Added tickets in track
http://trac.xbmc.org/ticket/10546
http://trac.xbmc.org/ticket/10547
http://trac.xbmc.org/ticket/10548

Let me know if I can help in anyway, I'm slow at C++ coding but I don't mind trying.Wink

/


- Montellese - 2010-10-19

I did some more digging into the code concerning the fact that the "playing" is always set to "true" when calling Audio-/VideoPlayer.GetTime/.GetTimeMS/.State and found this in the AVPlayerOperations.cpp at multiple occasions:
Code:
result["playing"] = g_application.IsPlaying();
result["paused"] = g_application.IsPaused();
I then did some searching on the IPlayer.IsPlaying() and found out that it doesn't actually tell you whether a song/video is playing or not but rather that the player itself (DVDPlayer, PAPlayer, ExternalPlayer) is active (although the current song/video might be paused).

Is this the inteded use in JSON RPC? If so I don't understand why because whenever IPlayer.IsPlaying() returns false it also means that the player is not active at all and therefore can't even be accessed through the JSON RPC API because it only allows you to access the currently active player.
Why are there two items "playing" and "paused" anyway? Doesn't the value of one automatically imply the value of the other?


- topfs2 - 2010-10-19

Montellese Wrote:I did some more digging into the code concerning the fact that the "playing" is always set to "true" when calling Audio-/VideoPlayer.GetTime/.GetTimeMS/.State and found this in the AVPlayerOperations.cpp at multiple occasions:
Code:
result["playing"] = g_application.IsPlaying();
result["paused"] = g_application.IsPaused();
I then did some searching on the IPlayer.IsPlaying() and found out that it doesn't actually tell you whether a song/video is playing or not but rather that the player itself (DVDPlayer, PAPlayer, ExternalPlayer) is active (although the current song/video might be paused).

Is this the inteded use in JSON RPC? If so I don't understand why because whenever IPlayer.IsPlaying() returns false it also means that the player is not active at all and therefore can't even be accessed through the JSON RPC API because it only allows you to access the currently active player.
Why are there two items "playing" and "paused" anyway? Doesn't the value of one automatically imply the value of the other?

Hmm, I really dislike our interfaces at times. Might be that should be result["playing"] = g_application.IsPlaying() && !g_application.IsPaused();


- Zarquon - 2010-10-20

I'm making the following JSON call and was wondering what fields were available for return? Specifically I was hoping I could retrieve the air date and run time.

Code:
{"jsonrpc": "2.0", "method": "VideoLibrary.GetRecentlyAddedEpisodes", "params" : { "start" : 0 , "end" : 15 , "fields": [ "director", "year", "rating","showtitle", "season", "episode","plot" ] }, "id" : 1 }

Any help would be appreciated.


- Tolriq - 2010-10-20

All the fields can be found here :

http://trac.xbmc.org/browser/trunk/xbmc/lib/libjsonrpc/FileItemHandler.cpp

just check the FillVideoDetails or FillMusicDetails Smile

You are looking for :
firstaired and runtime Smile


Developers, its time to thing of users !! - vaton4 - 2010-10-20

Hi to all. I am not sure this is the right thread for my laments, but seems it is populated by the people who can help.
I am relatively new XBMC user, but a quite experienced computer professional (in the battlefield since 1968), so I do not need help frequently. This time I need.

Recently I tried the new (Dharma) web control interface and I must say I am a bit confused. I can connect without problems ... but if XBMC is not allready playing, it's allmost all I can do.

At the bottom I see just big gray rectangle; at the top there are REMOTE, MOVIES, TV SHOWS, MUSIC, and SETTINGS fields, but they seem to be dead - If I point to some field, its background color changes, but clicking does nothing except the 'ajax-loader.gif' icon shows and starts to rotate. No directories, no files, no controls, no messages, no help ...

If XBMC is allready playing (thanks to heavens the infra remote and wireless keyboard work for me), I can see album and track info, timing info, next track info and basic control butons. Buttons seem to work as expected, but no playlist, no playlist edition, no volume control. And again, no directories, no files to build playlist. Beyond this, track name sometimes changes properly, somtimes does not (reloading page helps here).

In the Wiki there is just a very, very brief description of the obsolete interface and list of JSONRPM functions for developers. No description, no user help.

Would finally developers of this nightmare make this part of XBMC more user friendly, please ??


- topfs2 - 2010-10-20

vaton4 this is development thread about jsonrpc, not webinterface. Please ask your questions in the correct forum. And before you post again, please read through the docs about how to submit a proper bugreport.


- Zarquon - 2010-10-20

Tolriq Wrote:All the fields can be found here :

http://trac.xbmc.org/browser/trunk/xbmc/lib/libjsonrpc/FileItemHandler.cpp

just check the FillVideoDetails or FillMusicDetails Smile

You are looking for :
firstaired and runtime Smile
Thank you. This is exactly what I was looking for and this is great for reference. Unfortunately "runtime" do not seem to be supported in that return value for VideoLibrary.GetRecentlyAddedEpisodes but "duration" is.

The only problem seems to be that duration isn't always populated. Any ideas?


- Montellese - 2010-10-20

Did anyone else notice a strange behaviour of the "rating" field when using AudioLibrary.GetSongs()? I always get
Code:
"rating": 48
for all songs. It works fine for AudioLibrary.GetAlbums() but I noticed that this one is handled differently in the JSON RPC code:
Code:
if (item->IsAlbum() && item->HasProperty(field))
{
  if (field == "album_rating")
    object[field] = item->GetPropertyInt(field);
  else
    object[field] = item->GetProperty(field);
}

Or is there a reason that the value is 48 for every song? I check the "song" table in the MyMusic7.db database file and saw that most of the songs have a rating of 0.