Skip to main content

Proposed unit change for mpeos_dvr.h:MPE_DVR_RECORDING_LENGTH

  4 posts   Feedicon  
Replies: 3 - Last Post: June 14, 2012 02:49
by: cpratt
showing 1 - 4 of 4
Posted: April 26, 2012 02:13 by cpratt
The units for MPE_DVR_RECORDING_LENGTH (passed to mpeos_dvrRecordingGet() returning a uint64_t) are currently specified as seconds.

However, org.ocap.shared.dvr.RecordedService.getRecordedDuration() specifies that it returns "The duration of the recording in milli-seconds."

I'm proposing the units for MPE_DVR_RECORDING_LENGTH be brought in parity with the getRecordedDuration() and return milliseconds instead of seconds. This will have an additional benefit in providing a more accurate res@duration value for HN-exported RecordingContentItems.

Detailed change:

Index: mpe/os/include/mpeos_dvr.h
===================================================================
--- mpe/os/include/mpeos_dvr.h  (revision 32730)
+++ mpe/os/include/mpeos_dvr.h  (working copy)
@@ -242,7 +242,7 @@
     MPE_DVR_RECORDING_SIZE,
 
     /**
-     * Current length (in seconds) of this recording</td>
+     * Current length of the recording (in milliseconds)</td>
      */
     MPE_DVR_RECORDING_LENGTH,

Questions and comments welcome.

Posted: May 11, 2012 19:57 by dhooley
Should we consider adding a new API that (correctly) returns the milliseconds value, and keeping the old API that (incorrectly) returns the seconds? We would switch our Java code to call the new API.
Posted: May 24, 2012 19:40 by cpratt
There isn't really an API signature change for this (MPE_DVR_RECORDING_LENGTH is a value provided to mpeos_dvrRecordingGet()).

I suppose we could introduce a MPE_DVR_RECORDING_LENGTH_MS property that the stack would attempt to query first to retrieve the recording length and then retrieve MPE_DVR_RECORDING_LENGTH if that fails. But we'll need to depend on platforms returning an error code (e.g. MPE_DVR_ERR_INVALID_PARAM) when MPE_DVR_RECORDING_LENGTH_MS is provided. MPE_DVR_RECORDING_LENGTH would be documented as "deprecated".

e.g. The RI platform returns MPE_DVR_ERR_UNSUPPORTED when an unknown parameter is supplied. So it would operate in a backwards-compatible way.

The only concern here is that MPEOS ports may not feel a need to update their implementation to support the new value with the old value still being present. Perhaps stronger wording suggesting that the property will be removed in the future.

I'll go with this approach unless there's further comment/suggestions.
Posted: June 14, 2012 02:49 by cpratt
The mpeos API change, and the associated RI stack and RI platform changes are committed to the RI trunk with changes 35120 and 35150.

MPE_DVR_RECORDING_LENGTH_MS will be queried first and if the platform doesn't return a value (if it doesn't return MPE_SUCCESS) the (now-deprecated) MPE_DVR_RECORDING_LENGTH property will be queried, which should allow for backward compatibility.

Note, however, that the MPEOS/Emulator code (mpeos_dvr.c) and JNI was treating this value as a uint32_t when it's designated as a uint64_t in the mpeos_dvr.h file.
Replies: 3 - Last Post: June 14, 2012 02:49
by: cpratt
 
 
Close
loading
Please Confirm
Close