recordings prematurely 'stop'

[moonmeat]

I am trying to setup NextPVR in with the lastest docker image from this thread on a Mac Mini (192.168.0.101): https://forums.NextPVR.com/showthread.php?tid=61999

I am using a legacy HDHR3-US (HDHomeRun DUAL, 192.168.0.109). I have set the IP ENV and opened the udp ports as described here: https://forums.NextPVR.com/showthread.php?tid=59393. The host firewall is off.

I have run a channel scan with the SiliconDust HDHR setup software from a windows computer and can see my channels. In this setup software, I have set the BDA compatibility to NextPVR.

I have setup an xmltv file for the program guide.

I am accessing NextPVR through the web interface. I have scanned my HDHR3-US device and can see my channels in the NextPVR channel settings and in the guide, and can start and schedule recordings. The second tuner channels were copied from the first.

However, for some reason unknown to me, recordings will 'stop' earlier than scheduled. Although the NextPVR software will claim it is recording and will seem to stop at the desired stop time, the .ts file will be truncated with a shortened length (e.g. expected length 63 min with padding is 45 min). The next recording will seem to start (and stop) with the usual recording indicators in the recording 'tab' and highlighted red in the guide, but the .ts file will be empty.

I will need to restart the NextPVR docker container to get an actual recorded file generated again, but it will again stop at some point. This happens independently with each of the 2 tuners.

For example, from the attached log, a scheduled recording started at 15:31 around log line 16506.

By line 16695, the number of bytes received stopped changing at 3656983708:
2025-01-21 15:32:22.264 [DEBUG][51] Have received 3656921856 bytes from rtp source

The log continues to report this number of bytes received until the recording stops around 16:00. The actual recorded .ts file is only 1 min 23 seconds long (should have been ~29 min).

The next recording started at 4:00pm and reports having received 0 bytes:
2025-01-21 16:00:01.395 [DEBUG][57] Have received 0 bytes from rtp source

I canceled the recording at ~16:17:
2025-01-21 16:17:16.176 [DEBUG][57] Have received 0 bytes from rtp source
The .ts file was empty.

I had the second tuner recording as well, and it stopped recording received bytes at
2025-01-21 15:58:03.184 [DEBUG][55] Have received 2050597780 bytes from rtp source
The .ts file was short. The next scheduled recording (16:00) on the second tuner reports receiving no data until I stopped it at 16:22. The .ts file was empty.

I restarted the NextPVR docker container at ~17:03 and initiated 2 recordings at ~17:05 to show that they start as usual after a restart. I canceled them both about 9 min later. The .ts files are OK at this point, but recordings will surely fail again.

The HDHomeRun DUAL device behaves fine on another system that I am exploring migrating from. I have another device, a non-legacy HDHomeRun CONNECT, that works properly with NextPVR (not connected during the above reported testing results). The tuners are up to date with the current firmware.

I have attached the logs. Any guidance on what I may be doing incorrectly or incompletely would be appreciated. Thank you.

[mvallevand]

This could all be explained by poor signal so hard to say. Does host mode work better?

However if you have a legacy and standard HDHR you can't necessarily copy there is a flaw in the copy design that could corrupt a legacy tuner which could explain some issues.

Martin

[moonmeat]

This could all be explained by poor signal so hard to say.

I don't understand how this could all be explained by a poor signal. I live in a metro area with stronger signals and experience this issue on all channels when using the legacy device.
A tuner in the legacy device, after stopping working with NextPVR, continues working with other software without interaction. But NextPVR can't record from a tuner in the legacy device from any channel, regardless of signal strength, after it 'stops', until a NextPVR reboot (when using the recommended docker published port settings). As an additional note, the legacy device tuner LEDs on the device turn on and stay on for the full duration of all scheduled recordings, they do not turn off early.

Does host mode work better?

Thanks for this suggestion. Host mode does work 'better', but not good enough. Let me explain. In bridge mode, as stated above, once NextPVR stops receiving data, it can't resume receiving data until it (NextPVR) is restarted. However, in host mode, NextPVR will still unfortunately stop receiving data at 'random' times, but it will successfully start receiving data again when the next recording is started (without reboot). Does this help with the troubleshooting process?

However if you have a legacy and standard HDHR you can't necessarily copy there is a flaw in the copy design that could corrupt a legacy tuner which could explain some issues.

I did not have the standard HDHR device connected, nor did I copy anything to or from its tuners. My procedure was this: I scanned one tuner on the legacy HDHR device, apparently successfully, then copied the channels to its other tuner, then updated the EPG.  I have also scanned both legacy device tuners separately, with the same outcome. If there may be something corrupted related to the legacy HDHR device channel scanning, is there any suggested remedy?

Thanks again.

[mvallevand]

I just wanted to confirm that you didn't copy. The UDP ports you pass through Docker might be getting confused which is why I suggested host mode. I cannot explain why data stops flowing but it is UDP and it looks like NextPVR closes the port when data stops. You aren't using other software at the same time are you?

Also note NextPVR doesn't scan HDHR tuners, it uses the information that you have configured on the Silicondust site from Windows software.

Personally I'd try on bare metal and see if it is Docker, especially the comment that NextPVR does properly reset the UDP ports in host mode.

Perhaps have Silicondust review your device on their forum, I know they logs things but maybe with the legacy devices it is limited.

Martin