[Montellese]

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.

[Mizaki]

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.

[Montellese]

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.

[Mizaki]

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

[Montellese]

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

[Mizaki]

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.

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.

[Montellese]

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.

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.

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.

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.

[Tolriq]

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

[Montellese]

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.

[Tolriq]

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.

[Mizaki]

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.

[Montellese]

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.

[Mizaki]

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.

[Montellese]

Ah that sounds right. I forgot about lastPlayed.

[Montellese]

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.