Recordings cut-off due to improper use of multiple tuners

[TVHelp]

I was having issues with zero size or completely blank recordings so I installed the latest along with the patches and redid my whole setup to get clean channel scan. Seems to have been a mistake. Now my shows are getting cut-off by NPVR switching tuners inappropriately.

E.G.
Show A 7:00 pm Channel 1
Show B 7:00 pm Channel 2
Show C 8:00 pm Channel 1
Show D 8:00 pm channel 3
Show E 9:00 pm channel 4
Show F 9:00 pm Channel 5

Tuner 21 starts to record show A stops normally with no further recordings until an hour later to record show E on new channel.
Tuner 23 starts to record show B then stops short cutting off recording to switch to show D on channel 3 (1/2 hour show - is this the issue) ends and records next show F in 1/2 hour
Tuner 25 starts to record show C on channel 1 ends normal
Tuner 27 is idle and never used


Shouldn't the logic be to record show C on tuner 21 so that it can stay on the same channel, and include all pre and post padding, use tuner 25 (or 27) for show D and then use tuner 23 or 25 for either show E or F - it use to do this? I could understand if I had 4 shows schedule for each time then something would need to be stopped early, but this really does not make sense.

Bottom line, shouldn't back to back shows on the same channel use the same tuner - this is the most effective use of a tuner, leaving channel switching to another tuner? The whole reason I use NPVR instead of media center is because NPVR allowed post recording overlap on same channel whereas Media Centre always cuts off shows even when on the same channel and does not honor post recording time or use additional tuners.

This was a problem before, then seemed to be fixed, now it is back again. Or is there something in the way I setup the recordings initially - i.e. order that I created the recurring recordings - that affects this? I always restart recording services after setting up new recordings as I thought this is where the logic is applied, is that a good idea or bad idea?

What is the best way to roll-back to another version of the software, without doing a windows restore or redoing all my setup, to see if that helps?

Logs attached.

[johnsonx42]

Yes, I see what you mean. It looks like NRecord is losing track of which tuners are busy on which frequencies. I encountered a similar sort of bug previously, and sub was able to find the logic flaw and fix it fairly quickly; hopefully the same is true this time.

Code:

2013-01-21 19:59:00.076    [DEBUG][7]    Recording due to start pre-padding, but tuner not available
2013-01-21 19:59:00.096    [DEBUG][7]    Scheduled Recording about to start maybe a candidate for moving to another tuner (different locator than another recording on same device)
2013-01-21 19:59:00.096    [DEBUG][7]    Existing:
<physical_channel>117</physical_channel>
2013-01-21 19:59:00.096    [DEBUG][7]    Required:
<physical_channel>116</physical_channel>
2013-01-21 19:59:00.096    [DEBUG][7]    Was allocated to capture source21
2013-01-21 19:59:00.516    [DEBUG][7]    Found another available tuner for new recording. Now allocated to 23
2013-01-21 19:59:00.576    [DEBUG][7]    Recording successfully moved.
2013-01-21 19:59:00.576    [DEBUG][7]    allocating recording target filename: D:\nPVR\2 Broke Girls\2 Broke Girls_20130121_20002030.ts
2013-01-21 19:59:00.576    [DEBUG][7]    About to start recording (1641 on 23): D:\nPVR\2 Broke Girls\2 Broke Girls_20130121_20002030.ts...
2013-01-21 19:59:00.576    [DEBUG][7]    Free space 257874444288  (D:\)
2013-01-21 19:59:00.576    [DEBUG][7]    Asking NDigitalHost to start: D:\nPVR\2 Broke Girls\2 Broke Girls_20130121_20002030.ts
2013-01-21 19:59:01.256    [DEBUG][7]    Temp at 1/21/2013 7:59:11 PM
2013-01-21 19:59:01.256    [DEBUG][7]    Started recording (1641:2:D:\nPVR\2 Broke Girls\2 Broke Girls_20130121_20002030.ts)
2013-01-21 19:59:01.276    [DEBUG][7]    No C:\Users\Public\NPVR\Scripts\ParallelProcessing.bat
2013-01-21 20:00:00.082    [DEBUG][7]    Stopping recording (1636 on 21). Past end time of recording. 18
2013-01-21 20:00:00.092    [DEBUG][7]    StopStream
2013-01-21 20:00:01.092    [DEBUG][7]    Starting: C:\Users\Public\NPVR\Scripts\PostProcessing.bat "D:\nPVR\Bones\Bones_20130121_19001959.ts" 3 1636 21
2013-01-21 20:01:00.258    [DEBUG][7]    Stopping recording (1638 on 23). Past end time of recording. 1
2013-01-21 20:01:00.268    [DEBUG][7]    StopStream
2013-01-21 20:01:00.768    [DEBUG][7]    Starting: C:\Users\Public\NPVR\Scripts\PostProcessing.bat "D:\nPVR\The Carrie Diaries\The Carrie Diaries_20130121_19002000.ts" 9 1638 23
2013-01-21 20:31:00.051    [DEBUG][7]    Stopping recording (1641 on 23). Past end time of recording. 2
2013-01-21 20:31:00.051    [DEBUG][7]    StopStream

So the way I read that, at 19:59 NRecord wants to start recording Two Broke Girls on physical channel 116 using tuner 21, and correctly determines that tuner is currently busy on physical channel 117. So it goes looking for a tuner to move it to, and chooses tuner 23 which is still recording The Carrie Diaries until 20:00pm (and it's not padding, it's during the actual recording time which should be sacred). It appears to think it's starting a second stream on the same physical channel, but tuner 23 is actually on physical channel 113, not 116.

The NDigitalHost for tuner 23 just does what it's told:

Code:

2013-01-21 18:59:02.815    [INFO][4]    DigitalRecorder.StartStream(D:\nPVR\The Carrie Diaries\The Carrie Diaries_20130121_19002000.ts)
....
2013-01-21 18:59:02.815    [INFO][4]    Creating BDA graph
2013-01-21 18:59:03.165    [DEBUG][4]    About to tune BDA graph:
<tuning>
  <type>QAM</type>
  <locator>
    <physical_channel>113</physical_channel>
  </locator>
  <service_id>2</service_id>
  <tsid>43</tsid>
  <service_type>1</service_type>
</tuning>

2013-01-21 18:59:03.165    [INFO][4]    Setting locator to BDA_MOD_256QAM

2013-01-21 18:59:03.165    [INFO][4]    Tuning to frequency 113
2013-01-21 18:59:03.175    [DEBUG][4]    About to try setting tuner modulation
2013-01-21 18:59:03.175    [DEBUG][4]    Got tuner output pin
2013-01-21 18:59:03.175    [DEBUG][4]    Got IKsPropertySet interface
2013-01-21 18:59:03.175    [DEBUG][4]    KSPROPSETID_BdaDigitalDemodulator is supported...
2013-01-21 18:59:03.175    [DEBUG][4]    Modulation set
2013-01-21 18:59:03.175    [DEBUG][4]    Resetting metadata
2013-01-21 18:59:03.175    [DEBUG][4]    About to submit tuning request
2013-01-21 18:59:03.615    [DEBUG][4]    Resetting metadata
2013-01-21 18:59:03.615    [DEBUG][4]    Calling LockChannel()
2013-01-21 18:59:03.625    [DEBUG][4]    locked=0, present=0, strength=100, quality=60   (took 0ms to check)
2013-01-21 18:59:03.635    [INFO][4]    DigitalRecorder.StartStream() allocated handle: 0x1
2013-01-21 18:59:03.655    [DEBUG][4]    Temp at 1/21/2013 6:59:13 PM
2013-01-21 19:59:00.576    [INFO][246]    DigitalRecorder.StartStream(D:\nPVR\2 Broke Girls\2 Broke Girls_20130121_20002030.ts)
2013-01-21 19:59:00.576    [DEBUG][246]    Switching BDA graph to tune:
<tuning>
  <type>QAM</type>
  <locator>
    <physical_channel>116</physical_channel>
  </locator>
  <service_id>1</service_id>
  <tsid>46</tsid>
  <service_type>1</service_type>
</tuning>

2013-01-21 19:59:00.576    [DEBUG][246]    Frequency has changed, so stopping recording from previous frequency. (Handle 1)
2013-01-21 19:59:00.976    [INFO][246]    Setting locator to BDA_MOD_256QAM

2013-01-21 19:59:00.976    [INFO][246]    Tuning to frequency 116
2013-01-21 19:59:00.996    [DEBUG][246]    About to try setting tuner modulation
2013-01-21 19:59:00.996    [DEBUG][246]    Got tuner output pin
2013-01-21 19:59:00.996    [DEBUG][246]    Got IKsPropertySet interface
2013-01-21 19:59:00.996    [DEBUG][246]    KSPROPSETID_BdaDigitalDemodulator is supported...
2013-01-21 19:59:00.996    [DEBUG][246]    Modulation set
2013-01-21 19:59:00.996    [DEBUG][246]    Resetting metadata
2013-01-21 19:59:00.996    [DEBUG][246]    About to submit tuning request
2013-01-21 19:59:01.246    [DEBUG][246]    Resetting metadata
2013-01-21 19:59:01.246    [DEBUG][246]    Calling LockChannel()
2013-01-21 19:59:01.246    [DEBUG][246]    locked=1, present=1, strength=100, quality=60   (took 0ms to check)
2013-01-21 19:59:01.256    [INFO][246]    DigitalRecorder.StartStream() allocated handle: 0x2
2013-01-21 19:59:01.256    [DEBUG][246]    Temp at 1/21/2013 7:59:11 PM
2013-01-21 20:01:00.268    [INFO][254]    DigitalRecorder.StopStream() handle: 1
2013-01-21 20:31:00.051    [INFO][91]    DigitalRecorder.StopStream() handle: 2

NDigitalHost knows the frequency has changed, so it stops delivering data on handle 1 as soon as it switches frequencies and allocates handle 2. Yet 2 minutes later, it gets a stop request for handle 1 from NRecord, as NRecord doesn't realize it has already stomped on that recording.

[Handy.Man]

One workaround is to fine tune bordering shows with TV Listings/TV Recording Pre-Post Padding with positive or negative minutes.
The individual show settings are lost after an EPG update !!! and have to be redone after each update.
The settings are are kept if you update the Season/Recurring recording.

You can not change the padding of ongoing recording
The tuning has to be done before the 'precious' show start, update to surrounding show while the 'precious' show is ongoing will not prevent two channels on the same tuner 'issue'.

Also you have to use TV Recording Listing not Recording to manage the recordings. NextPVR will crash if you try to manage a 'negative' minutes show with Recordings

Not BulletProof but manageable although not 'supported' in NextPvr per se.

[TVHelp]

One workaround is to fine tune bordering shows with TV Listings/TV Recording Pre-Post Padding with positive or negative minutes.
The individual show settings are lost after an EPG update !!! and have to be redone after each update.
The settings are are kept if you update the Season/Recurring recording.

You can not change the padding of ongoing recording
The tuning has to be done before the 'precious' show start, update to surrounding show while the 'precious' show is ongoing will not prevent two channels on the same tuner 'issue'.

Also you have to use TV Recording Listing not Recording to manage the recordings. NextPVR will crash if you try to manage a 'negative' minutes show with Recordings

Not BulletProof but manageable although not 'supported' in NextPvr per se.

Thanks for the info.

FYI - Original recurring setup was via TV GUIDE so I have now updated the padding via TV Recordings recurring panel. We will see if that helps, may need to wait until next Monday to see what happens.

Note - I actually have updated post padding during show recording in progress successfully in the past (due to delayed start of programming due to sports), but don't think of this as a solution to my problem as how would I know when it is going to happen. But that was before most recent patches, I will have to try that again to see if it still works!

[TVHelp]

Yes, I see what you mean. It looks like NRecord is losing track of which tuners are busy on which frequencies. I encountered a similar sort of bug previously, and sub was able to find the logic flaw and fix it fairly quickly; hopefully the same is true this time.

Thanks, glad to see I was not crazy, there may have been a previous patch that was lost.. Will wait to hear from sub...

[johnsonx42]

Any fine tuning or work-arounds suggested will only help for out-maneuvering NPVR's normal scheduling logic, which on some occasions isn't perfect particularly when you really, really want padding. You've encountered a real bug which will cut a recording short no matter what machinations you've gone through beforehand.

[Handy.Man]

Any fine tuning or work-arounds suggested will only help for out-maneuvering NPVR's normal scheduling logic, which on some occasions isn't perfect particularly when you really, really want padding. You've encountered a real bug which will cut a recording short no matter what machinations you've gone through beforehand.

This happens about every days (3 tuners here) when I don't carefully plan the padding :-(

[Handy.Man]

Thanks for the info.

FYI - Original recurring setup was via TV GUIDE so I have now updated the padding via TV Recordings recurring panel. We will see if that helps, may need to wait until next Monday to see what happens.

Note - I actually have updated post padding during show recording in progress successfully in the past (due to delayed start of programming due to sports), but don't think of this as a solution to my problem as how would I know when it is going to happen. But that was before most recent patches, I will have to try that again to see if it still works!

Yup but these were probably 'positive' minutes padding if using TV Guide/Recording. Neg one are more problematic.

[TVHelp]

I guess a 'new feature' request might be to have the option to specify which tuner to use per recording during the setup of that scheduled recording and not allow the process to stomp on it. But then I guess that is the main problem here anyway. If that were fixed it would not be needed. But still, I could see some usefulness in that option..

[Brad242]

TVHelp,
The feature is already there (in a hackish kind of way...):

1. Make sure your EPG update has already occurred, as it will undo any changes you make. I rarely record around 2pm so I have the EPG update set to 14 (14:00 hours).
2. Wait until nothing is currently recording (stopping the service below will stop any recordings in process).
3. If you need to manually schedule anything, do it now. Then close the NPVR app (I don't use it (I'm NEWA only), but I suspect it isn't happy if you stop the service with the app running).
4. Stop the NPVR service. I do it in a batch file (cmd prompt):
net stop "NPVR Recording Service"
5. Start SQLiteSpy and open the npvr.db3 database.
6. Go to the CAPTURE_SOURCE table and note the oid of your active tuners. I only use ATSC and not QAM, so I only note the ATSC oids. As long as you don't change tuners, the oids should remain stable, so you can skip this step in the future.
7. Double click the SCHEDULED_RECORDING table to view it. You may have to increase the column widths in SQLiteSpy for the start_time and end_time columns. I find it easiest to click the start_time column to have it sort the table by start times, as I'm only fixing the current evening's recordings.
8. Study the start and end times in the db and note the conflicts. It helps to have opened the NEWA guide in your web browser before you stopped the service so you can see what shows are on the same channel and/or tuner. Note the web server is down at this point, so you want to be sure the guide was showing the right stuff beforehand. Sometimes I'll have open a 2nd tab to a different time slot if necessary.
9. Change tuners so there are no conflicts by editing the capture_source_oid of the programs with an appropriate oid from step 6.
10. Close SQLiteSpy (it automatically saves the db the moment you make any edits).
11. Start the NPVR service:
net start "NPVR Recording Service"
12. If you were using NEWA, delete the cookie NEWA saved in your browser, (stopping the NPVR service expires the cookie), then refresh the NEWA guide. I set up a separate Firefox browser instance just for NPVR, so I'm not muddling through a list of other cookies, and just delete all each time.
13. Don't add any other recordings or do a EPG update until the shows you fixed are done recording.

I do this typically on Wednesday and Thursday when I need 3 or more tuners. Looks like a bunch of steps, but after a few months practice, I don't even think about it.

I suspect the issue TVHelp posted about is the same as in the thread I started a few months ago:
http://forums.nextpvr.com/showthread.php...ers-active

I hinted at it there, but I'll blatently point it out here: in my humble opinion, the in-advance scheduling logic is broken, and NPVR relys on some just-in-time logic to reallocate tuners on the fly just before the recording is about to start. On my 3 XP boxes as I noted in the thread, the just-in-time logic does not work properly and kills one or more of the active recordings several minutes before the end of the show(s). By editing the db manually, I'm removing the conflicts and the just-in-time logic never kicks in and I have perfect recordings with padding fully working. Several folks suggested XP is to blame for the just-in-time logic failing and it may well be, but in my humble opinion NPVR should not be scheduling recordings that are on different RF channels on the same tuner, but it does. It doesn't matter if these are recurring recordings or one time or a mix of both. It screws it up most of the time. Every time I go into the db, I just shake my head at the decisions it made, then fix them manually and go on my way.

I do understand sub is a really busy guy (I can relate!) and hope eventually he can find time to pin down the issue. If the logic to fix this is really complex, perhaps taking a look at some of the other open source project's source code and allocation logic might be beneficial.