khargy Wrote:So after I called player.open for the video playlist I called:

Code:

{"jsonrpc": "2.0", "method": "Player.Shuffle", "params": [1], "id": 1}

I get an "ok" result but when I go to the next item it's still in order.

khargy Wrote:Ok, so this is interesting... sometimes when I called my video playlist I would use "path" and sometimes I would use "file", so:

Code:

{ "jsonrpc": "2.0", "method": "Player.Open", "params": { "item": { "path": "special://profile/playlists/video/all videos.m3u"  } }, "id": 1 }

Code:

{ "jsonrpc": "2.0", "method": "Player.Open", "params": { "item": { "file": "special://profile/playlists/video/all videos.m3u"  } }, "id": 1 }

if I use "file" it plays the video in order, but if I use "path" it plays them randomly... but with "path" it seems to be playing them in player ID 2 which, if I understand things correctly is the picture player.

Although I'm still getting the issue where on the 2nd play it'll get stuck on the GUI - sometimes it'll say "loading" forever, but if I just send the play.open command again it'll go.

grywnn Wrote:Just noticed that Files.getSources no longer returns a file/directory name per source, only a label (XBMC OS X, build from 10/09).
Pretty useless this way
Got no time to open a ticket, but can do tomorrow if necessary.

grywnn Wrote:BTW Player.getItem is GREAT!

Montellese Wrote:As you can see we already had to break backwards compatibility for all those namespaces just to get a clean API on which we can build in the future without having to break backwards compatibility again.

topfs2 Wrote:The API is far from backwards compat already in the move from v2 -> v4 (even if not great changes), thus we decided that we might aswell do ALL non-backwards compat changes which has bugged us. This to make less changes (perhaps even keep backwards compat) in the next upcomming versions.

EDIT: Also you all should consider v2 (dharma) to have been just a taste of whats to come, it was never really finished and was mostly added as a showcase. Eden (v4) is looking rather finished and polished. While we have lots of ideas for the future it is very cleaned out and should be maintainable.

• Refactored Files.Download into Files.PrepareDownload and Files.Download. Using jsonrpc over HTTP Files.PrepareDownload does, what Files.Download did until now. It provides a URL which can be called to download the file (beware the answer format has changed). The idea behind the changes is that some transport layers will support direct download through Files.Download while others (like HTTP) will not and in that case the method name "Download" may be confusing. That's why we split the functionality into Files.PrepareDownload (which will be available over HTTP) and Files.Download (which will not be available over HTTP because it's not supported).
  

mzanetti Wrote:Hi,

Thank you once again for the work on this API. My remote control app is turning out great and has already quite a lot of users. One feature request that pops up frequently is to add things like "c" or "i" to the Input namespace to be able to open the context menu and info dialogs.

mzanetti Wrote:Hi,

Thank you once again for the work on this API. My remote control app is turning out great and has already quite a lot of users. One feature request that pops up frequently is to add things like "c" or "i" to the Input namespace to be able to open the context menu and info dialogs.

jasonvp Wrote:@Montellese
How long do you think the HTTP API will be in use for?

Montellese Wrote:We want to get rid of it ASAP after Eden has been released. I'm aware that this will cause problems with some applications that use methods that are not exposed by jsonrpc but the team decided that some of the things exposed by the http api should not be made accessible to third party applications the way it has been done by the http api (which sometimes is done through very fugly hacks) so we might have to drop some things and re-introduce them later in jsonrpc but only if we find a nice and controllable way to expose them.

• Changing the playcount of a movie or episode
  
• Get the local movieid or showid given an imdbid/tvdbid or title
  

othrayte Wrote:I've been meaning to speak up about this for a while, in Trakt Utilities we use the json rpc extensively but there are a few things we still need to use the httpapi for

othrayte Wrote:

• Changing the playcount of a movie or episode
  

othrayte Wrote:

• Get the local movieid or showid given an imdbid/tvdbid or title
  

Montellese Wrote:I have already done some work on this which will allow to call something like VideoLibrary.SetMovieDetails() and provide some fields and values which should be changed. It's not completely ready yet as we don't know yet how to make certain that nothing goes sideways if an application executes a call that will set invalid data, but this is something we want to make available soon after Eden has been released.

Montellese Wrote:"Custom" db queries through jsonrpc have been requested a few times already. The problem is that XBMC itself doesn't really support this (apart from browsing by year, director etc). So json-rpc would have to hack around the lack in xbmc core which isn't a very good solution IMO.

1. That is is in the db
   
2. The imdb id, title & year (We currently only support this for movies)