2025-01-22, 03:19 AM
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.
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.