udo_richter@xxxxxx(Udo Richter) 06.05.05 02:40
>Rainer Zocholl wrote:
>> See that this is a race condition?
>> All these attemps occurs in the same second!
>Actually not a race condition, more like a denial of service.
OK. a "It does not work any more"-state ;-)
>Had something similar once, because of missing write access to a
>folder. VDR fails and tries again and again. There is no 'giving up'
>state for VDR.
>> Is that fixed in newer releases?
>Just compared sources, there are no relevant changes in that area
>between .18 and .23. So I would guess that updating wont solve your
>problem.
Thanks.
>In that case where your disk did run full:
>Did you have remaining *.del recordings waiting for cleanup?
Yes. I deleted them manually finally form console
I was very upset as i marked recordings over recordings for deletion,
and VDR did not delete them.
So i rebooted VDR
"usually" a rebooted VDR "usually" first removes all "*.del"
but it did not AFAIR
Maybe that "cleanup" did not happen because a recording immediately starts?
Next time i will write down what was done.
Now it's 10 days ago and i did not pay much attention to it.
>Are you sure there were *.rec recordings that were free for deleting?
>These clean up old recordings rules are *very* tricky.
Seems so..no KISS ;-)
>I'm working on a patch that marks 'ready to delete' recordings,
>because I usually let VDR decide what to delete and when. (just dont
>have the time to get it completed.) As long as you dont see what may
>get deleted, this strategy is a mine field.
"find -mane '*.del'" helps and is very fast.
But a key: "please lauch the deletion thread now" would be nice.
Too a record size indicator would be nice, as i
have still some recordings with VPS and it happens, that VDR
restarts the recording at the begin of the next programm
and sometime it records until i turn off the box...
Rainer---<=====> Vertraulich
//
//
<=====>--------------ocholl, Kiel, Germany ------------
