Unable to watch with tuner sharing on neterr=96%

Well Sparky, with tuner sharing off the client pulls direct from the HDHR. With sharing on you pull from the server that pulls from the HDHR. Tells me that you have a network problem between your server and the HDHR.

2 Likes

Why don't you just go back to whatever you were doing and stop trying to play a network expert on a public forum?

You seem hellbent on shoving square pegs through round holes and then whinge that the hole drillers are doing it wrong.

As to your topic, yeah, you're going to have a bad time with network errors happening to %96 of the packets.

I doubt you'll get any response from the developers though, you've told them all that you know better than they do so why would they even bother to try helping?

Thank you for polluting the thread. Back to the issue at hand.

If somebody would like to add my HDHR to their DVR to try it let me know. I made it available on a public IP - 199.102.54.167 It is discoverable but playback/signal status is IP restricted so let me know your IP.

That is not how it works even with tuner sharing the stream does not go through the server ... The request for a tuner goes to the server that is all ... not the stream.

OOPS guess I am wrong it does go through the dvr just does not write to disk.

With Tuner Sharing enabled, the Client connects to the DVR, which connects to the HDHomeRun and streams the data from the HDHomeRun to the Client via the DVR by holding an in-memory buffer of the recent data, sending a copy to each connected Client.

If there are any neterr= statistics showing errors above 0%, it means that the HDHomeRun filled its internal (very small) network buffer and was forced to drop video data when new video data come in. The reason why this would happen is that the receiving end was unable to read the data from the network connection fast enough. This would either be because the network connection is unstable (generally due to being on WiFi, but it could also be a bad ethernet cable, etc.) or because of issues on the receiver of the connection (in the case of the DVR, either due to the computer being overloaded, computer misconfigurations, or hardware failure).

5 Likes

Ok, aside from the fact neterr=98% is clearly bogus the problem only happens when watching live. Recordings work fine.

The extra problem is also tuner selection - the DVR server will happily select a tuner in a different state to record just because it has the same channel number available :rofl:

Remove the different state tuner :rofl:

Then report it to SiliconDust, that information is pulled straight from the HDHR box itself.

https://info.hdhomerun.com/info/hdhomerun_config#checking_the_signal_strength

Screenshot 2022-04-16 143758

1 Like

I created a local proxy with the same IP locally so the latency is sub millisecond instead of 100ms.
No issues now.
Keep your HDHomeRun devices in the same zip code :wink: @Edwin_Perez

Apology accepted...

do not flatter yourself @eric , fix the problem :innocent:

I’ve read the thread twice and I can’t understand what you’re talking about.

Everything I’ve read sounds like an issue with your network or server.

1 Like

A Strength/quality/symbol of 100% is always a little suspect. Is there any chance attenuating the signal changes this?

Just throwing this out there for consideration.
Have you considered the IP packet TTL and hops in the route?
I know the HDHR tuners set the intial value very low, like 2 or 3?

Wait. If you try to use an HDHomeRun that is not on the local LAN, you’re gonna have a bad time. Use our m3u support for bringing in remote sources.

HDHR sets TTL to 3 to avoid headaches related to supporting remote access. Problem solved. No remote access possible.
That's why a proxy is needed to work around this problem.

100ms latency to the HDHR proxy kills the ability of live viewing when tuner sharing is on. I know it is hard to believe but there must be a bug in your code :wink:
The offer to use my HDHR device remotely still stands if you would like reproduce the issue.

Let me state this clearly: We do not support emulated HDHomeRun devices and do not support HDHomeRun devices that are not on the same LAN as the DVR.

What does it mean to not support this?

It means we will not assist customers with diagnosing problems or investigate fixes required to make the configuration work.

Why won't you help me?

We have invested a large amount of time and history into having a stable platform working with the constraints of the hardware HDHomeRun devices.

We decided that a better solution for us and for our customers is to bringing in other video sources is via our Custom M3U playlist feature.

That's nice however I am clearly hitting a bug in your code. If you do not close this thread I will update it once you fix it while working on some other problem. We've been through this before. :wink: