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,

Sunday, August 17, 2003, 2:29:20 PM, you wrote:

> 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...

Sorry, but that was the internet mailer I use (OK, it's a weak
excuse..)

>> 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.

Thats not a good Idea.

> 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?

I don't like that Idea because I often leave a recording with a % on
the system and delete the original name manualy because of the lack of
comfortable renaming possibility with a remote control.

What do you think about checking the oldest directory with the fuser
command. It shows open files and the pids which are accessing the files.
And if you find something then skip it.

Actual example:

stereo:~ # fuser /video/Der_König_von_Dulsberg/*/*
/video/Der_K\37777777766nig_von_Dulsberg/2003-08-17.14.51.50.14.rec/001.vdr:  8869  8871  8872  8873  8886  8890  8891  9123  9124  9125
/video/Der_K\37777777766nig_von_Dulsberg/2003-08-17.14.51.50.14.rec/index.vdr:  8869  8871  8872  8873  8886  8890  8891  9123  9124  9125

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