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

(2012-05-06 13:28)Mizaki Wrote:  To confirm all Player.OnPlay give the error:

Code:

Received unexpected continuation frame.

and closes the socket.

This should be fixed with https://github.com/xbmc/xbmc/commit/b8a3...1c3dbf3a5b and please let me know if you encounter any other problems with websockets.

Just trying with audio. Notifications have some problems:
Next: I get notified twice
Prev: I get Player.OnSeek. I realise why. Because it go to the beginning of the song.
Play/Pause: No notification.
FF/RW: Are fine. Either with pressing play or using the opposite to cancel the other.
Stop: Fine.

Are you on a recent master build (specifically since AE has been merged)? Because gnif has re-written the whole PAPlayer (which handles music like mp3 etc) and it seems like he didn't really care about the callbacks used by XBMC to create the notifications in JSON-RPC, python etc. I noticed the same thing today and will let him know that he needs to re-add them where necessary.

Yes, AE. Do you want the video ones or wait for gnif?

The video ones should still work fine, at least they did when I used them to test my websocket fix.

I get VideoLibrary.OnUpdate notifications when using next or prev as well as the expected.
That's pressing previous twice. OnSeek goes to the beginning and looks fine and then when moving to play the previous video the OnUpdate as well.

I'd like to request notification of subtitles on/off and audio stream changes. Shall I do them separate or as one FR? Also, what are your thoughts on passing the current statuses when first opening a websocket? I can of course just request the current state manually but I was thinking it would be "nice" if on opening you received OnPlay if XBMC is playing.

And I guess the reason the vfs thumbnail etc. path is now wrong/not showing images is the work on the cache? Should I just ignore it for now?

Thanks.

(2012-05-13 16:47)Mizaki Wrote:  I get VideoLibrary.OnUpdate notifications when using next or prev as well as the expected.

Code:

{"jsonrpc":"2.0","method":"Player.OnSeek","params":{"data":{"item":{"id":1874,"type":"episode"},"player":{"playerid":1,"seekoffset":{"hours":0,"milliseconds":-727,"minutes":0,"seconds":-17},"speed":1,"time":{"hours":0,"milliseconds":0,"minutes":0,"seconds":0}}},"sender":"xbmc"}}

{"jsonrpc":"2.0","method":"Player.OnPlay","params":{"data":{"item":{"id":2213,"type":"episode"},"player":{"playerid":1,"speed":1}},"sender":"xbmc"}}

{"jsonrpc":"2.0","method":"VideoLibrary.OnUpdate","params":{"data":{"item":{"id":1874,"type":"episode"}},"sender":"xbmc"}}

That's pressing previous twice. OnSeek goes to the beginning and looks fine and then when moving to play the previous video the OnUpdate as well.

That's probably because XBMC updates the "playcount" property in the database so you'll get the VideoLibrary.OnUpdate notification.

(2012-05-13 16:47)Mizaki Wrote:  I'd like to request notification of subtitles on/off and audio stream changes. Shall I do them separate or as one FR?

Please create seperate feature requests on trac. There's also subtitle changes not only on/off.

(2012-05-13 16:47)Mizaki Wrote:  Also, what are your thoughts on passing the current statuses when first opening a websocket? I can of course just request the current state manually but I was thinking it would be "nice" if on opening you received OnPlay if XBMC is playing.

You can create a feature request for it but it will probably be very far down on my todo list.

(2012-05-13 16:47)Mizaki Wrote:  And I guess the reason the vfs thumbnail etc. path is now wrong/not showing images is the work on the cache? Should I just ignore it for now?

Yup, they should be fixed as soon as we merge PR958. There will also be a new way to retrieve images through the webserver because we plan to get rid of the access through /vfs/.... to get more control over what can be accessed through the webserver. But for a while both the "old" /vfs/... and the new /image/... access will work.

This mean you won't extend http to support partial request for easy streaming ? :'(

(2012-05-13 20:50)Tolriq Wrote:  This mean you won't extend http to support partial request for easy streaming ? :'(

Hm where/when did I say that? I just said that the access to the VFS will be removed from the webserver because it is as big a security hole as it can get.
When someone adds support for video/music streaming it will (most likely) be done with a streaming-specific handler in the webserver which will support all the necessary things for real streaming and not some half-arsed implementation through the VFS.

It's clear vfs is not gootd but not sure http streaming will come soon

Not talking about access to cd-art or download of the trailers when available.

Was just wondering of how the transition will come, not more.