[vdr] Unable to rebuild index on some French HD records

Klaus Schmidinger Klaus.Schmidinger at tvdr.de
Sun Apr 25 16:54:19 CEST 2010

On 04/18/10 18:53, dplu wrote:
> Le Sunday 18 April 2010 16:11:20 Klaus Schmidinger, vous avez écrit :
> Hi
>> On 13.04.2010 17:44, dplu wrote:
>>> Hi
>>> When we delete index file on some HD recording due to synchronous problem
>>> for editing, sometimes vdr is not able to rebuild it , start for few
>>> seconds and generate an errors
>>> Stream has "something" in it, you can add mark but not navigate between
>>> without crashing vdr , when playing records, time goes not seconds to
>>> seconds but every two seconds
>> If the index is initially wrong, and ok after regenerating it,
> It is not ok until the buffer size is increased ...
>> this patch may fix the initial index creation:
>> --- remux.c     2010/02/28 14:42:07     2.42
>> +++ remux.c     2010/04/05 09:32:57     2.43
>> @@ -817,7 +817,7 @@
>>                   if (synced && Processed)
>>                      return Processed;
>>                   if (Length < MIN_TS_PACKETS_FOR_FRAME_DETECTOR * TS_SIZE)
>> -                    return 0; // need more data, in case the frame type is
>> not stored in the first TS packet +                    return Processed; //
>> need more data, in case the frame type is not stored in the first TS packet
>> if (!frameDuration) {
>>                      // frame duration unknown, so collect a sequence of
>> PTS values: if (numPtsValues < MaxPtsValues && numIFrames < 2) { // collect
>> a sequence containing at least two I-frames
>>> Is it possible for next release to increase the buffer size to 300
>>> instead of 100 in recording.c , class cIndexFileGenerator ? This has been
>>> tested successfully by at least two users with same problem
>> I don't see how increasing this buffer size would change anything.
>> cFrameDetector::Analyze() needs to see MIN_TS_PACKETS_FOR_FRAME_DETECTOR
>> packets, which is a mere 376 byte. So even a much smaller buffer should
>> work.
>> But maybe I'm missing something here and somebody can point out why
>> increasing this buffer size would actually change anything.
> Not sure but what happen if the size of data stream between two keyframes is 
> greater than max buffer value ? You will never be able to have inside one 
> buffer range two I frames at the same time ? HD stream in France are not full 
> standard, maybe to prevent copy or other

Only two subsequent TS packets are used to analyze the where a new frame starts.

> Will test your patch this week and see if it change or not index problem 

I would expect this patch to fix the problem. I don't see why increasing the
buffer size would help.


More information about the vdr mailing list