[vdr] [ANNOUNCE] VDR developer version 1.7.31

Udo Richter udo_richter at gmx.de
Wed Oct 3 13:03:24 CEST 2012


Am 30.09.2012 15:41, schrieb Klaus Schmidinger:
> - The new class cIoThrottle is used to allow I/O intense threads to temporarily
>    suspend their activities in case buffers run full (suggested by Torsten Lang).
>    Currently the cutter thread is suspended if the TS or Recorder buffer use more
>    than 50% of their capacity. Plugin authors may want to participate in this
>    mechanism if they use intense background I/O.

I'd suggest to use this for the low disk space deleted recording cleanup 
too. Recently, I've seen an issue like this happen, using VDR-1.7.30, 
where my disk was nearly full, and some deleted recordings didn't get 
wiped before a new recording. After a while, two HD recordings running 
at that time, AssertFreeDiskSpace kicked in and cleaned a deleted 
recording to free up disk space, resulting in an buffer overflow for the 
recorder:

02:08:31 low disk space while recording, trying to remove a deleted 
recording...
02:08:31 removing recording /video/.......del
02:08:31 removing /video/.......del/00001.ts
[...]
02:08:37 removing /video/.......del/00100.ts
02:08:37 removing /video/.......del/resume
02:08:37 removing /video/.......del/marks
02:08:37 removing /video/.......del
02:08:38 max. latency time 7 seconds
02:08:43 buffer usage: 70% (tid=27204)
02:08:43 buffer usage: 80% (tid=27204)
02:08:44 buffer usage: 90% (tid=27204)
02:08:44 buffer usage: 100% (tid=27204)
02:08:44 ERROR: 1 ring buffer overflow (1 bytes dropped)
02:08:44 buffer usage: 70% (tid=27187)
02:08:44 buffer usage: 60% (tid=27187)
02:08:45 ERROR: skipped 187 bytes to sync on start of TS packet
02:08:45 ERROR: skipped 187 bytes to sync on start of TS packet
02:08:45 cNaluDumper: TS continuity offset 6
02:08:45 buffer usage: 0% (tid=27204)

The deleting was surprisingly slow, probably because of the high disk 
fill and fragmentation. And for some reason, the overflow happened after 
the deleting. Not sure what caused the delay.

Cheers,

Udo




More information about the vdr mailing list