[vdr] Re: running out of space during cutting

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Manfred Schmidt-Voigt wrote:
> 
> ...
> But I found another thing what could lead to a problem. VDR always
> decides to delete the oldest recording if you have all other parameters
> at the same value (lifetime...). But if you try to cut your oldest
> recording the new directory will get the same name only with a "%"
> in front of the toplevel directory for this new structure. This means
> that VDR will find this one as the next one which has to be deleted.
> And it does. You can imagine the problem?
> 
> Here is a part of my message file:

Please don't wrap log messages...

> Aug 17 13:58:56 stereo vdr[8896]: playing '/video/%1/2003-01-15.23.
> 25.50.14.rec/003.vdr'
> Aug 17 13:59:00 stereo /USR/SBIN/CRON[8956]: (root) CMD ( rm -f /var/spool/cron/lastrun/cron.
> hourly)
> Aug 17 13:59:41 stereo vdr[8896]: low disk space while recording,
> trying to remove a deleted recording...
> Aug 17 13:59:41 stereo vdr[8896]: ...no deleted recording found,
> trying to delete an old recording...
> Aug 17 13:59:44 stereo vdr[8896]: deleting recording /video/%%1/2003-
> 01-15.23.25.50.14.rec
> Aug 17 13:59:44 stereo vdr[8896]: low disk space while recording,
> trying to remove a deleted recording...
> Aug 17 13:59:44 stereo vdr[8896]: removing recording /video/%%1/2003-
> 01-15.23.25.50.14.del
> Aug 17 13:59:44 stereo vdr[8896]: removing /video/%%1/2003-01-15.
> 23.25.50.14.del/summary.vdr
> Aug 17 13:59:44 stereo vdr[8896]: removing /video/%%1/2003-01-15.
> 23.25.50.14.del/001.vdr
> Aug 17 13:59:44 stereo vdr[8896]: removing /video/%%1/2003-01-15.
> 23.25.50.14.del/index.vdr
> Aug 17 13:59:44 stereo vdr[8896]: removing /video/%%1/2003-01-15.
> 23.25.50.14.del/marks.vdr
> Aug 17 13:59:44 stereo vdr[8896]: removing /video/%%1/2003-01-15.
> 23.25.50.14.del/002.vdr
> Aug 17 13:59:44 stereo vdr[8896]: removing /video/%%1/2003-01-15.
> 23.25.50.14.del/003.vdr
> Aug 17 13:59:44 stereo vdr[8896]: removing /video/%%1/2003-01-15.
> 23.25.50.14.del
> Aug 17 13:59:54 stereo vdr[8896]: ERROR: /video/%%1/2003-01-15.23.
> 25.50.14.rec//marks.vdr.$$$: No such file or directory
> Aug 17 13:59:54 stereo vdr[8896]: recording to '/video/%%1/2003-01-
> 15.23.25.50.14.rec/004.vdr'
> Aug 17 13:59:54 stereo vdr[8896]: ERROR: /video/%%1/2003-01-15.23.
> 25.50.14.rec/004.vdr: No such file or directory
> Aug 17 13:59:54 stereo vdr[8896]: end video cutting thread
> Aug 17 13:59:55 stereo vdr[8869]: ERROR: 'toFile 2' during editing
> process
> Aug 17 13:59:55 stereo vdr[8869]: ERROR: Schnitt gescheitert!

Ok but that's a different story. Of course the name of the edited
version could be set to the current date, but then it might no
longer be clear which edited version belongs to which original
recording.

What could be done, too, is that AssertFreeDiskSpace() never tries
to delete recordings marked with '%', since these are obviously
edited versions and should therefore never be deleted automatically.
Would that be an idea?

Klaus


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