Problems with new HDHR tuner

[MovieBuff]

I just replaced my HD HomeRun Flex 4K quad tuner with a new one (I was experiencing increasing failures with messages like “HDHR stream failed” and ”No data delivered”.  I couldn’t see any cause for the missed recordings and guessed that the HDHR was starting to fail).  The new unit is the same model as the old one.  I installed the new unit following Silicondust instructions, and then went into NextPVR Settings\Devices and ran a scan to detect the new tuners, then enabled the same channel listing I had already set up for the old tuners for each new tuner.  Any old tuners in the device listing have been set to Disabled status.

However, it appears that my recordings are not operating in the same way that they did with the old HDHR.  With that unit, recordings made on the same channel, even if they had different sub-numbers (e.g. 4.1, 4.2, 4.3, etc.) would only use one tuner, and multiple programs would overlap on the tuner while finishing their pre-pad and post-pad times.  If a program on another channel needed a tuner and no other tuner was free, a program with a post-pad would give up the tuner for the program that needed to be recorded.  It was all very slick.

With the new tuner, it seems that this common channel sharing sometimes occurs, but usually does not.  Additionally, it also appears that a program with a post-pad may not relinquish the channel to a program that is scheduled to be recorded in the same time slot, even if no other tuner is available for the program to be recorded.  With my previous tuner, this was not a problem.  As a result, I am seeing recording failures with a message of “Failed:  No error, but no data delivered.  This is usually because the device failed to lock a signal.”

As an example, in the attached log2 file, there is an error message for the show The Last Stand at the following time stamp.  This show did not record because a couple of other programs still had a few minutes left in their Post-pad recording time and one of them did not relinquish its tuner:

2023-04-06 17:57:21.246             [DEBUG][10]               WebException: System.Net.WebException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

I also took a quick look at the Search tool for this program and saw a message “Failed to start requested stream”.

I was thinking that the allocation of tuners is managed by NextPVR.  Is this the case?  If so, can you suggest anything that I may have missed when setting up the new tuners that may have been the cause of this change in operation?

I have a default Pre-pad of 3 minutes and Post-pad of 33 min for all programs.  The first test recordings started from a sleep state.  I rebooted the PC a couple of times and also restarted the HDHR before conducting the test.

[sub]

However, it appears that my recordings are not operating in the same way that they did with the old HDHR.  With that unit, recordings made on the same channel, even if they had different sub-numbers (e.g. 4.1, 4.2, 4.3, etc.) would only use one tuner, and multiple programs would overlap on the tuner while finishing their pre-pad and post-pad times. 

For the majority of the HDHomeRun devices (on Windows), you have the option of either using the default 'HDHR' device type, or installing the BDA drivers which gets you both ATSC and HDHR device types (on the Settings->Devices page). You'll only get this behaviour you describe when you've setup your channels on tuner type 'ATSC'. You do not get this when your tuner type is 'HDHR'. Sounds like you're using the 'HDHR'.

This is a limitation of the HDHomeRun protocol, and not something NextPVR has any control over.

If a program on another channel needed a tuner and no other tuner was free, a program with a post-pad would give up the tuner for the program that needed to be recorded. It was all very slick.

It'll behave this way it'll behave for all device types.

[MovieBuff]

Thanks very much!  NextPVR had included ATSC options for these tuners in the Device listing when I ran the Devices scan, so I enabled these tuners and disabled the HDHR type tuners.  After updating the channel listings for the new tuners, I ran another test to see how the 4 tuners managed multiple programs.  I watched the behavior using the NextPVR system tray tool.  The tool showed the tuners now properly sharing programs with common channels during both the recording periods as well as the padding periods.  The change to the ATSC tuners seems to have addressed the problem that I was observing in my post.

However, while the recordings appeared to be working properly in the system tray tool, there were still some failed recordings.  There appeared to have been multiple causes.  One of the recordings (Good Times) was in the initial group of programs that I selected when I started the test.  Per the system tray tool, it appeared to be recording properly and showed as Recording in the Recent Recordings listing while the program was airing and during the post-pad period.  However, when I looked at the Recent Recordings listing after the program and post-pad were completed, the program showed as “Failed: No errors, but no data delivered.  This is usually because the device failed to lock a signal.”  This is a fairly strong station and my antenna was pointed toward it, so this seems odd, and I am wondering whether anything else might be an issue.  In the logs, this recording appeared to be starting about 2023-04-07 10:36:11.508.

A similar failure occurred for a program that initiated part way through the test (What’s for Sale), from the same channel group as the program mentioned above.  It appears to have started recording at 2023-04-07 11:27:00.214 in the log.
If there is nothing unusual in the log, this may indicate a lack of sensitivity in the new tuner compared to the old one.  If so, I can test this with further recordings.

Other recordings that were scheduled to start in the middle of the test worked OK.  If you want an example for comparison, Curious George appears to have started at 2023-04-07 11:27:02.141 and recorded correctly.

The other issue I encountered is that recordings that were already scheduled to record before I installed the new tuners, either through recurring or individual scheduling requests, seem to be experiencing a high rate of failures.  I had some of these previously scheduled recordings mixed in with the programs I scheduled for the test today, and another one followed the test later in the day when there were no other recordings active.

During the test, I was watching to see how these were handled, since similar previously scheduled programs had failed in yesterday’s test.  During the test, the programs appeared in the Recent Recordings listing as though they were recording properly, but did they not appear in the system tray tool as recording in any of the tuners. In looking at the log (both programs during the test were Ironside:  I looked further in the log at the details of the second program, episode S01E07, where the scheduled program appears to be starting about 2023-04-07 11:57:00.179), the stream has an unusual reference to an IP address, which later entries appear to indicate is invalid.  Later in the day, a recording of Murdoch Mysteries (starting around 2023-04-07 13:57:00.210) also contained an IP reference that was likewise not found.  I am wondering whether recordings scheduled before the new tuner was installed have some reference that needs to be updated, or if the scheduled recordings, both the recurring ones and the individual scheduled ones, need to be deleted and replaced with new requests?

In order to try to salvage the scheduled recordings, I quickly brought up the Search tool during the Pre-Pad period so that I could find the program and cancel it, and I then opened the program again and clicked Record Once.  After clicking the Record Once button, the program appeared in the system tray tool, and appeared to be properly sharing a tuner with another program from the same channel group. It also indicated Recording in the Recent Recordings listing.  However, after the completion of the test, I saw that they both also had the “Failed: No errors, but no data delivered” messages in the Recent Recordings listing.  (the cancellation log entries appear around 2023-04-07 11:58:36.867 and the attempted re-start about 2023-04-07 11:58:42.024)  I am wondering whether I tried to re-start it too quickly after the cancellation attempt, or if there is some other cause?  This station is the same channel group as the ones mentioned above; I have not experienced a failure with this channel group before when I have had the antenna pointing in its direction, so it should not have failed due to a weak signal unless the new tuner is not working properly.

Thank you!

[sub]

I'd suggest deleting the older HDHR tuners you had you previously, rather than just disabling the tuners. There are some scenarios where disabled tuners can still be used.

On the Settings->Devices screen, hold the Ctrl key on your keyboard, and click the 'delete' button that appears. They'll reappear next time NextPVR is restarted, but with no channels on them.

The other issue I encountered is that recordings that were already scheduled to record before I installed the new tuners

Did you update the EPG after installing the new tuner and disabling the old ones? This is one of those scenarios. Delete the HDHR ones, reboot, then do an Update EPG.

During the Update EPG it'll reschedule the recordings, and allocate them to the available tuners.

[mvallevand]

Does your hdhr always get the same ip from the router and do you only use NextPVR to access it? Both of these can impact recordings and live TV.

Martin

[MovieBuff]

I deleted the disabled tuners and rebooted my PC.  However, when the PC came back up, the NextPVR icon in the tray remained gray.  I checked that the NextPVR service was running, which it was, but restarted it just to be sure.  When I opened the NextPVR application and opened Settings, I received a message, apparently from localhost:8866 "Unexpected error loading settings!"  My connection to the internet seems to be fine, as other web sites are working OK.  I repeated this process 2 times to see whether further rebooting would address the issue.  Suggestions?

Regarding the IP question ... I haven't paid attention to the HDHR tuner's IP address in the past.  It is connected to the router via hard wire and an ethernet switch and so it should be consistent from one session to the next.  Since the new tuner would now be a new device on the network, the router may have assigned it a different IP address.

[sub]

I deleted the disabled tuners and rebooted my PC.  However, when the PC came back up, the NextPVR icon in the tray remained gray.  I checked that the NextPVR service was running, which it was, but restarted it just to be sure.  When I opened the NextPVR application and opened Settings, I received a message, apparently from localhost:8866 "Unexpected error loading settings!"  My connection to the internet seems to be fine, as other web sites are working OK.  I repeated this process 2 times to see whether further rebooting would address the issue.  Suggestions?

It sounds like your recording service wasn't running. Maybe you needed to wait a little longer after rebooting, to ensure the service had fully started.

[MovieBuff]

It's been up for about 10+ minutes now.  Services says that it is running, but just restarted it to be sure, and says it is running.  I also restarted Firefox to see if that helped.  Still getting the same message.

I saw in another post a suggestion to connect to localhost:8866/index.html.  I gave that a try and received a reply that Firefox can't establish a connection to the server at localhost:8866.

Suggestions?
Thank you!

[sub]

Stop the service, and try manually running NextPVRServer.exe (not similar named NextPVRService.exe), and see if it has an errors on the screen. Try seeing if the web browser then connects.

[MovieBuff]

There was an error when I ran the NexgPVRServer program:  "Unhandled exception.  System.Collections.Generic.KeyNotFoundException: The given key '47' was not present in the dictionary.
     at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
     at NShared.RecordingService.WorkerThread()
     at System.Threading.Thread.StartCallback()"

When I closed the window, I noticed that the system tray icon had changed from gray to green.  However, when I tried to open the web application, it was unresponsive.

I rebooted, and followed the same process again.  This time, the error did not appear when I ran the .exe and the tray icon turned green.  But the web application was still mostly unresponsive, and Devices did not populate a list of available tuners.  Clicking the Re-scan button produced only 3 blank lines.

I rebooted again, and this time the tray icon turned green immediately after startup and when I opened the web application, it prompted me to log in.  After logging in and opening Settings/Devices, it displayed the 4 ATSC tuners that I had set up, as well as a list of devices that I thought I had deleted (HDHR, QAM, etc).  I deleted them again and rebooted again.  After rebooting, I opened Devices again, and the list reappeared.  So I gave up trying to delete them and just disabled them again. 

I'm now updating the EPG.  Looks like this may take a while, so I'm going to let it run and see how it works tomorrow morning.  Thank you very much for your guidance!