Incorrect Duration displays for long recordings

[eDVBMetaParser]

The data member m_length (which stores the recording duration in 1/90000sec units) is declared as an int, which means that it wraps around to negative if the recording duration is longer than ~398min (longer than (2^31 -1)/90000 sec).

The field is also read using atoi() and written using the printf("%d") code which also truncate the value, even if stored correctly.

This can lead to no duration, or the incorrect duration, being displayed for the "Duration" display for the recording in the media player.

This bug was originally reported for long recordings from HDMI IN, but the bug affects all recordings.

There are other fields in eDVBMetaParser that are also incorrectly typed (m_time_create should be time_t, not int and m_filesize should be off_t, not int), but these types are the correct size and do not cause data truncation. If they are corrected, there are some flow-on effects for some other functions' return types, printf strings and string-to-integer conversion functions.

eStaticServiceM2TSInformation::getInfo() and eStaticServiceDVBPVRInformation::getInfo() also have a value return type (int) that is too narrow for the off_t return value when they are passed iServiceInformation::sFileSize as the information type.

Replication steps

Make a recording with a duration 398 min or longer (e.g. 7 hours = 420 min).

When the recording completes, open the media player (MEDIA from live TV), and navigate to the recording. For a 7-hour recording, the Duration will be empty.

View the recording's .ts.meta file. For a 7-hour recording, the duration (line 6) will be negative, resulting from the 64-bit pts_t used for the duration having been stored in a 32-bit signed integer.

Navigate away from the recording in the media player and adjust the duration in the .ts.meta file to the correct value by adding 2^32 (4294967296) to it.

Navigate a back to the recording, it will show an incorrect duration, for a 7-hour (420 min) recording it is 397min40sec. This appears to be due to the out-of-range value being returned as (2^31 - 1) (0x7fffffff).

Comments (6)