NextPVR Refuses to Record if signal doesn't lock fast enough

[ChaosMageX]

NextPVR suddenly started doing something weird today and started to fail at recording just about all my shows. Looking at the ndigitalhost log files, it looks like it's failing for some reason even if the signal locks successfully. Is it not locking fast enough or what's happening?

Code:

2018-05-02 08:59:00.241    [INFO][71]    DigitalRecorder.StartStream(E:\NextPVR\RecordedTV\Great Day Houston\Great Day Houston_20180502_09001000.ts)
2018-05-02 08:59:00.241    [DEBUG][71]    Calling LockChannel()
2018-05-02 08:59:00.241    [DEBUG][71]    locked=1, present=1, strength=100, quality=98   (took 0ms to check)
2018-05-02 08:59:00.241    [DEBUG][71]    File size is 0
2018-05-02 08:59:00.241    [INFO][71]    DigitalRecorder.StartStream() allocated handle: 0x24
2018-05-02 08:59:00.251    [DEBUG][71]    Temp at 5/2/2018 8:59:10 AM
2018-05-02 09:01:00.041    [INFO][37]    DigitalRecorder.StopStream() handle: 23
2018-05-02 10:01:00.196    [INFO][37]    DigitalRecorder.StopStream() handle: 24
2018-05-02 10:01:00.196    [INFO][37]    No more streams active. Stopping device.
2018-05-02 10:01:00.196    [DEBUG][37]    About to request async graph stop
2018-05-02 10:01:00.196    [DEBUG][27]    Graph stopping... (async)
2018-05-02 10:01:00.216    [DEBUG][27]    Graph reports state 'Stopped'
2018-05-02 10:01:00.216    [DEBUG][27]    Graph stopped (async)
2018-05-02 10:01:00.216    [DEBUG][37]    Async stop completed successfully
2018-05-02 10:01:00.216    [DEBUG][37]    Removing filter  MPEG-2 Sections and Tables
2018-05-02 10:01:00.216    [DEBUG][37]    Removing filter  BDA MPEG2 Transport Information Filter
2018-05-02 10:01:00.216    [DEBUG][37]    Removing filter  MPEG-2 Demultiplexer
2018-05-02 10:01:00.216    [DEBUG][37]    Removing filter  NPVR TS Mon
2018-05-02 10:01:00.216    [DEBUG][37]    Removing filter  Tuner
2018-05-02 10:01:00.216    [DEBUG][37]    Removing filter  Network Provider

Now I've noticed that I'm still running version 4.0.4 and version 4.1.1 is out, so I will be upgrading shortly and hope that fixes the problem...BUT WILL IT?! Has this problem been fixed at any of the releases since 4.0.4?

And if not, is there some setting somewhere I can tweak to tell NextPVR not to time-out so quickly if it fails to lock a signal at first?

I've attached the full logs to this thread in the hopes that it will help determine the problem and find a solution.

EDIT: After restarting the computer running NextPVR, as well as the SiliconDust HDHomeRun Connect HDHR4-2US on which those failed recordings took place, it seems to be working again...for now. I'll still upgrade NextPVR and hope that helps, but I really would like to know if I should keep worrying about this happening after upgrading NextPVR.

[sub]

NextPVR Refuses to Record if signal doesn't lock fast enough

This is not correct. There is no timeout.

NextPVR reports the signal lock in the log, but pays no attention to it itself, since it knows that many devices misreport this stuff.

When it's doing a recording, it basically starts the device, requests the device tunes to the correct frequency, then will accept any data that arrives from the device up until the end time of the recording. It's been this way since the very first release of NextPVR, and hasn't changed recently.

That log shows a recording starting at 08:59, and finishing at 10:01. Any data received from the device during this time should be captured in the recording. If there was nothing in the file, check if that channel ever works - they may have moved that channel to a different frequency or something.

[ChaosMageX]

No need to verify that the channel still works, since the recording I mentioned is successfully working after the restart is on that same channel, and I'm just about finishing verifying the other channels through the Kodi interface to NextPVR.

Luckily (hopefully) I don't have to worry about the UHF channel frequency changes until this fall.

It would seem that in this case I guess the fault lies with the SiliconDust HDHomeRun Connect HDHR4-2US, which is apparently falsely reporting a signal lock. I guess now I know that whenever I spot this happening I should try hard resetting the tuner.

Man, I really wish there was a way to retrieve more diagnostic data from the SiliconDust HDHomeRun tuners than just the limited data their log.html page has to offer. Then I could at least catch them in the act of failure.