Recordings cut-off due to improper use of multiple tuners

[johnsonx42]

(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.

[sub]

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 was able to reproduce it yesterday with this exact steps, but the problem definitely went away with the change I made yesterday. This was with an empty database though, and in the patch I posted above, I did find that maybe future pending recordings on that same tuner might interfere with the logic, so I put in a small change for that too.

[johnsonx42]

That one worked. The third recording successfully moved to the third tuner.

[sub]

Great.

[Reddwarf]

Is the patch in post#40 the official fix for this issue or will there be another one without extra logging?

[johnsonx42]

I'd suggest the extra logging be left in for the moment, just in case some other scenario comes up when more people test it. Another 2.5.x release is coming soon, that's probably when sub will remove any logging he no logner wants.

[sub]

It's unlikely I'll remove the logging. It was only a few lines when a recording is about to start, so doesn't hurt to be there, and will most likely be useful.

[totallhavoc]

I just watched the system do something weird which may or may not be related. I loaded the patch from post #40, thanks sub! I was just monitoring my system and this is what happened:

8:00 PM
Tuner 1 - NCIS on CBS
Tuner 2 - Hart of Dixie on The CW

9:00 PM
Tuner 1 - NCIS LA on CBS and the post padding for NCIS
Tuner 2 - The Taste on ABC, cuts off post padding from Hart of Dixie
Tuner 3 - New Girl on Fox
Tuner 4 - Cult on The CW

Shouldn't Cult have been put on Tuner 2 with Hart of Dixie so the pre/post padding worked? And, put The Taste on Tuner 4?

I'll up logs if needed, but I don't know if this falls under that scheduling rewrite that I have seen mentioned.

[sub]

When back to back recordings are involved, you're not always going to get padding. It'll try it's best to give padding, but the logic is complicated, and sometimes it doesn't work out that way.

[johnsonx42]

actually I'm curious to see your logs. I find logic scenarios like this interesting to examine.