[vdr] VDR 1.7.20 - Incorrect Progress Bar Times for Radio Programmes

[Chris Mayo]

On 27/08/11 15:24, Klaus Schmidinger wrote:
> On 27.08.2011 15:35, Chris Mayo wrote:
>> Progress bar display shows excessive times for radio programmes (no
>> video).
>>
>> A recording of about 5 minutes starts at 5:22:13 and ends at
>> 27404:47:54. The actual recording is fine. Recording is from BBC Radio 3
>> using DVB-T. ffmpeg -i shows:
>>
>> Input #0, mpegts, from '00001.ts':
>>    Duration: 00:05:06.12, start: 38666.622211, bitrate: 225 kb/s
>>    Program 132
>>      Stream #0.0[0x1b6](eng): Audio: mp2, 48000 Hz, stereo, s16, 192 kb/s
>>
>> I see the same playing with dvbhddevice or xineliboutput.
>>
>> Recordings made with previous versions of vdr (including 1.7.19 with
>> suggested reversion to 1.7.18 recording code) display correct times
>> playing with 1.7.20.
> 
> Please try this patch:
> 
> --- remux.c     2011/08/20 09:07:26     2.59
> +++ remux.c     2011/08/27 14:20:18
> @@ -840,7 +840,7 @@
>                      return Processed; // flush everything before this
> new payload
>                   if (framesPerSecond <= 0.0) {
>                      // frame rate unknown, so collect a sequence of PTS
> values:
> -                    if (numPtsValues < MaxPtsValues && numIFrames < 2)
> { // collect a sequence containing at least two I-frames
> +                    if (numPtsValues < 2 || numPtsValues < MaxPtsValues
> && numIFrames < 2) { // collect a sequence containing at least two I-frames
>                         const uchar *Pes = Data + TsPayloadOffset(Data);
>                         if (numIFrames && PesHasPts(Pes)) {
>                            ptsValues[numPtsValues] = PesGetPts(Pes);
> 
> 
> Apparently it got only a single PTS value and then was
> unable to calculate a difference.
> This patch fixed it for me (on the German radio channel
> ANTENNE BAYERN, which also showed the effect you reported).
> 
> Klaus
> 

That's fixed it for me too. Many thanks.

Chris