Re: Unable to rebuild index on some French HD records

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx
> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
> _______________________________________________
> vdr mailing list
> vdr@xxxxxxxxxxx
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux