I added a remote tuner to the list of sources. It is about 100ms away. It works perfectly fine when tuner sharing is off. However with tuner sharing on, the DVR is getting nervous and starts complaining about a problem with the signal:
Here is a line from the log:
Statistics for ch5.1 KXAS-DT: ss=100% snq=99%-100% seq=100% bps=13413302,3265184-16334944 pps=608,243-684 neterr=96%
It might not be the only place where this problem manifests itself.
Notice: Total Cache (28.8s video + 0.0s audio)
neterr=90% It's not Channels, once again it's you.
Did you miss the part where it says - viewing, with tuner sharing set to off, works fine?
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.
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).
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 
Remove the different state tuner
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
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 
@Edwin_Perez
Apology accepted...
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.
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.
