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
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
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
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
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 948568 943016 5553 100% /mnt/data
which is not a good use% to run any file system on long term. :(
Cheers,
Udo
-
Gero -
Klaus Schmidinger -
Udo Richter