JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC

(2012-05-13 20:41)Montellese Wrote:  That's probably because XBMC updates the "playcount" property in the database so you'll get the VideoLibrary.OnUpdate notification.

The DB has zero for "watchedcount" on all tvshowview and episodeview so I don't think it's that.

IIRC the logic for sending the notification is pretty stupid. It doesn't really check if anything has changed. So if playcount is updated from 0 to 0 it still sends the notification as long as the update method is called.

I think it must be lastPlayed as I've just noticed the episodes I was testing with have it filled in. Obviously doesn't follow the same >80% counts as watched rule.

Ah that sounds right. I forgot about lastPlayed.

Monday, May 14th 2012:
Commit: 1e16f6f66c96f70bfdb7
These commits solve the problem of retrieving thumbnails and fanart provided by JSON-RPC after introducing the new texture caching functionality in the video library. With the new cache XBMC uses image://<path-to-real-file> URLs to relate to images. Currently this only is implemented for video artwork, music artwork still uses the old special://<some-path> URLs but they should both work. We used this opportunity to introduce a new image handler in the webserver which is meant to replace the existing VFS handler someday in the near future. This means that images can and should from now on be retrieved using the following HTTP URL: http://<ip>:<port>/image/<url-encoded-image-path> where <url-encoded-image-path> can either be a image://- or a special://-based URL. It is very important that the whole image-URL provided by JSON-RPC is URL-encoded because otherwise it will result in an invalid URL and will not work. If you're not sure what the resulting URL should look like, take a image-URL returned by JSON-RPC and use Files.PrepareDownload to retrieve the actual URL you should call. For the time being you can still use the "old" VFS handler but we plan to remove it because it is a huge security risk/hole.

As always feel free to ask if you have any questions/problems.

Just had a quick look and recent episodes gave me

I am right in thinking everything should still be local?

That got me confused at first as well. The new texture cache keeps track of images based on their original location and only caches an image (locally) if really necessary. So if you scrape an episode with TheTVDb, it will automatically get the episodes thumb from tvdb so the original location of that image is on thetvdb server so that's what XBMC uses to keep track of the image. When you request that image using the URI returned by JSON-RPC it will first check if the image is already cached. If that's the case it will return the cached image. Otherwise it will cache the image and then return it.

Ah, yes I see. Quick looks often result in fail

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.

(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.