Skip to main content

HN Server not reusing the streams between normal and trick play.

5 replies [Last post]
shobanapeter
Offline
Joined: 2006-07-29
Points: 0

When the client requests for a play speed change, RI server cleans up the resources, opens a new session afresh and starts streaming in the requested playspeed. There is a scheduled cleanup for the old stream. But within the timeout if trick play request comes, RI doesnot seem to reuse the same stream. It opens a new session which allocates resources again. Was this the intended design?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
scottdeboy
Offline
Joined: 2009-02-02
Points: 0

The client initiates a play speed change via an HTTP GET. On the server side, there is a socket associated with the HTTP GET request, and the 'session' models the portions of the request which won't change for the duration of that socket connection. See the mpe_HnStreamParamsMediaServerHttp struct in mpeos_hn.h for more details on which parameters which don't change for the duration of the connection (for example, the profile ID).

The 'playback' server-side struct (mpe_HnPlaybackParamsMediaServerHttp) represents parameters which may change during the socket connection. For example, if CCI is encountered, the previous playback is stopped and a new playback is started (using the same socket) from a new start position with different CCI.

shobanapeter
Offline
Joined: 2006-07-29
Points: 0

Thanks for the reply, But i still have few doubts.

Does it mean, the client has to use the same socket for a trick mode change without closing the original connection. But the OCAP HNP recommends to close the connection when switching from normal to trickplay.
"It is recommended by [DLNA vol 1] that the connection be closed and re-opened when changing the play speed."
My concern is also on the performance. Every time when the client requests for a trick mode change if the server has to release all the resources, say close the DVR/TSB file , setup again and start
streaming again, wouldn't that be a performance hit? A socket cannot be reused but DVR resources could be reused.

scottdeboy
Offline
Joined: 2009-02-02
Points: 0

The client can choose to initiate trick mode requests using the same socket or a new socket - the server makes no assumptions about the socket.

TSB resources aren't released immediately after the last TimeShiftWindowClient is released - there is a timer and a setting which controls how many seconds elapse before the TSB is released after the last use. In dvr.properties (can be overridden in final.properties):
OCAP.dvr.tsb.tswDeathTime=5

shobanapeter
Offline
Joined: 2006-07-29
Points: 0

Thanks Scott, so every HTTP-GET request would require the stack to open a new streaming session, even if it be the same connection id /different. If the client has the same connection id, shouldn't the recording stream be reused? Is my understanding right? What if the client's trick request comes and is processed by the server before it processes the stopping of the normal play. There could be a race condition there.The resources might be exhausted and the trick request may not get the resources allotted at all. I still think the stack should reuse the reording stream objects if the connection ids are similar.

scottdeboy
Offline
Joined: 2009-02-02
Points: 0

The connection ID allows the client to inform the server that this new connection is part of a logical session, but the client is not required to provide a connection ID. We have to support both modes and can't assume a connection ID will be provided by the client, so each connection is its own session.

There can be race conditions where a client uses different sockets on each request and the second connect is seen prior to the first close, but that is always possible - a client could choose to simultaneously issue multiple GET requests with different ranges in order to try to speed up client-side caching.

The connection ID is used to track streams primarily because NetSecurityManager#revoke provides an activityID (connectionID).

I did notice what I believe to be a bug, in that HEAD requests should be going through NetAuthorizationHandler2#notifyActivityStart, but they aren't. I'll file a bug for this.