recording cut short when 3 tuners active

[Brad242]

Hey.. I just had a thought- is anyone running Windows 7 (or Vista) with three or more tuners and can do my test? I'd happily go buy a copy if it would fix this issue.

[johnsonx42]

I run 4 tuners on Win7 and while I've not explicilty run your specific test scenario, I have not had any problems like this and often have 3 or 4 tuners running with back-to-back recordings.

[superman2012]

I have 7 tuners (including dual tuners) on my Win7 x64 pc, so far so good.

[Graham]

From what I have read, Win 8 will be on sale any day now and it will be as cheap as chips so buying Win 7 might not be a good choice.

[Brad242]

Thank you everyone for the feedback on Windows 7!

Some musings..
I can't say something is messed up with NextPVR since it apparently works ok on Windows 7. Any fix sub would have to do seems like it would be some bandage for some bug/shortcoming on XP.
So on XP:
Something is still messed up with the unofficial dvbfix files.
Something is broken with the BDA API behavior when more than 2 tuners are used.
A race condition of some sort is happening (most of my bizarro programming issues on Windows have been caused by race conditions... toss some timers in, problem goes away)
In the halls of Microsoft it may have been said "two tuners ought to be enough for anybody running XP" (heheheh.. sorry.. but HEHEHEHEH! yeah I know Bill probably never said the 640k thing...)

Anyway.. I've ordered a copy of Home Premium to experiment with (and will be running Classic Shell... yeah Chicago interface FOREVER BABY!).

[Jaggy]

I know two people that when using XP & were able to record on more than two DVB devices with NextPVR without having a problem... unfortunately both have moved to Win7 now so I couldn't get them to do an exact match test to test the exact same situation you were reporting was a problem for you.

[johnsonx42]

(and will be running Classic Shell... yeah Chicago interface FOREVER BABY!).

just don't turn off Aero. bad things happen to media playback in win7 if you turn it off.

[stoenjes]

"Given the following scenario:
3 tuners installed,
2 programs ending the same time,
1 program starting the same time that the other 2 are ending,
pre and postpads being used,
The programs are scheduled as one time recordings.

the result:
One of the earlier programs will be cut short by several minutes, and the cut short recording will end about 5 seconds before the minute mark. The NTFS last modified times on all files will be correct (having included the postpad), implying that the files were all closed at the correct time, and that one tuner stopped sending data several minutes too soon."

I use one minute pre and post pad. One of the 'first' recordings went blank 40 seconds before the time ran out.

Stan

[Brad242]

stoenjes,
Thank you for doing the test. I tried it with 1 minute pre and post pads and got ~2 minutes short. I'm
not sure why your short time differs from mine.

After that I did about a dozen more tests on my box "hdtv" and figured out a workaround (using XP.. I'm going to hold off on redoing the box with Windows 7 unless the workaround gets too painful).

I was looking over the npvr.db3 database and noticed the capture_source_oid field in the SCHEDULED_RECORDING table.
I'm using 3 ATSC tuners and currently on this box they are capture_source_oid 20, 22, & 24.

With my 3 tuner test this is what I get (pgm #1 means the first one I scheduled, pgm #2 the second, etc.):
pgm #1 capture_source_oid 20
pgm #2 capture_source_oid 22
pgm #3 capture_source_oid 20 (a conflict, and an on-the-fly reallocation will have to be done by NPVR right before the recording starts)

In my tests, Pgm #1 and #3 all recorded at the correct length, and pgm #2 cut short every time (by ~2 minutes- I used a 1 min pre&postpad).

All record correctly if I change it so there are no conflicts:
pgm #1 capture_source_oid 20
pgm #2 capture_source_oid 22
pgm #3 capture_source_oid 24

My last tests were with nine 30 minute programs- 3 back-to-back shows on 3 different RF channels.
The 1st 2 channels, all the programs started and stopped the same time. The last channel I
chose programs starting 30 minutes later than the 1st 2 channels. Pre and postpad of 1 min. The tuner allocations appeared
random with some conflicts.
In the 1st test with 9 programs, I let it run as is. 2 programs came up short, both by 2 minutes.
In the 2nd test with 9 programs, I edited the capture_source_oid fields so that no conflicts existed.
All recorded correctly.

So my workaround if I need to use all 3 tuners at once:
Schedule as I normally would with NEWA.
Stop the NPVR Recording Service.
Load the npvr.db3 with SQLiteSpy.
Edit any capture_source_oid conflicts in the SCHEDULED_RECORDING table.
Close SQLiteSpy.
Restart the NPVR Recording Service.

I used the technique on my other 3 tuner box "bsod" for real last Friday when I needed all 3 tuners, and had no short recordings!

Is it necessary to stop the NPVR Recording Service, edit the db, then restart the service?
Several posts here mention doing that, but I've tried it a few times without stopping the service, without
any issue. I wasn't recording or scheduling at the same time I was editing, if that matters.

Why does the issue appear on XP but not Win 7? Assuming it is something to do with the on-the-fly reallocation,
I'd guess some BDA API calls are being done on the tuners, and Windows 7 is behaving differently than XP. I dunno...