Great program but I wondering if my understanding is correct.
In processing a file, if the file is followed by another file the post pad is not added until the next file is complete. This means if you have a long program following you would need to wait some time before the file is ready.
Assuming you could arrange for the program to wait for 3 or so minutes into the next program before processing, would it possible to add the post pad while the next program is still being recorded. In this way, you only need to wait 3 or so minutes into the next program before completion of file.
Is there is a record locking issue?
And now for the dumb question: If it is record locking issue, why is that I can play a program while I am still recording it.
zaprat Wrote:Great program but I wondering if my understanding is correct.
In processing a file, if the file is followed by another file the post pad is not added until the next file is complete. This means if you have a long program following you would need to wait some time before the file is ready.
Assuming you could arrange for the program to wait for 3 or so minutes into the next program before processing, would it possible to add the post pad while the next program is still being recorded. In this way, you only need to wait 3 or so minutes into the next program before completion of file.
Is there is a record locking issue?
And now for the dumb question: If it is record locking issue, why is that I can play a program while I am still recording it.
Short answer, yes it's record locking.
I know that the cutting rogram needs full access to the file before it wil work. I supose the author or someone else could write a cutter that does not require full access, but I'm not smart enough to do that myself.
GB-PVR is really quite nice about reading open or currently writing rograms. I believe that's on of the good things about MPG format (If I remember, if the PVR was recording to other formats like divx, one would NOT be able to watch while recording...)
I have certainly taken a break from major coding as of late. but my idea for a new version of ZBack2Back would certainly help you view the bits you're missing even before you have finished recording the second show.
Sorry if that's a tease. I don't have anything ready for beta test, though I have proof of concept...
zehd Wrote:I have certainly taken a break from major coding as of late. but my idea for a new version of ZBack2Back would certainly help you view the bits you're missing even before you have finished recording the second show.
Sorry if that's a tease. I don't have anything ready for beta test, though I have proof of concept...
I know you have your hands full with Ultra2 but I just learned about ZBack2Back and would be interested in any new version you come up with.
More and more networks are not hitting their marks as far as starting and stopping on time, either by accident or on purpose to get viewers to not switch channels. ZBack2Back is our way of combatting/coping with this.
One Request/Suggestion: If I understand it correctly, ZBack2Back uses its own padding sizes, regardless of what was used when recording the program and universally apply them to
all programs. I think an improvement would be to use the larger of the pre and post paddings used when recording programs and the pre and post padding sizes defined within ZBack2Back. That would let us choose a very long padding for a sports event when setting it to be recorded. Yes, I know I could just move the stop time to later but the manipulation that ZBack2Back does gets this extra time without tying up a tuner like which would be done if the program end time were pushed back.
LewE Wrote:I know you have your hands full with Ultra2 but I just learned about ZBack2Back and would be interested in any new version you come up with.
More and more networks are not hitting their marks as far as starting and stopping on time, either by accident or on purpose to get viewers to not switch channels. ZBack2Back is our way of combatting/coping with this.
One Request/Suggestion: If I understand it correctly, ZBack2Back uses its own padding sizes, regardless of what was used when recording the program and universally apply them to all programs. I think an improvement would be to use the larger of the pre and post paddings used when recording programs and the pre and post padding sizes defined within ZBack2Back. That would let us choose a very long padding for a sports event when setting it to be recorded. Yes, I know I could just move the stop time to later but the manipulation that ZBack2Back does gets this extra time without tying up a tuner like which would be done if the program end time were pushed back.
I think when I'm done with Ultra and ZProcess (Yeah I'm working on that now, beating the rush for when sub starts changing things with the new release ooops) I'll redo zback2back too.
ZBack2Back is a really dirty workaround and I've since discovered some very elegant things...
I'll be knocking on your door for help with this too...
zehd Wrote:I think when I'm done with Ultra and ZProcess (Yeah I'm working on that now, beating the rush for when sub starts changing things with the new release ooops) I'll redo zback2back too.
ZBack2Back is a really dirty workaround and I've since discovered some very elegant things...
I'll be knocking on your door for help with this too...
Not to scare you...but I'll be keeping an eye open for something new on this front as well.
TomR Wrote:Not to scare you...but I'll be keeping an eye open for something new on this front as well.
Great Tom.
Now he won't do anything with ZBack2Back.