Mailing List archive

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

[vdr] Re: running out of space during cutting



Hello Klaus,

Saturday, July 26, 2003, 4:54:57 PM, you wrote:

> Manfred Schmidt-Voigt wrote:
>> 
>> At Saturday, 26 July 2003, you wrote:
>> 
>> >Manfred Schmidt-Voigt wrote:
>> >>
>> >> Hi List, Hi Klaus,
>> >>
>> >> is it possible to change the behavior of the cutting process a little
>> >> bit? When the actual cut starts VDR should look first through the
>> >> recordings and do its cleanup circle. Often when I start the cutting
>> >> process it breaks because there was not enough space left on the
>> >> disk. But I have deleted some recordings first. A better way would
>> >> be if the behavior would be the same as during recording: VDR frees
>> >> up space automatically according to the lifetime rules.
>> >
>> >Doesn't it do this already?!
>> >
>> >VDR calls AssertFreeDiskSpace() in cCuttingThread::Action(), which
>> should
>> >take care of this (has been introduced in version 0.99pre2).
>> >
>> 
>> In cutter.c you use AssertFreeDiskSpace() without the priority parameter.
>> Is this not necessary for a correct work of your AssertFreeDiskSpace-
>> function? In recording.c you have defined "void AssertFreeDiskSpace(int
>> Priority)" and in this function you do a lot of conditional stuff
>> on this priority. Is this a bug or a feature?

> The Priority parameter is used to allow a high priority recording
> to make sure it succeeds. A cutting job certainly doesn't qualify
> as "high priority", because it can always be repeated later.

> If you want, you can add some priority to the call of AssertFreeDiskSpace(),
> but I wouldn't recommend it. As it is, it should remove any *.del recordings,
> but leave old recordings alone.

> Klaus

I have played a little bit with the AssertFreeDiskSpace Function and I
think I know now the "weakness" of this function. It is optimized for
a job during recordings. If you use this routine also for cutting than
you should set some of the defines to other values. If you set
MINDISKSPACE to 1024Mb than this is not enough for a "fast recording"
as cutting is. You "record" more than 1GByte in 100 seconds
(DISKCHECKDELTA) which is the second important value to this
algorithm. So if you have a little bit more than 1GB free diskspace in
the beginning but your recording need more than this you will only
check in the beginning and than the "recording" runs out of space. I
have set now MINDISKSPACE to 4096Mb and this should be sufficient to
cut more than a 2hour movie. The other possibility is to lower
DISKCHECKDELTA. But this will increase the process load.

Maybe you can think about something to determine if this function is
called by a real recording or by the cutter and set the values than
dynamically but with the big and cheap disks today its maybe more easy
to spend these aditional 3GByte as free buffer on the video disk.

Kind regards
Manfred



-- 
-------                   Manfred Schmidt-Voigt                  -------
-----                  Günzweg 10, 22393 Hamburg                   -----
-----                                                              -----
-------          mailto:manfred.schmidt-voigt@mannitec.de         -------



-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.



Home | Main Index | Thread Index