Mailing List archive

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

[vdr] Re: cutting broken again...



Sergei Haller wrote:
> 
> On Sat, 29 Dec 2001, Guido Fiala wrote:
> 
> GF> This time it is an absolutely clean stream, no driver crashs during recording
> GF> of "Abyss..." on Pro7. Playing or setting the cutting marks is no problem,
> GF> the editing starts just normally but somewhere in the middle it stops without
> GF> appearant reason.
> GF>
> GF> ...
> GF>
> GF> Look carefully at the cutted movies, count the visible sections and guess
> GF> length in minutes and cross check twice until you delete the original -
> GF> something evil is going on :-(
> 
> Last week I had the following situation (which might be different from the
> Guidos): I had a recording A which I was going to cut. Just before cutting
> I removed an old recording B (which was moved to a *.del directory)
> While cutting my hard disk became empty

I assume you mean your HD became *full*?! ;-)

> and the cutting process stopped.
> It turned out that the recording B was still in a *.del directory and was
> not removed from the hard disk as the free space was needed.
> 
> If the disk wents empty while recording and there are some deleted
> recordings on the disk, they are removed. I think it should be handled
> similarly while a cutting process.

You can try adding the line

   AssertFreeDiskSpace(0);

right after the 'while (active) {' line in dvbapi.c's cCuttingBuffer::Action().
The parameter defines the "Priority" with which you want to assert the free disk
space (works the same way as for normal recordings). If no deleted recordings
are there ('*.del'), VDR will delete recordings with lower Priority than the
given parameter. Use '100' if you want to make absolutely sure the cutting process
will get enough space.

I just saw that cCuttingBuffer::Action() doesn't check the result of the call to
safe_write(toFile, buffer, Length). I'll add this and then VDR should notice if
the disk runs full and could end the cutting process with an error message (and
maybe remove the resulting file, since it wouldn't be complete).

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