udo_richter@gmx.de(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 ------------