Tvheadend

I am evaluating using tvheadend + xbmc in an existing commercial application. We have nearly 20,000 linux boxes that display video and are centrally controlled. During my evaluation I have ran into a limitation that I believe is unique to how I am controlling XBMC.

First some background. In our application the user does not change channels, channel changing is controlled using a central server. Also, we require the ability to 'jump' between channels (e.g. go from the second channel to the twenty-fifth channel). To accomplish this we need to use the JSON-RPC service built into XBMC. I have put together a proof of concept prototype that does exactly this. However there are some rough edges that are no doubt unique to my fringe-case.

Hopefully someone here can help me understand what I am seeing so that I can resolve this.

When I open a htsp stream using the XBMC menu system, and then change channels using PageUP / PageDown the viewing experience rivals that of a regular television. (Most excellent and bravo to the developers for doing such an outstanding job btw.) However when I issue a JSON-RPC call (e.g. {"id":"6","method":"Player.Open","params":{"item":{"file":"htsp:\/\/localhost:9982\/tags\/0\/2.ts"}},"jsonrpc":"2.0"}) the channel change isn't nearly as seamless.

I expect that issuing the Player.Open method causes the existing stream to be closed before opening the new stream. This would account for both the visual discontinuity and longer channel change times. My understanding having read the HTSP spec is that the HTSP protocol handles channel changes internally, re-using the existing TCP connection. My assumption is that Player.Open does not re-use the existing connection, but opens a new TCP connection.

What I REALLY need, is for channel change behavior that behaves more like the what happens when PgUp / PgDown are pressed. The first call to Player.Open should initiate the TCP connection. Subsequent calls should identify that the base URL has not changed, and reuse the existing connection.

Are there any technical barriers that prevent this from being developed? We are not wed to the Player.Open method, but must use the JSON-RPC service to accomplish this. What is the best approach?

Kindest Regards,

Shannon Haworth