Re: [vdr] Hard link cutter
Andreas Brachold wrote:
i like your patch, but its work only on some recordings.
Its failed with a segmentation fault, on cutting.
The only differ are unbalanced marks (out missed)
Confirmed, the patch doesn't handle the case that the last mark is a
cut-in mark, not a cut-out. In that case 'Mark' will be NULL, causing a
segfault. The attached (untested) patch should do the trick.
Cheers,
Udo
Index: cutter.c
===
--- cutter.c(revision 895)
+++ cutter.c(working copy)
@@ -167,8 +167,9 @@
uchar MarkFileNumber;
int MarkFileOffset;
// Get file number of next cut mark
- if (fromIndex-Get(Mark-position, MarkFileNumber,
MarkFileOffset)
- (MarkFileNumber != CurrentFileNumber)) {
+ if (!Mark
+ || fromIndex-Get(Mark-position, MarkFileNumber,
MarkFileOffset)
+ (MarkFileNumber != CurrentFileNumber)) {
// The current source file will be copied completely.
// Start new output file unless we did that already
if (FileSize != 0) {
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Hard link cutter
Hello, Udo Richter wrote: I've been thinking about video cutting strategies, and I think its possible to speed up the cutting process noticeable, with some modifications to VDR. i like your patch, but its work only on some recordings. Its failed with a segmentation fault, on cutting. The only differ are unbalanced marks (out missed) 0:00:48.13 (in) 0:02:12.12 (out) 0:03:51.20 (in) 0:17:16.11 (out) 0:26:19.06 (in) 0:43:32.10 (out) 0:51:50.10 (in) Core was generated by `/opt/vdr-1.4/bin/vdr -l 1 6 -v /video/vdr -L /opt/vdr-1.4/lib -s /opt/vdr-1.4/b'. Program terminated with signal 11, Segmentation fault. #0 0x080a37d7 in cCuttingThread::Action (this=0x8bbde18) at cutter.c:170 170 if (fromIndex-Get(Mark-position, MarkFileNumber, MarkFileOffset) (gdb) print Mark $1 = (class cMark *) 0x0 Current language: auto; currently c++ (gdb) bt #0 0x080a37d7 in cCuttingThread::Action (this=0x8bbde18) at cutter.c:170 #1 0x0812ca45 in cThread::StartThread (Thread=0x8bbde18) at thread.c:244 #2 0xb7eff0bd in start_thread () from /lib/tls/libpthread.so.0 #3 0xb7d759ee in clone () from /lib/tls/libc.so.6 HTH, Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Hard link cutter [was: Suggestion: High speed cutting]
Richard Lithvall wrote: Why not just change the naming of video files to four, five or even eight digits? The real limit is that the file format and the VDR API uses byte sized integers to represent this. (cIndexFile::Get uses an uchar *FileNumber.) This could be extended, even with moderate changes on the file format. (there are reserved bytes that could be used) However, in any case it will break compatibility for the recording format and for the VDR API. And with some tricks, 255 files are enough too, so why break things? Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Hard link cutter [was: Suggestion: High speed cutting]
Udo Richter wrote: This has been in my mind for over two years, and now I just wanted to see it working: Using hard file system links to speed up editing whenever a 00x.vdr file is copied from source to destination recording without modification. This has crossed my mind several times as well, thanks for implementing it! Future plans To solve the file size vs. recording size conflict, dynamic file sizes could be implemented, so that a recording starts with small file sizes, and increases the file size at some point to ensure enough space for huge recordings before 255.vdr is reached. For example, using 32Mb up to 192.vdr and 2000mb from 193.vdr on will give a total of 128 Gb or 84 hours, while using small files for up to 4 hours. Why not just change the naming of video files to four, five or even eight digits? /Richard ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Hard link cutter [was: Suggestion: High speed cutting]
Hi, Richard Lithvall wrote: Why not just change the naming of video files to four, five or even eight digits? The problem is not the file name, it's the index file. An index entry stores the file number as uchar, which allows 256 recording files. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
