1.5.36 Recordings Change Channel Mid-stream

[BrettB]

I do not have any analog devices. All cable, clear QAM. I've got 4 tuners--1 dual-tuner HDHR giving 2 and 1 AverMedia A188C PCIe Pure ATSC card giving 2. All tuners are connected to the same cable source and have the same channels configured in npvr. Generally, the HDHR tuners are the ones being used since they have the highest priority.

For this test, the following channels were used:
[INDENT]

• qam256 75-1 233 WCCODT (broadcast 4) 1920x1080i 16:9
  
• qam256 75-2 232 KAREDT (broadcast 11) 1920x1080i 16:9
  
  
• qam256 79-1 231 KSTPDT (broadcast 5) 1280x720p 16:9
  
• qam256 79-3 234 KMSPDT (broadcast 9) 1280x720p 16:9
  

[/INDENT]

I started the following 4 recordings all with 1 minute pre-padding and 2 minutes post-padding. I verified the tuner being used both with the HDHR Config (GUI) and the npvr tray status display.
[INDENT]

• (10453): E:\NPVR Recordings\College Football\College Football_20101231_13001700.ts (Channel 233 - HDHR #0)
  
• (10454): E:\NPVR Recordings\Judge Judy\Judge Judy_20101231_16301700.ts (Channel 234 - HDHR #1)
  
• (10456): E:\NPVR Recordings\Jeopardy!\Jeopardy!_20101231_16301700.ts (Channel 232 - HDHR #0)
  
• (10457): E:\NPVR Recordings\5 Eyewitness News at 430\5 Eyewitness News at 430_20101231_16301700.ts (Channel 231 - HDHR #1)
  

[/INDENT]

Everything starts out just fine. 2 HDHR tuners being used, 4 programs being recorded to 4 files.

Then I scheduled one additional recording:
[INDENT]

• (10455): E:\NPVR Recordings\FOX at 5\FOX at 5_20101231_17001730.ts (Channel 234)
  

[/INDENT]

Now at 17:00 (not 16:59 which pre-padding would indicate), nrecord starts this recording, but it uses HDHR #0. The HDHR Config (GUI) shows that the tuned frequency/channel for HDHR #0 is indeed changed from 75 to 79 at that time. The nprv tray status then shows 3 recordings on that tuner for the 2 minute period 17:00-17:02. When I play the original 2 recordings from HDHR #0, 2 minutes before the end of recording #10456 the file goes from channel 232 to channel 231. What's very strange is that recording #10453 seems to remain on channel 233. And the new recording #10455 records channel 234. The 2 recordings from HDHR #1 seem to work just fine.

There are 2 problems with this situation:

1. Recording #10456 "changes channel" in the middle of the file (actually 2 minutes before the end of the file). These changes cause problems with comskip and mvpmcx2--especially since these two channels aren't using the same resolution.
   
2. Recording #10455 doesn't get its pre-padding eventhough there is already an active & available tuner on the frequency it needs both during the pre-padding and all recording and post-padding times. (In fact, the file for recording #10454 has the contents that should have also been in recording #10455.)
   

[sub]

The was a couple of reports of this with previous versions of NPVR too, but I was never able to reproduce it. I think it intended to cut the recording short at the time this switch, but you continued to get some data from that channel until the end of the padding time because it coincidentally happened to use the same audio/video pids for a channel on the new frequency.

[johnsonx42]

But you do seem to have some issues with the padding logic and/or tuner priority and/or tuner allocation. There was no reason his recording #14055 should have been scheduled on HDHR#0, since HDHR#1 was already tuned to the same frequency. In addition, there were 2 other tuners with the same channel defined sitting idle. It seems if it were really smart it should have used HDHR#1, or if it was only somewhat smart it would have used one of the idle tuners; defaulting back to HDHR#0 is not at all smart.

[sub]

But you do seem to have some issues with the padding logic and/or tuner priority and/or tuner allocation.

Yep, all versions of NPVR have been a bit week and shuffling things around if other tuners are available will the same channel. It'll often just go for the first one available, at the expense of post-padding on some other in-progress recording. (GBPVR had the same sorts of issues when you were using multi-record)

[mvallevand]

But is NRecording expecting PID's to be unique? 0x49, x52 and x53 are very common for OTA ATSC and but the frequencies I checked RabbitEars.Info for Minneapolis MN and many of them use these.

Martin

[sub]

No, its not expecting PIDs to unique. I'm not saying this isnt a bug. It is a bug. It should have told the recording to stop at the time it switched channels, but didnt. I'm just speculating how it could have ended up with another channel in the same file.

[mvallevand]

Ok, thanks, when mvpmcx2 receives the same PID's can get very confused. And boy re-reading the grammar in my last post, you'd think that I had already started celebrating New Year, and I haven't. Sorry about that.

Happy New Year.


Martin