Mailing List archive

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

[vdr] Re: More about free space on hd



Guido Fiala wrote:
> 
> > > To state it clearly: My disk had many many Gigabytes free for the
> > > resulting files - think it's a problem in the frame-parser which
> > > accidently makes the cutting thread believe EOF is reached...
> >
> > During the cutting process VDR doesn't parse any frames (this is done only
> > during recording, when the index.vdr file is generated). The cutting
> > process just uses the information from index.vdr to locate the positions
> > stored in the editing marks and "shovels" the necessary frames from the
> > original recording into the new recording (and creates the new index.vdr
> > file on the fly).
> >
> > > @Klaus: if it would help i can try to cut out the section (e.g. using
> > > split) and send only a small file to you - how large would it have to be?
> >
> > I don't believe this would help. You'd probably have to send the entire
> > file, and that's way too much data.
> >
> > If the problem is actually reproducable, you could add several debug
> > outputs to cCuttingBuffer::Action() to see what exactly goes wrong. Maybe
> > there _is_ a problem somewhere in there that only comes up in specific
> > cases...
> 
> Fortunately (???) it is reproducible - i placed several debug dsyslog's and
> found out, that the break after
> 
>            if (PictureType == I_FRAME) { // every file shall start with an
> I_FRAME
>               if (!Mark) // edited version shall end before next I-frame
>               {
>                       dsyslog(LOG_INFO,"end for I_FRAME"); //<-- here it's bailing out...
>                  break;
>                 }
> 
> At this point it happens that the variables are as following (a single
> CutIn-Mark at the very beginning, about 3 hours to go):
> FileSize=0 Length=56514 fromFile=15 currentFileNumber=1
> 
> The result is a zero-byte vdr-file.
> Placing some pairs of cut In/Outs shifts the bailing point.
> Placing a cut out mark at the end gives the complete file.
> 
> conclusion:
> As the break-out point is depending on setting the marks it has to be some
> bug in vdr... I think it appeared first with the option "cut edited files",
> changing the option, however, does not solve the problem.
> It can also be since vdr allows files larger than 1024MB (i set it to
> 2000MB)...

>From what you describe I'd say that the problem occurs if there is no explicit
ending mark (just verified this - it actually is like this).
I'll see to change this so that the cutting will automatically assume
an ending mark at the very end of the recording, if the last user provided mark
is a "beginning" mark. Until then it should work if you always place an explicit
ending mark.

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________



Home | Main Index | Thread Index