Skip to main content

Maximum duration value is not set during resizing the buffering TSB

4 replies [Last post]
ssathish
Offline
Joined: 2011-05-26
Points: 0

This post is intent to confirm the behavior of TimeShiftProperties.setMaximumDuration(long maxDuration).

Scenario:
- Select a service with minimum duration.
- Set maximum duration for the respective ServiceContext.

When setMaximumDuration is called, TimeShiftWindowClient.setDesiredDuration(duration) is invoked, but TimeShiftWindowClient.setMaximumDuration(duration) is left unused.
In TimeShiftWindow.updateForChangedDuration(), the condition for resizeBufferringTSB() method call is imposed based on 'buffering TSB size' and requested 'minimum duration'.
Though our intention is to intimate maximum duration value to RI platform, but the resize buffer method call condition is purely based only on minimum duration value in current logic.
This results, maximum duration is not set to native (IfsHandleImpl->maxSize) which in turn leads to consider the file as 'non circular' in IfsOpenImpl method in IfsImpl.c.

In TimeShiftWindow.updateForChangedDuration():

if ((bufferingTSB != null) && (bufferingTSB.bufferSize < m_constraints.minDuration))
{
resizeBufferingTSB(m_constraints.minDuration);
}

Query:
There is no maximum duration check to restrict the TSB for not to hold more than requested maximum duration value, isn't it?
If we want to implement the condition check to resize buffering TSB for maximum duration value, what is the required condition to impose?

Reply viewing options

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

There are two different concepts of "maximum" in the RI:

  1. The "maximum" duration set via TimeShiftProperties.setMaximumDuration() is non-limiting. The exact text of TSP.setMaximumDuration(): "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." So essentially this duration is just a "hint".
  2. The maximum duration at the platform level. Currently a platform can buffer as much content as it would like beyond the size supplied in mpeos_dvrTsbNew(). So technically restricting the duration of the TSB at the native level is not currently supported. But some of the infrastructure (e.g. TimeShiftContraints.maxDuration) is there to support it if/when necessary (The only use case I know of for restricting the duration is for CCI).

Some background: OCAP time-shift buffering - and the RI stack - is designed (as of DVR I03) to enable a platform to buffer as much content as it would like beyond the minimum duration. e.g. certain vendors expressed a requirement to allow all unused space on a storage volume to be used as timeshift. So the concept of "minimum" really represents the amount of buffering the platform *must* buffer and then it has latitude beyond this. So you'll notice that the RI never makes any assumptions about the fact that the TSB is circular/restricted.

I would say that updateForChangedDuration() needs a tweak to use the same math that startBuffering() uses:

long duration = Math.max(m_constraints.minDuration, m_constraints.desiredDuration);

I can make this change once the code freeze is lifted.

Let me know if this clarifies anything (or induces new questions).

ssathish
Offline
Joined: 2011-05-26
Points: 0

Thanks for your clarification.
As you said, the maximum duration can be fixed by including the below code in TimeShiftWindow.updateForChangedDuration().
long duration = Math.max(m_constraints.minDuration, m_constraints.desiredDuration);
resizeBufferingTSB(duration);
From my understanding of TimeShiftProperties.setMaximumDuration API java-doc, setting maximum duration "MAY be buffered", but it also specifies "Informs the implementation that storing more content than this is not needed by the application owning this ServiceContext". This insists to convey the required duration limit to native layer, isn't it?

cpratt
Offline
Joined: 2008-12-18
Points: 0

The setMaximumDuration() value (from TimeShiftProperties and BufferingRequest) probably could be communicated to the platform as a "soft/desired" maximum. I think it would make sense to add a "hard" maximum parameter at the same time to indicate an absolute limit - as is required in some CCI modes. I don't think this would change the TSB allocation method (mpeos_dvrTsbNew), as this method is essentially a TSB space reservation mechanism. These parameters could probably be added to mpeos_dvrTsbBufferingStart().

Can you file an issue for this? The former part of the work isn't high. But the CCI aspect of this is an oversight that should be remedied at some point.

ssathish
Offline
Joined: 2011-05-26
Points: 0

Thanks again.

Filed an issue tracker OCAP_RI-491.