Re: [vdr] [ANNOUNCE] VDR developer version 1.7.31
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/1.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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.31
On 03.10.2012 13:03, Udo Richter wrote:
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.
I guess this should do the trick:
--- recording.c 2012/09/30 13:05:14 2.64
+++ recording.c 2012/10/03 12:52:13
@@ -97,6 +97,8 @@
bool deleted = false;
cThreadLock DeletedRecordingsLock(DeletedRecordings);
for (cRecording *r = DeletedRecordings.First(); r; ) {
+ if (cIoThrottle::Engaged())
+return;
if (r-Deleted() time(NULL) - r-Deleted() DELETEDLIFETIME) {
cRecording *next = DeletedRecordings.Next(r);
r-Remove();
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.
Which file system are you using for your video directory?
I recently switched from ext3 to ext4 and it does feel a little snappier.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.31
Am 03.10.2012 14:55, schrieb Klaus Schmidinger: Which file system are you using for your video directory? I recently switched from ext3 to ext4 and it does feel a little snappier. Its an XFS disk, and it was surprisingly fast on deleting when it was fresh. Unfortunately, #df -m /video Filesystem 1M-blocks Used Available Use% Mounted on /dev/mapper/lvm--disk-data 948568943016 5553 100% /mnt/data which is not a good use% to run any file system on long term. :( Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR developer version 1.7.31
VDR developer version 1.7.31 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.31.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.30-1.7.31.diff
MD5 checksums:
a3edd18a352465dd26c97c1990f7bcfd vdr-1.7.31.tar.bz2
32ff98697d1b383478a6e1932e4afc9c vdr-1.7.30-1.7.31.diff
WARNING:
This is a *developer* version. Even though *I* use it in my productive
environment. I strongly recommend that you only use it under controlled
conditions and for testing and debugging.
The default skin LCARS displays the signal strengths and qualities of
all devices in its main menu. For devices that have an stb0899 frontend chip
(like the TT-budget S2-3200) retrieving this information from the driver is
rather slow, which results in a sluggish response to user input in the main
menu. To speed this up you may want to apply the patches from
ftp://ftp.tvdr.de/vdr/Developer/Driver-Patches
to the LinuxDVB driver source.
The changes since version 1.7.30:
- If regenerating an index file fails and no data is written to the file, VDR
now
reports this error and removes the empty index file.
- The setup parameter Recording/Instant rec. time (min) can now be set to '0',
which means to record only the currently running event (based on a patch from
Matti
Lehtimäki).
- Decreased the ring buffer put/get trigger sizes from 1/3 to 1/10.
- The script given to VDR with the '-r' option is now also called whenever a
recording is deleted (thanks to Alexander Wenzel).
- Improved detecting frames in MPEG 4 video (reported by Andrey Pridvorov).
- cPatPmtParser::ParsePmt() now also recognizes stream type 0x81 as AC3, so
that
recordings that have been converted from the old PES format to TS can be
played
(suggested by Jens Vogel).
- Fixed a leftover frame counter in the LCARS skin's replay display after
jumping to
an editing mark and resuming replay.
- 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.
- Increased the size of the TS buffer to 5MB and that of the Recorder buffer to
20MB to better handle HD recordings (suggested by Torsten Lang).
- Moved cleaning up the EPG data and writing the epg.data file into a separate
thread to avoid sluggish response to user input on slow systems (based on a
patch from
Sören Moch).
- Fixed sorting folders before recordings in case of UTF-8 (thanks to Sören
Moch).
- Reactivated stripping control characters from EPG texts and adapted it to
UTF-8.
- Added missing decrementing of 'len' in libsi/si.c's String::decodeText()
functions.
- When checking whether a video directory is empty, file names that start with a
dot ('.') are no longer automatically ignored and implicitly removed if the
directory
contains no other files. Instead, RemoveEmptyDirectories() now has an
additional
parameter that can be given a list of files that shall be ignored when
considering
whether a directory is empty. This allows users to continue to use files such
as
.keep to prevent a directory from being deleted when it is empty. Currently
the
only file name that is ignored is .sort.
Have fun!
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.31
On Sunday 30 September 2012 - 15:41:14, Klaus Schmidinger wrote:
- When checking whether a video directory is empty, file names that start
with a dot ('.') are no longer automatically ignored
...
is empty. This allows users to continue to use files such as .keep to
prevent a directory from being deleted when it is empty.
That's great! Thanks a lot!
br
Gero
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
