OpenDCT: An open source digital cable tuner.

[tmiranda]

Originally Posted by EnterNoEscape

I don't think you have a disk I/O problem from that log. It looks like maybe you're one of the few people with issues using HTTP streaming from the HDHomeRun. Try this:

1. Stop OpenDCT service
2. Change hdhr.allow_http_tuning=true to hdhr.allow_http_tuning=false in opendct.properties
3. Start OpenDCT service

Great, I'll try this tonight.

What causes this issue? The reason I ask is because when I was running a Windows server OpenDCT worked flawlessly right out of the box.

[EnterNoEscape]

Originally Posted by tmiranda

Great, I'll try this tonight.

What causes this issue? The reason I ask is because when I was running a Windows server OpenDCT worked flawlessly right out of the box.

My best guess is either my NIO HTTP implementation has some subtle issues (that I haven't been able to reproduce) or NIC driver performance. HTTP should generally be more reliable since it's using TCP, but the HDHomeRun will not buffer for you if you're not pulling the stream in fast enough which can result in the poor recording quality you've been experiencing. This change will cause you to use RTP instead which will actually give us more to work with since the packets are numbered and OpenDCT will log when there's a continuity problem which usually means we have a throughput problem somewhere.

[KryptoNyte]

Originally Posted by EnterNoEscape

This might be enough to get around the problem. I'm seeing this log entry: 16:44:49.091 [SageTVRequestHandler-96:HDHomeRun HDHR5-4US Tuner 10757234-0] ERROR HDHRNativeCaptureDevice - The channel '1402' does not have a frequency on the lineup 'atsc_hdhomerun_10757234'.
and I can't figure out where in the code this is being logged from which is really bugging me. The error should only happen in ClearQAM mode. ATSC doesn't check for this kind of thing because we can derive it from the channel requested, yet we see a log entry contradicting that.

Thanks for taking the time to look that over - I'll give it a shot tonight.

If this resolves it, I'll try to back up and restart the install over again to see what's causing it. At the my.hdhomerun.com webpage, where you select QAM or ATSC, then scan/list all available channels, I seem to recall it generating the channel list in OpenDCT with the filename led with qam_ or atsc_ depending on what was selected there. I also wonder if taking my other server/Ceton offline while installing and configuring OpenDCT would make any difference.

These Connect devices with the capability to tune both ATSC and internet streams are surely creating some new challenges for the Sage tuner setup. It would be interesting if it could work where two lineups could be used for each tuner - not exactly sure how that would happen yet.

[tmiranda]

Originally Posted by EnterNoEscape

My best guess is either my NIO HTTP implementation has some subtle issues (that I haven't been able to reproduce) or NIC driver performance. HTTP should generally be more reliable since it's using TCP, but the HDHomeRun will not buffer for you if you're not pulling the stream in fast enough which can result in the poor recording quality you've been experiencing. This change will cause you to use RTP instead which will actually give us more to work with since the packets are numbered and OpenDCT will log when there's a continuity problem which usually means we have a throughput problem somewhere.

Thanks for that info. I'll look at the NIC driver performance to see if there are issues. When I picked out my new motherboard I made sure it had an Intel NIC because they are generally very good compared to the others available.

[tmiranda]

Originally Posted by EnterNoEscape

My best guess is either my NIO HTTP implementation has some subtle issues (that I haven't been able to reproduce) or NIC driver performance. HTTP should generally be more reliable since it's using TCP, but the HDHomeRun will not buffer for you if you're not pulling the stream in fast enough which can result in the poor recording quality you've been experiencing. This change will cause you to use RTP instead which will actually give us more to work with since the packets are numbered and OpenDCT will log when there's a continuity problem which usually means we have a throughput problem somewhere.

I made the change and it's somewhat better. There is still a lot of pixelation. Log attached.

[KryptoNyte]

Nope, that didn't work. Still getting the "No Signal" on this. I did delete the OpenDCT configuration folders, rescanned to cable/qam on the my.hdhomerun.com page, deleted tuner in Sage.properties, and started over (including recommended tweak to comma separated values in lineup). After tuning the program in Sage, I see that there is no stream starting in the HDHR monitoring software.

I captured the OpenDCT log immediately after a failed tuning event, attached.

Is Java 8.181 a potential problem?

[EnterNoEscape]

Originally Posted by KryptoNyte

Nope, that didn't work. Still getting the "No Signal" on this. I did delete the OpenDCT configuration folders, rescanned to cable/qam on the my.hdhomerun.com page, deleted tuner in Sage.properties, and started over (including recommended tweak to comma separated values in lineup). After tuning the program in Sage, I see that there is no stream starting in the HDHR monitoring software.

I captured the OpenDCT log immediately after a failed tuning event, attached.

Is Java 8.181 a potential problem?

I suspect not. I wonder if you're on to something with the InfiniTV being available. I didn't notice it configured in opendct.properties. Try taking it off the network temporarily. OpenDCT might be using it as a reference.

[EnterNoEscape]

Originally Posted by tmiranda

I made the change and it's somewhat better. There is still a lot of pixelation. Log attached.

I don't see an attachment.

[KryptoNyte]

Originally Posted by EnterNoEscape

I suspect not. I wonder if you're on to something with the InfiniTV being available. I didn't notice it configured in opendct.properties. Try taking it off the network temporarily. OpenDCT might be using it as a reference.

Will do. Right after the Brewer game

Off topic - is there a difference between running OpenDCT Console vs. as a service?

[tmiranda]

Originally Posted by EnterNoEscape

I don't see an attachment.

Sorry. Here it is.

[KryptoNyte]

It turned out to have nothing to do with the troubleshooting thus far. One time when running OpenDCT console, I noticed a line item that included Java 64bit as it was scrolling. I checked my OpenDCT install, and it was 32 bit. I had both 32 and 64 bit versions of Java installed. Uninstalled 64 bit, and instantly everything started working.

In the end, I don't know where the issue was, OpenDCT or SageTV.

[tmiranda]

Originally Posted by tmiranda

Sorry. Here it is.

Bump.

[KryptoNyte]

Tom, with the PES Packet size mismatches, is there any helpful information right around post #263 of this thread? I know the environments vary, but maybe some helpful nic settings there.

https://forums.sagetv.com/forums/sho...=62774&page=14

EDIT: Reading beyond that information would lead me to believe that ENE fixed the issues that were appearing there, so maybe not so helpful. In fact, reading the history of this OpenDCT thread tends to shed some real light on the massive amount of time that ENE must have dedicated developing and tweaking this interface software.

[KryptoNyte]

It would probably be good to mention here in regard to setting up the HDHR Connect Quatro tuner with HDHomerun Premium TV in Sage, that I eventually moved this tuner to a Win 10 system for a friend. I had tested on my own Win7 machine and got over all the hurdles documented in the last couple pages of this thread, and then hit a wall when moving that same tuner to Win10. SageTV could see the native Silicondust device, but not the OpenDCT HDHR device (which does not have "Silicondust" in the listed device name in the Sage tuner list).

After some research in this thread, a mention from nyplayer and waylo, I see that the Windows 10 defender firewall was keeping OpenDCT from reporting the DCT version of the HDHR tuner to SageTV. Once the firewall service was disabled, everything starting working as it should.

I won't completely condone shutting down your Win 10 firewall, so anyone that knows the correct procedure to add the necessary software exceptions, please let us know.

[EnterNoEscape]

Originally Posted by KryptoNyte

Will do. Right after the Brewer game

Off topic - is there a difference between running OpenDCT Console vs. as a service?

Not really, but sometimes running it in the console can help troubleshoot issues.

Originally Posted by KryptoNyte

It turned out to have nothing to do with the troubleshooting thus far. One time when running OpenDCT console, I noticed a line item that included Java 64bit as it was scrolling. I checked my OpenDCT install, and it was 32 bit. I had both 32 and 64 bit versions of Java installed. Uninstalled 64 bit, and instantly everything started working.

In the end, I don't know where the issue was, OpenDCT or SageTV.

So you're good?

Originally Posted by tmiranda

I made the change and it's somewhat better. There is still a lot of pixelation. Log attached.

You're dropping packets like crazy (which is what I expected to see from your feedback). Try increasing the UDP buffer size to 8388608:

sudo sysctl -w net.core.rmem_max=8388608

[KryptoNyte]

Originally Posted by EnterNoEscape

So you're good?

I'm good.

Hopefully Tom gets his stuff sorted, too.

[thomaszoo]

I just purchased the Quatro and can't seem to get it to play nice with SageTV. It is installed and shows up as a network tuner in Sage and I got the channel lineup working. I followed all of the instructions (Deacon Crusher) and suggestions for getting it to work such as getting rid of my 64 bit Java. I can't see anything apparent in the logs. When SageTV tries to use one of the premium channels it comes back with "No Signal". But looking at the HDHR config gui it shows that there is definitely something happening, just like when using the HDHR app. I'm not sure what to do next.

[KryptoNyte]

You might first try completely disabling the Windows Firewall service, temporarily, reboot, and see if that clears it up.

If not, start posting your OpenDCT logs.

[thomaszoo]

No luck there. I did notice that the "Network Target" in the HDHR Config Gui has the correct IP address. The port number seems to change depending on the channel requested.

The OpenDCT log is attached.

Thanks for the help.

[KryptoNyte]

It looks like you have the 64 bit version of OpenDCT installed. If you still have Java 32bit installed, maybe try uninstalling OpenDCT, and then downloading and installing the 32bit version of OpenDCT, reconfigure from scratch and see how that goes (leaving your machine clear of any 64 bit versions of OpenDCT and Java).

I seem to recall the Windows 10 Firewall service being called something a bit different ... Windows Defender Firewall. Be sure that SERVICE is fully disabled, and then a reboot, until you get this working.