Skip to main content

Should TimeShiftProperties.setMaximumDuration work if no service is selected in the ServiceContext?

4 replies [Last post]
Joined: 2009-12-22
Points: 0

The documentation for setMaximumDuration specifies that it can be called in any state of the ServiceContext:


Sets the maximum duration of content that MAY be buffered for this ServiceContext. Informs the implementation that storing more content than this is not needed by the application owning this ServiceContext.

This method MAY be called at any time regardless of service context state.

maxDuration Maximum duration in seconds.
IllegalArgumentException - if the parameter is less than the duration set by the setMinimumDuration method, or if the parameter is less than the duration returned by <a href="eclipse-javadoc:%E2%98%82=client-util/C:%5C/Users%5C/ldragan%5C/.m2%5C/repository%5C/org%5C/ocap%5C/ocap-stub%5C/1.1.3%5C/">OcapRecordingManager.getSmallestTimeShiftDuration</a>.
SecurityException - if the calling application does not have ServiceContextPermission(&quot;*&quot;,&quot;own&quot;) for the ServiceContext object that implements this TimeShiftProperties.


Is this javadoc accurate?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2008-12-18
Points: 0

I don't know of any inaccuracies in the Javadoc. But there are obviously a lot of things it doesn't say that are described in setMinimumDuration(). And there are semantics which are clarified in the TSP.getMaximumDuration() Javadoc:

Gets the maximum content buffering duration. If this method is called before setMaximumDuration has ever been called, or if content buffering is disabled for this ServiceContext the value returned SHALL be 0.


The maximum content buffering duration in seconds.

So it's clear that the maximum duration is persistent across selects. However there's no requirement (or limitation) on when it takes effect.

The maximum duration (both on TimeShiftProperties and BufferingRequest) is really just a "hint" to the stack regarding the calling application's buffering needs. There's no hard requirements behind these parameters. The name often leads people to believe it specifies a constraint. But OCAP really doesn't put any constraints on the amount of buffering an implementation may perform - allowing implementations/platforms to buffer content according to their respective abilities. e.g. if a platform allows all free disk/flash space to be used for time-shift buffering (instead of utilizing fixed-size/circular TSBs), they are free to do so.

Can you elaborate on where you think it's potentially inaccurate?

Joined: 2009-12-22
Points: 0

One of the vendors is seeing a NullPointerException when the maximum duration is set before calling We have received a fix that suggested to call before setMaximumDuration, but I think the existing code should work because there is no API requirement to call select before setMaximumDuration (the javadoc mentions that setMaximumDuration can be called in any state of the ServiceContext).

Joined: 2009-02-02
Points: 0

Would you please file a bug and attach the stack trace?



Joined: 2010-09-08
Points: 0


I am just posting here becasue I think this is kind of related but I was looking through the code and I noticed that after I do a servide select and try to resize the buffer by setting the maximum duration the buffer never changes. Now the default maximum buffer size in the RI simulator is Long.MAX_VALUE which is 9223372036854775807. The code in the RI(TimeShiftWindow) for changing the size of the buffer is this

if (bufferingTSB.bufferSize < tsbSize)
// Note: May throw IllegalArgumentException
// Assert: curTSW resize complete (in TSWSTATE_BUFFERING)
// or TSB restart cycle started (in TSWSTATE_BUFSHUTDOWN)

So the buffer will never be resized since the current buffer size is set to 65 hours and I want to resize it to 35 seconds.

code is located in line 1379.