2013-02-22, 09:24 PM
(note that I typed this before the patch above was posted... will test with the new patch)
I just ran one more scenario, and it failed in the same way as before.
This time I started the first two recordings as Quick Records so they had no post-padding. Both were set to end at the same time. Then I set the third recording to begin immediately after the first two, with 1-minute padding. As expected, the 3rd recording was moved to the second tuner, and cut-off the second recording a minute early. I just wanted to see if post-padding on the first two recordings was somehow causing the error to occur.
So it seems pretty certain that this bug will occur when there are recordings on the first and second tuner that both end at the same time, which are followed immediately by a third recording that requires a different physical channel than either of the first two, AND the third recording has a pre-padding request that necessitates it moving from the provisionally scheduled tuner to a 3rd tuner. I suspect it would also happen with just two tuners, where NRecord should determine that honoring the pre-padding is not possible since both tuners are busy, but instead it will still cut the recording on the 2nd tuner short.
I just ran one more scenario, and it failed in the same way as before.
This time I started the first two recordings as Quick Records so they had no post-padding. Both were set to end at the same time. Then I set the third recording to begin immediately after the first two, with 1-minute padding. As expected, the 3rd recording was moved to the second tuner, and cut-off the second recording a minute early. I just wanted to see if post-padding on the first two recordings was somehow causing the error to occur.
So it seems pretty certain that this bug will occur when there are recordings on the first and second tuner that both end at the same time, which are followed immediately by a third recording that requires a different physical channel than either of the first two, AND the third recording has a pre-padding request that necessitates it moving from the provisionally scheduled tuner to a 3rd tuner. I suspect it would also happen with just two tuners, where NRecord should determine that honoring the pre-padding is not possible since both tuners are busy, but instead it will still cut the recording on the 2nd tuner short.
server: NextPVR 5.0.7/Win10 2004/64-bit/AMD A6-7400k/hvr-2250 & hvr-1250/Winegard Flatwave antenna/Schedules Direct
main client: NextPVR 5.0.7 Desktop Client; LG 50UH5500 WebOS 3.0 TV
main client: NextPVR 5.0.7 Desktop Client; LG 50UH5500 WebOS 3.0 TV