Hello,
maybe a stupid question ...
How to program a recording in VDR which have to run for more than 24 hours ?
regards Petric
Klaus Schmidinger wrote:
Only when you don't touch the timer. :-)
You could program several overlapping timers.
Or you can prolong the already running timer every few hours.
But you can't extent a recording indefinetly because there is limit of 255 files into which VDR can record. But under normal circumstances there is at least enough capacity for recording several days.
Hello,
On Wednesday 04 January 2006 10:52, Matthias Schniedermeyer wrote:
So the file naming can go from 001.vdr to 255.vdr. What about 256.vdr to 999.vdr ? So - if you keep the default of 2GByte sized files - you are limited to about 255 hours and a sum size of 512 GBytes. In the shops you find 500GByte drives and when it comes to Raid arrays you can get more.
Ok, usually (nearly) no one would go to record such lenghty sessions ...
regards Petric
Petric Frank wrote:
So the file naming can go from 001.vdr to 255.vdr. What about 256.vdr to 999.vdr ?
index.vdr uses a 1-byte number to store the file, thats why the limit is 255. The format could be extended, there's enough reserved space that could be used, but since its really hard to extend beyond 24h anyway, why bother with the current 10-day limit? The only good reason would be high speed cutting with small files.
Cheers,
Udo
Klaus Schmidinger wrote:
I just had a weired idea.
index.vdr is for 1 .. 255
and it should be relativly easy (and backward compatible) to extent that schema with
index002.vdr for 256 .. 510
and so on.
But OTOH who want's a month or year long recording. ;-)
Petric Frank wrote:
Yes. Since somewhere in the VDR 1.1 timeline it is possible to have overlapping timers on the same channel where VDR simultaniously stores the broadcast in <x> directories.
So actually you have to have a method to remove the overlap when you want to create a contious recording out of several recordings.
How to join the recordings ?
For playbackability with VDR in the 'simplest' case you only need to fix the file-number in the index.vdr-file and append that onto the first recording and move the XXX.VDR-files with the fixed name into the first recording dir.
But that way the overlapp would still be there.
So you needed a program that finds the exact frame where the first recording stopped. Then finds the exact same frame in the next recording and then copies the portion of 001.vdr from the next-recording and appends and fixes the content of the index.vdr beginning after the frame you determined earlier. Then you copy the remaining XXX.VDR-files where you only have to fix the number of the file and file-number in index.vdr.
And start over with the next recording until you are done or hit the 255-file limit.
For someone with a bit of programming experience this should only be a matter of one or two afternoons. The exact format of index.vdr is documented in one of the documentation files.
A bit simpler:
1. Move all the nnn.vdr files into new directories, renumbering them in the right order and make sure that each possible overlap is actually in one dir. E.g. if you have 1/001-1/005, 2/001-2/255, 3/001-3/023 you could reorder this as x1/001-x1/004 (from 1/001-1/004) x2/001-x2/099 (from 1/005, 2/001-2/098) x3/001-x3/178 (from 2/100-2/255, 3/001-3/023) (You can completely disregard index and other files.)
2. Run genindex in each of the new dirs.
3. Fix the cut-points. This is left as the only programming exercise, but supposedly noad can do this already (-o flag).
4. Run vdrsync --cut or whatever.
I'm doing this routinely (by hand, don't ask me for a script :-) to join multi-part episodes of certain shows. Here the first step is trivial as most recordings consist only of 2 or 3 nnn.vdr files and for the third step I need noad anyway.
Olaf
Olaf Titz wrote:
I like my idea better. :-)
But i already have scripts for parsing index.vdr and finding a specific frame in a recording. (But i need it to find the same cutting-marks in the same recording from a different VDR-instance(*) for find a the 'longest' (byte-wise) recording which is most like without recording errors.)
So all i needed to do if i had this problem would be a bit of glue for the pieces i already have. :-)
*: I have 3 VDR-machines and if possible i record the same broadcast with all 3 machines. This greatly minimized the 'risk' of losing a recording due to errors. (Execept errors on sending side or when the weather is so bad the even the reception doesn't work)
Bis denn
Matthias Schniedermeyer wrote:
A little revision to my idea makes this very much easier and lightning FAST.
Instead of finding the last frame of the previous recording in the next recording it would be better to find the first frame of the NEXT recording in the previous one.
That way you only have to truncate(which is way cheaper than having to copy data) the end of the older recording part and move over the XXX.VDR file and paste the content of index.vdr with only needing to fix the file-number. No need to mess with offsets.
That's it. 2 recordings merged into one.
All in all this way it only takes a few seconds to merge 2 recordings.
Bis denn
-
Klaus Schmidinger -
Matthias Schniedermeyer -
Olaf Titz -
Petric Frank -
Udo Richter