Kodi Community Forum

topfs2 Wrote:Well we have had the discussion internally and came to the conclusion that its impossible to tell what information the client wants. The only solution to that problem would either be send everything or just enough to query the server (which we have chosen). The benefit of query is that a client may utilize a cached copy if they so desire, further limiting the bandwith required by json-rpc clients. If the data presented in OnPlay isn't enough to query the server however, that would be a problem (which OnStop seems to lack in your example here, so please make a trac ticket for that).

Ah, a mistake on my part I mean to provide two onPlay examples, please ignore the onStop one that should be:
{"jsonrpc":"2.0","method":"Player.OnPlay","params":{"data":{"speed":1,"type":"episode"},"sender":"xbmc"}}

I agree that you should only provide the minimum required to identify the item, but in the case of streaming items where there is no associated id, the minimum required info for a tv episode is the title, season number and episode number.
So what would be good would be if you cant provide the id that the title etc is provided, because at the moment it is impossible to tell what is playing, (without the really bad request to get current playing item and trying to extract the data from the url)

othrayte Wrote:Ah, a mistake on my part I mean to provide two onPlay examples, please ignore the onStop one that should be:
{"jsonrpc":"2.0","method":"Player.OnPlay","params":{"data":{"speed":1,"type":"episode"},"sender":"xbmc"}}

I agree that you should only provide the minimum required to identify the item, but in the case of streaming items where there is no associated id, the minimum required info for a tv episode is the title, season number and episode number.
So what would be good would be if you cant provide the id that the title etc is provided, because at the moment it is impossible to tell what is playing, (without the really bad request to get current playing item and trying to extract the data from the url)

Hmm, well that is a bug I'd say (or untested ). If you could create a small example script or something and put it in a trac ticket cc me and montellese that would be perfect.

I guess it happens if the item is not in the db (say stream from youtube or something?)

Hi Guys,

Is there any reason why "MusicPlayer.Cover" does not return any info?

Response


"MusicPlayer.Property(Fanart_Image)" works fine.

Response


Cheers
Jason

Hi Guys,

Thanks for all your help and putting up with my basic questions. I've got one more for you though it has nothing to do with JSON I just thought I would post here because you have some kind of idea what I am trying to achive. If you want to remove this post or want me to start a thread somewhere else please say so.

I'm currently creating a widget for a Nevo S70 remote control that runs a cut down version of Windows Mobile 6. The remote also has a web browser. The problem is that the remote does not know what a .tbn file is and will not download the image. It only supports .png, .bmp, .jpg or .gif (non-animated).

So my question is would it be possible to write a script that would also generate a .jpg image in the XBMC Thumbnails folders as well as the .tbn file?

I have also manually added some .jpg images of the .tbn files to the Thumbnails folders to try which works or is this not recommended to do?



Cheers
Jason

jasonvp Wrote:I'm currently creating a widget for a Nevo S70 remote control that runs a cut down version of Windows Mobile 6. The remote also has a web browser. The problem is that the remote does not know what a .tbn file is and will not download the image. It only supports .png, .bmp, .jpg or .gif (non-animated).

So my question is would it be possible to write a script that would also generate a .jpg image in the XBMC Thumbnails folders as well as the .tbn file?

No not really, we do set the mimetype which makes it work on all webbrowsers afaik. tbn can be anything but defined via the header and the mimetype, mostly so its easier for us to handle the internals. Anyways, it would be better if we actually stored png and jpg instead of tbn. There is a trac ticket regarding it IIRC.

jasonvp Wrote:Hi Guys,

Is there any reason why "MusicPlayer.Cover" does not return any info?

Code:

{"jsonrpc":"2.0","id":1,"method":"System.GetInfoLabels","params":{"labels":["MusicPlayer.Cover"]}}

Response

Code:

{"id":1,"jsonrpc":"2.0","result":{"MusicPlayer.Cover":""}}

"MusicPlayer.Property(Fanart_Image)" works fine.

Code:

{"jsonrpc":"2.0","id":1,"method":"System.GetInfoLabels","params":{"labels":["MusicPlayer.Property(Fanart_Image)"]}}

Response

Code:

{"id":1,"jsonrpc":"2.0","result":{"MusicPlayer.Property(Fanart_Image)":"special://masterprofile/Thumbnails/Music/Fanart/b18ea041.tbn"}}

Cheers
Jason

The correct way to get the thumbnail of currently playing is via AudioPlaylist.GetItems, much how its done on in AudioLibrary.

Quote:The correct way to get the thumbnail of currently playing is via AudioPlaylist.GetItems, much how its done on in AudioLibrary.

Thanks.

I realize that you can get it that way it's just that I use "System.GetInfoLabels" a lot because you can get a lot of different info returned without having to send multiple JSON strings to get the same thing. Just seems more efficient for me.

The reason for this method is because Nevo S70 Widgets allow you to create 2-way control easily without the need to write any code, just need to do some regex but the downside of Widgets is that they don't do unsolicited feedback so any announcements from xbmc are ignored. This means that on my Now Playing page which displays info like Current Song, Artist, Album, Playlist Position/Length, Player Time/Duration (used for a slider bar for seeking), next Song and other stuff is asked for every 4 seconds because it's the only way to ensure the remote is in sync and all with one string...if you know what I mean.

Nevo remotes do have another option besides Nevo Widgets which is called ".Nevo Plugins" which does do unsolicited feedback but you need to know how to write code, which I don't. I have the SDK for it and would love to learn but just don't have the time to at the moment.

So that's why it would have been great to use "MusicPlayer.Cover" to easily add Album Art to my Now Playing page. Anyway I'll just have to use AudioPlaylist.GetItems instead.

One other thing I noticed is when I go to Music/Songs and say I have 100 songs listed (haven't ripped all my CD's yet). I select play for the first song and then I select shuffle and the song that is currently playing may end up in position e.g. 85. Why does songs positioned at 85 to 100 only play? I would have thought the currently playing song would stay at position 1 and the rest of the 99 songs would be shuffled and would all play.


Cheers
Jason

jasonvp Wrote:Thanks.

I realize that you can get it that way it's just that I use "System.GetInfoLabels" a lot because you can get a lot of different info returned without having to send multiple JSON strings to get the same thing. Just seems more efficient for me.

Sure, We are however contemplating removing it for the next version. Mostly since its rather unstable and its very dynamic (doesn't depend on the json version but on the skinning version, which isn't good). We will probably have it until we are sure that the majority of the stuff is fetchable via other mechanisms though.

You might want to look into batch requests, it adds a bit more bw than the GetInfoLabels but atleast its in one go.

topfs2 Wrote:You might want to look into batch requests, it adds a bit more bw than the GetInfoLabels but atleast its in one go.

Where can I find info on batch request?


Cheers
Jason

EDIT: Don't worry I found it here.

Hi Guys,

In my library setup i have not checked 'include artists that only appear on various artists albums' so when i list my artists in the default skin all of the VA albums are grouped under 'Various' (well.. to be honest they are not all there, but they are not scattered through my artists list either so its all good), however when i request all artists (unsorted) via JSON-RPC i get a list of artists 10 times longer than it should be because it is listing all artists, including those appearing only on VA albums.

Has this been discussed? Ideally the complete artist list should have a single entry for 'Various' and when you request albums with the artistid associated with this entry it should return all 'Various Artists' albums.

dann0 Wrote:Hi Guys,

In my library setup i have not checked 'include artists that only appear on various artists albums' so when i list my artists in the default skin all of the VA albums are grouped under 'Various' (well.. to be honest they are not all there, but they are not scattered through my artists list either so its all good), however when i request all artists (unsorted) via JSON-RPC i get a list of artists 10 times longer than it should be because it is listing all artists, including those appearing only on VA albums.

Has this been discussed? Ideally the complete artist list should have a single entry for 'Various' and when you request albums with the artistid associated with this entry it should return all 'Various Artists' albums.

Hmm, never tried this tbh. It sounds like partly a bug. Ideally it should behave as in GUI (perhaps with the option to query all artists no matter the setting). Please start a bugreport / feature request with a detailed list of how to reproduce (if you could upload your or a sample database that would also be quite nice, its up to you) and cc me and Montellese.

I agree that the GetArtists should only by default return those which are in GUI, we could add a GetArtist(allow_various=true) type of thing though which forces it to return them no matter the setting.

Hi Guys,

Is it normal that when nothing is playing?

Returns

I would have thought it would return,


Cheers
Jason

Hmm, well if no player exist it cannot execute the method, not sure if it should be this explicit or we could have the players be a bit more virtual.

With the new player merge it would be correct to fail to execute as we have id's for each player. I'll discuss this a bit internally, please submit a bugreport nevertheless so we remember it (or can have the discussion there). Feel free to cc me and Montellese.

I have been digging in the JSON HTTP/TCP api for a while now and what can I say but nice Work!
I have found a bug in 9090 port binding. witch affects XBMC 10,10.1, and the git mainline. When xbmc starts the first couple of seconds and you do a JSON request i.e VideoLibrary.GetMovies the json socket will not bind or it will crash...



Regards!

topfs2 Wrote:Hmm, well if no player exist it cannot execute the method, not sure if it should be this explicit or we could have the players be a bit more virtual.

The reason I asked was because I initially created a Widget for a Boxee Box for a friend and that got me interested in XBMC. So rather than reinventing the wheel I thought I would just add to my already made Widget for use with XBMC. This is also another reason why I'm using "System.GetInfoLabels" a lot because the Boxee Box has limited JSON commands.

When using "AudioPlayer.State" with the Boxee Box it returned the below even though no player was active.


I was just curious. Sorry for being be a pain in the bum.

Quote:With the new player merge it would be correct to fail to execute as we have id's for each player. I'll discuss this a bit internally, please submit a bugreport nevertheless so we remember it (or can have the discussion there). Feel free to cc me and Montellese.

Will do if you think it's worth the trouble?


Cheers
Jason

jasonvp Wrote:The reason I asked was because I initially created a Widget for a Boxee Box for a friend and that got me interested in XBMC. So rather than reinventing the wheel I thought I would just add to my already made Widget for use with XBMC. This is also another reason why I'm using "System.GetInfoLabels" a lot because the Boxee Box has limited JSON commands.

When using "AudioPlayer.State" with the Boxee Box it returned the below even though no player was active.

Code:

{"id":3,"jsonrpc":"2.0","result":{"playing":false}}

I was just curious. Sorry for being be a pain in the bum.



Will do if you think it's worth the trouble?


Cheers
Jason

Oh interesting, I wasn't aware that they merged in our json code. Well they should only merge it on stables (as thats when we freeze json-rpc), so their return should be the one in Dharma (which I think it is). So you should check against jsonrpc.version and either only work with a specific version (even is stable, odd are development. 2 = dharma, 4 will be eden). With boxee having json-rpc we might revisit the json-rpc versioning so that they can merge a bit in between too, but this is something we would need to discuss a bit internally, will let you guys know if we change versioning.

Anyways, try JSONRPC.Version on their server, it really should return 2 otherwise they have merged development builds (which isn't good).