Skip to main content

Behavior of stack when requestSetMediaTime() is set beyond EOF and played back.

6 replies [Last post]
karun_m
Offline
Joined: 2010-09-21
Points: 0

Hi,

In HN scenario, lets say that RecordedContentItem.requestSetMediaTime() is set beyond the EOF and then played back what should the implementation do? - It should thrown NormalContentEvent followed EndOfContent?

Please clarify the implementation behavior in this scenario.

Thanks in advance,
Karun

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

A media time request is communicated in HN by passing a TimeSeekRange.dlna.org header in the HTTP get request.

According to DLNA, if the TimeSeekRange.dlna.org represents a request for a range outside of available content, the request will be denied with a status code 416 (range not satisfiable), and the client will receive a SelectionFailedEvent.

karun_m
Offline
Joined: 2010-09-21
Points: 0

Hi Scott,

Thanks for your reply. I still have few questions. Kindly answer them too.

I am referring to DVR I06 spec section 6.2.1.2.1 (rules apply to players presenting recorded content) and below are my questions:

Pre Condition: I am setting RecordingContentItemImpl.requestSetMediaTime(...) / RecordedServiceImpl.setMediaTime(...) with media time more than recorded content duration.

1. Isn't the implementation should set the playback point to end of recording and send End Of Content?

2. Assuming that End Of Content is sent, how do applications will listen to those events without getting hold of player. To get hold of player isn't they need a normal content event?

Thanks,
Karun

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

Hi Karun,

I've tried multiple times to post a reply but it was flagged by their spam software for moderation. If it doesn't show up by tomorrow I will find someone else to try to post my response.

Scott

site_support
Offline
Administrator
Joined: 2011-07-06
Points: 0
Hi Scott, We have published your response. Unfortunately, sometimes legitimate comments are sent to moderation.
scottdeboy
Offline
Joined: 2009-02-02
Points: 0

Hi Karun,

Regarding question 1:

requestSetMediaTime does cause the default playback position of a recording content item and the default playback position of a recorded service to be 'synced' (HNP 2.0 I08, section 6.8.5.3).

HNP section 6.10.11 describes setRate/setMediaTime, and clarifies that "For network actions, implementations SHOULD handle this in a manner specific to the negotiated transfer protocol." As the application can't know which transfer protocol was negotiated, applications can't rely on any semantics, particularly at content boundaries.

The HN client implementation passes a TimeSeekRange.dlna.org header in the HTTP request when requesting a specific media time during initiation of recording content item playback. As there is no overriding language in HNP, DLNA spec restrictions apply, and a 416 status code is returned to the client if the request is outside of the available content range, resulting in a SelectionFailedEvent being sent to registered ServiceContextListeners.

However, if the request is within the available content range, and the content boundary is encountered, the RI implementation -does- currently change the rate to zero when end of content/beginning of content events are received from the platform, and an org.ocap.shared.media Beginning/EndOfContentEvent is posted. This is at least partially supported by a NOTE in HNP Figure 6-1 referencing a change to rate zero at content boundaries, although there is no normative spec text that would cause this behavior to be required.

Regarding question 2:

Yes, this is an issue - there is no reliable way to get a reference to the Player prior to reception of the initial ServiceContextEvent. An application could poll the media time to see if media time is moving forward. As the RI implementation behavior at the content boundary is not implementing 'normative' spec behavior, relying on the rate being set to zero is not going to give application developers a reliable solution.

I hope that helps - let me know if I can provide more information.

Scott

karun_m
Offline
Joined: 2010-09-21
Points: 0

Thanks Scott for your answers!

--
Karun.