Problem with back-to-back recordings with HDHR Prime tuner on different channels

[BrettB]

Looking at the NRecord.log, I think that I may have figured out what the problem is. I'm guessing that when NextPVR has a tuner locked, tuned to a channel and streaming from that channel to a port, then changes the tuner to a different channel and directs streaming to a different port, it is presuming that the HDHR will stop streaming to the first port. But, (again still guessing at this point) the HDHR is actually streaming the newly tuned channel to BOTH ports. I just checked the HDHR's log and here's what it shows:

Code:

20170227-03:53:55 Tuner: tuner0 tuning 804 WCCO HD (auto:237MHz-1)
20170227-03:53:56 CableCARD: tuner0 804 WCCO HD (auto:237MHz-1) access = subscribed
20170227-03:53:57 Tuner: tuner0 streaming rtp to 192.168.143.10:36312
20170227-03:59:59 Tuner: tuner0 tuning 825 USA HD (auto:159MHz-9)
20170227-03:59:59 Tuner: tuner0 streaming rtp to 192.168.143.10:36313
20170227-04:00:00 CableCARD: tuner0 825 USA HD (auto:159MHz-9) access = subscribed

Since the log file doesn't ever show streaming stopping, it doesn't help a whole lot.

I just setup a new test, and during the overlapping time period, I'll check the network traffic to see if it is indeed going to both ports.

[BrettB]

I just setup a new test, and during the overlapping time period, I'll check the network traffic to see if it is indeed going to both ports.

Well that test showed that after the channel change, NRecord was only listening on the new UDP port. So my guess was wrong. Here's an updated set of logs which shows the 2nd test.

[sub]

Hopefully this patch will stop the original recording at the time it switches over.

[BrettB]

Hopefully this patch will stop the original recording at the time it switches over.

Thanks for looking into this problem, sub. Unfortunately, it doesn't appear that this fix is quite right. I just got a chance to put it in to test. See the attached logs. I started a recording of WCCO 4 News at 6:57am (it was scheduled until 7:00am) on channel 804. Then scheduled Bad Dog! (starting at 7:00am) on channel 818. At 6:59, the 2nd recording did start trying to do the pre-padding as expected. And waited until 7:00am to force allocating the tuner. The NRecord.log does now show

Code:

2017-03-02 07:00:00.289    [DEBUG][10]    Stopping stream from previous frequency: 1

And, the file for WCCO 4 News did stop growing at 7:00am when the file for Bad Dog! started. So, that all looked good.

But then when I went to test playing the file for WCCO 4 News in NextPVR, it is showing a timeline duration of 00:07:50. It plays until 00:02:49 and then returns to the recording list. And the recording list indicates that it went until 7:05am. (I'm fairly sure that for other recordings where the pre- or post-padding couldn't be honored, the recording list is showing the actual start/end time for the recording without the pre- and/or post-padding time.)

Here's a link where you can download the .ts file from the WCCO 4 News recording: https://bowmantech-my.sharepoint.com/per...YibPNiBRn4

UPDATE: I extracted the timing.info file from the WCCO 4 recording (included in the new logs.zip). It didn't seem to go on until 07:50. So I tried playing it in the Native NextPVR, and it shows the duration at 02:50. (Updated logs zip should show this play attempt.) So, maybe it is just an issue with the web client (used by my X-NEWA in Kodi) OSD determining the file length.

[mvallevand]

So, maybe it is just an issue with the web client (used by my X-NEWA in Kodi) OSD determining the file length.

No it is more than just timing.info and the visual duration. Checking your logs and earlier ones in the thread, the post processing is happening on the first file when the second file stops not when the station changes.

2017-03-02 07:05:00.079 [DEBUG][10] Starting: C:\Users\Public\NPVR\Scripts\PostProcessing.bat "E:\NPVR Recordings2\WCCO 4 News This Morning at 6\WCCO 4 News This Morning at 6_20170302_06000700.ts" 804 193795 1565 "WCCO 4 News This Morning at 6"

Martin

[BrettB]

No it is more than just timing.info and the visual duration. Checking your logs and earlier ones in the thread, the post processing is happening on the first file when the second file stops not when the station changes.

Thoughts, sub?

[sub]

I think I know what's going on, and I'll have another go at fixing it, but it'll have to wait a few days - my home office, and development machine are currently dismantled while I'm redecorating the room.

[BrettB]

I think I know what's going on, and I'll have another go at fixing it, but it'll have to wait a few days - my home office, and development machine are currently dismantled while I'm redecorating the room.

Hey, sub. How's the redecorating coming along?

[BrettB]

Hey, sub. How's the redecorating coming along?

Any progress on this problem, sub?

[sub]

I'm not able to provide you a patch for this, but I'm fairly confident I have resolved it for the next release.