(2012-09-18, 15:40)Millencolin007 Wrote: But it would be a good thing if Files.GetDirectory always returns the artist the same way. Otherwise it does not match the definition from the json schema and it prevents you to use some higher level api to parse json objects directly to java.

(2012-09-18, 15:40)Millencolin007 Wrote: I already use the addons:// path in Music Pump to browse through the music and video addons but it has some issues(pops up progress dialogs on xbmc, search masks are hidden behind the progress dialog etc...) Those dialogs also make json-rpc block sometimes until the dialogs are clicked away. Far from perfect but it works

(2012-09-18, 15:43)Montellese Wrote:

(2012-09-18, 15:40)Millencolin007 Wrote: But it would be a good thing if Files.GetDirectory always returns the artist the same way. Otherwise it does not match the definition from the json schema and it prevents you to use some higher level api to parse json objects directly to java.

I thought that I had adjusted that in the JSON schema but maybe I'm wrong. Will fix. In your code you should just be able to check whether it's an array or a string and go from there.

(2012-09-18, 17:57)Tolriq Wrote: There's case like direct Class mapping in high level Json usage or direct streaming parsing in low level where checking if string or array or null depending on case is not really possible or needs very ugly hacks with bad perfomances.

(2012-09-18, 17:47)roli Wrote: Thank you for answering my question that fast. But I have another one. How can I get the filename of the media that is currently played? Or usually called label when you are browsing all files. The "Player.GetItem" can return many details but I don't see any option to get the file name. Problem is because my media is not sorted in library - I am just too lazy, so I am using XBMC to only play files. So I need the filename.

EDIT: Just figured out that passing an empty array in the request will return the label and type. Is that considered a "valid" solution?

(2012-09-18, 19:24)Millencolin007 Wrote:

(2012-09-18, 17:57)Tolriq Wrote: There's case like direct Class mapping in high level Json usage or direct streaming parsing in low level where checking if string or array or null depending on case is not really possible or needs very ugly hacks with bad perfomances.

I know. I am using gson since I was already familiar with this library and liked its direct json to class mapping.

Gson has a streaming mode which is nice for large data sets since it reads junk by junk. There is a function peek() which allows you to test the type of an object before processing it. This works actually really well but is a low level api which requires to write a lot of (boring) code.

I was trying to use direct class mapping for all requests which are not performance critical and used two different classes, one for api v4 and one for api v5 (after the big json change in august). But since Files.GetDirectory can return a string or an array in api level v5 this wasn't working properly. I think that it is possible to write a small deserializer to handle the array/string case properly. I just have to look into it.

(2012-05-15, 14:35)Montellese Wrote:

(2012-05-15, 14:10)dwagner Wrote: I'm having issues with the nightly builds (currently I am using the 12 May nightly build). I use Simple REST Client to do JSON testing in chrome, and it keeps giving me:
415 Unsupported Media Type

If I go back to the stable release of XBMC Eden, everything works fine.

Please always first take a look at this thread http://forum.xbmc.org/showthread.php?tid=98551 before you start using JSON-RPC with nightly builds. It will give you an overview of what has changed and in this case it will also give you the answer to your problem:

(2012-03-25, 13:51)Montellese Wrote: Tuesday, March 27th 2012:
Commit: adff92756087a50bb116
I just pushed a major refactor of how the webserver works internally. Currently this has only one effect on how it works and that affects JSON-RPC clients using JSON-RPC over HTTP. You need to make sure you set the Content-Type in the HTTP header to "application/json" and not something like "multipart/form-data" because that is plain wrong. The new implementation has the functionality to parse POST data for certain content-types (including application/json, multipart/form-data and application/x-www-form-urlencoded) and will therefore fail if the content-type does not match the actual POST data.