Pre and Post Paddings Should Be Respected

[LewE]

I didn't add this to the very active thread requesting User Interface wishlist items because I believe it has to do more with the internals of GBPVR.

I have three analog capture cards, each set to be able to deal with all of the available channels. I have two programs that occur back-to back, each set to be a recurring schedule, and each with a 2 minute post padding. What ends up happening is that they both get scheduled to be recorded by the same capture source and the 2 minute post padding of the first program is lost. There are no other programs scheduled to be recorded at this time so all three capture cards are available but only one is used.

This means that I lose part of the first program each day because of the time for GBPVR to stop one recording and start the next. With most shows this isn't an issue but the two programs I am talking about are The Daily Show and The Colbert Report. The Daily Show puts some of its content at the very end of each show and I end up missing some or all of it.

I know that one of zehd's utilities could take care of some of this problem but there is still some finite time when nothing is recorded because of GBPVR switching between recordings so this isn't a solution.

Why doesn't GBPVR make use of another capture card and maintain the post recording padding for each show when this is possible?

[Graham]

Config.xml has ...

Code:

<PreferAlternatingCaptureSources>false</PreferAlternatingCaptureSources>
  <TryToHonourPaddingIfPossible>true</TryToHonourPaddingIfPossible>

[LewE]

Config.xml has ...

Code:

<PreferAlternatingCaptureSources>false</PreferAlternatingCaptureSources>
  <TryToHonourPaddingIfPossible>true</TryToHonourPaddingIfPossible>

Thanks for pointing this out.

Those two parameters were set like in your message and I changed the first one to be TRUE.

I don't understand how the program interprets the two parameters if they are set as in your message. Shouldn't the TryToHonour parameter force use of alternate capture sources for this instance?

[Jaggy]

I had this exact same problem after sub introduced multi-record & I have mentioned it in a couple of messages with no response, I don't know if it is still there with 1.4.7 as I have only just upgraded & not tested it. BTW I have my config set the same as in Graham's message.

The only way I could find to stop it doing this undesirable behavior was to un-tick Multi-Record in config, after that all has worked the way it should & the WAF has increased again.

[sub]

Its hard to describe the million rules that have an effect on whether you get padding, but as pointed out above, having multi-record enabled can cause the 'TryToHonourPadding' to be ignored.

[LewE]

Its hard to describe the million rules that have an effect on whether you get padding, but as pointed out above, having multi-record enabled can cause the 'TryToHonourPadding' to be ignored.

Like Graham suggested, I went and unchecked that option in CONFIG. I couldn't find an explanation of what that opiton means in the documentation wiki though.

Can you give a brief explanation of what it is.

I also set PreferAlternateCaptureSources in config.xml to true.

[sub]

PreferAlternateCaptureSource set to true will prefer to allocate recordings to different capture sources when its part of a back-to-back recording. This is at scheduling time.

'TryToHonourPadding' is something effects the logic at recording time, specifically if it needs to stop a recording when it reaches the post-padding to start some other recording, it'll try to find another available capture source to perform the later recording.

Neither of these options operate when the multi-record is in use though - which is a feature that allows multiple digital channels to be recorded simultaneousely on a single tuner.

[LewE]

PreferAlternateCaptureSource set to true will prefer to allocate recordings to different capture sources when its part of a back-to-back recording. This is at scheduling time.

'TryToHonourPadding' is something effects the logic at recording time, specifically if it needs to stop a recording when it reaches the post-padding to start some other recording, it'll try to find another available capture source to perform the later recording.

Neither of these options operate when the multi-record is in use though - which is a feature that allows multiple digital channels to be recorded simultaneousely on a single tuner.

Thanks for the clarification. Since I use only analog channels I definitely don't need multi-record and it appears that this is what was making me lose the padding.

I think it would be useful if you added that warning about multi-record (referring to the Misc2 tab) to the Capture Sources portion of the Configuration Tool write-up in the documentation wiki.

[ElihuRozen]

If I record something on the same channel from 9:00-9:30 & 9:30-10:00 on my digital tuner, it records both shows from 9:28-9:32. When I watch the first show, it goes from 8:58 to 9:32. The second show has from 9:28 to 10:02. I just have the single digital tuner (for now), but multiple analog tuners.

[smiffypr]

Now on N-PVR (version 1.5.31), this problem still exists, but the configuration parameters don't seem to, so I can't experiment with them.
But if I could, I still wouldn't want to disable multi-record in order to try to honour padding.
What I think would work would be to have an option to force the honouring of padding. With this option set, the recording would be treated as beginning at the beginning of pre-padding and ending at the end of post-padding, and any conflicts would then show up at the time the recording is set. The user would then have the choice of cancelling a recording, or reducing the padding on that program in order to remove the conflict.
As a workaround, (which I think will work), where I have one recording starting at the same time as another ends, I can set the program following the first one to record and that will force the first tuner to stay on that channel.