bizarre recording issue with 1.5.36

[DHL]

This problem only seems to occur on Saturdays with two programs. I have 6 tuners in the computer where this problem occurs. There is a program on ABC that is recorded from 08:29 until 9:02 (but didn't start recording until 08:30), and a program on WMAQ from 08:57 until 10:02, and one or two other programs that are recording (on other channels) simultaneously. (See uploaded log file) At 9:00, the NBC recording starts recording onto the end of the WLS recording, that should still be recording until 09:02. At 9:02 the ABC recording stops and a new WMAQ recording starts. This is quite the oddity, yes? It seems like the pre and post padding were ignored for the WLS program. Running Win 7 with three HVR-2250s tuning QAM channels.

Thank you!

[mvallevand]

My expectation/hope is that this is fixed in 2.0 with

Code:

- fixed a problem where some recordings would continue to grow during the post-padding period, even though the tuner had switched to another frequency (which just happened to have a channel with same PIDs).

Martin

[johnsonx42]

it sounds like you're running into a bug that has been fixed in 2.0.3.

- fixed a problem where some recordings would continue to grow during the post-padding period, even though the tuner had switched to another frequency (which just happened to have a channel with same PIDs).

either way, I don't think anyone wants to spend time troubleshooting bugs in 1.5.36 now.

[BrettB]

My expectation/hope is that this is fixed in 2.0 with

In my (limited) testing so far with 2.0.3, the problem where a recording "changed channels" during the post-padding period seems to be fixed. (Note that the recording status still shows both the "finishing recording" and the "starting recording" on the same tuner during the post-padding overlap, but the "finishing recording" file does not get written to.)

However, the problem with tuner scheduling not honoring pre- and post-padding requests eventhough they could be honored doesn't seem to be fixed. In my case, when the new recordings should have started (i.e. the pre-padding time), there was already a tuner recording on the correct frequency. So, if the new recording would just use that tuner, both the post-padding for the recordings it was finishing and the pre-padding for the recordings it was beginning could have been honored. In addition, I had 2 more tuners available that were completely unused!

[Reddwarf]

So, if the new recording would just use that tuner, both the post-padding for the recordings it was finishing and the pre-padding for the recordings it was beginning could have been honored. In addition, I had 2 more tuners available that were completely unused!

I'm afraid that's a consequence of the way npvr schedules recordings, at epg-update time every recording is attached to a spesific tuner instead of doing this at recording time, which would probably solved your problem.

[sub]

I'm afraid that's a consequence of the way npvr schedules recordings, at epg-update time every recording is attached to a spesific tuner instead of doing this at recording time, which would probably solved your problem.

lol - you're like dog with a bone. It's not to do with this. Allocation of tuners at scheduling is only ever provisional, so that we know there is a plan for recording every recording it says it'll record. There is logic in the recording service to move those recordings at record time, if a tuner is already in use for live tv or post padding, if another after tuner can satisfy the request. There is a known issue in this logic though, that can cause post-padding to be dropped, and it's on my list of things to look at.

[Reddwarf]

lol - you're like dog with a bone. It's not to do with this. Allocation of tuners at scheduling is only ever provisional, so that we know there is a plan for recording every recording it says it'll record. There is logic in the recording service to move those recordings at record time, if a tuner is already in use for live tv or post padding, if another after tuner can satisfy the request. There is a known issue in this logic though, that can cause post-padding to be dropped, and it's on my list of things to look at.

Hm, not so long ago I was thrown out of live-tv because a recording started despite there was two other tuners with that channel available. :confused:

[DHL]

I upgraded to 2.0.3 after reporting this issue. I'll have to wait until Saturday to be sure that the problem has been solved, but it sounds encouraging. However, pre-padding is now apparently ignored on several recordings. I am going to enter specific times and eliminate the pre and post padding on one computer, to see if the recordings then record properly. (I did notice that some recordings were stopped prematurely--ignoring the post padding as described above by BrettB.)