Unable to rebuild index on some French HD records

  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,
this patch may fix the initial index creation:


> 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.

Klaus
  

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

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

Best regards
>
> Klaus
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
  

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.

Klaus
  

Hi

Thanks for the patch, seems to work OK for now, as long problem was not on all 
recordings, long time of checking start ... will reactivate if necessary

@+


Le Sunday 18 April 2010 18:53:35 dplu, vous avez écrit :
> 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
>
> Will test your patch this week and see if it change or not index problem
>
> Best regards
>
> > Klaus
> >
> > _______________________________________________
> > vdr mailing list
> > vdr@linuxtv.org
> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr