HDHomeRun IP address issues in iOS app

Hi,

Sorry for the long post!

Due to a poor connection using Powerline adapters I've had to move my Channels DVR Server (QNAP) and my HDHomeRun CONNECT QUATRO to an Ethernet hub connected to a wireless bridge, as I can't get a reliable Ethernet port behind my TV. This has improved the connection between the QNAP and HDHomeRun considerably, and the devices are also now getting my full fibre broadband internet bandwidth of 166MB up and down, where previously they were getting less than 10MB.

The wireless bridge is passing all traffic to my main router and the router is providing DHCP to all devices behind the wireless bridge if they are not static.

The IP address of the QNAP is static but currently the HDHomeRun is automatic so getting its IP via DHCP. This was the same when I was using Plex Live TV, although of course back then they were using the Powerline adaptors for their connection to my main router.

Therefore all devices on my network including this devices behind the wireless bridge are using the same subnet of 192.168.2.X with the same gateway of 192.168.2.1 which is my main router.

THE PROBLEM:

The web admin of Channels DVR Server scans the network and finds the HDHomeRun on the correct IP address and is working perfectly when watching Live TV via the web browser.

However when watching Live TV using the Channels iOS app it often fails to find a tuner with the error in the attached screenshot.

When checking Settings > Manage Sources in the iOS app it reports that the IP address of the HDHomeRun is the IP address of the wireless bridge, not the IP address of the HDHomeRun.

Sometimes if I wait a minute or so and try watching Live TV again on the iOS app, it will start working fine, but Settings > Manage Sources in the iOS app still reports the IP address of the HDHomeRun is the IP address of the wireless bridge, not the IP address of the HDHomeRun.

It seems because Channels DVR Server is on the same wireless bridge as the HDHomeRun it is registering the correct IP address of the HDHomeRun, but the iOS app on the other side of the wireless bridge, ie. on my main router side, is scanning the network, finding my HDHomeRun, but incorrectly registering the IP address of the HDHomeRun as being the IP address of the wireless bridge, even though Live TV on the iOS app is working after a minute or so of the iOS app being open. The iOS app never shows the correct IP address of my HDHomeRun even when Live TV is working.

I assume the iOS app does not get the IP address of the HDHomeRun from the already configured Channels DVR Server, instead the app does its own independent scan of the network and uses what it finds?

Either way my HDHomeRun is working just fine from both sides of the wireless bridge when using its correct IP address, including the native HDHomeRun app. I cannot however connect to the HDHomeRun using the IP address of the wireless bridge, which is to be expected of course.

This all makes me think that the Channels iOS app may be using a combination of configuration details from its own scan of the network and the details from the Channels DVR Server to get details of the HDHomeRun, and is perhaps first trying the wrong IP address the iOS app found, and then failing over and using the correct IP address the Channels DVR Server found?

As a further complication I use Tailscale VPN when outside my home (Tailscale installed on the Qnap and my iOS device) and Live TV in the Channels iOS app works perfectly when connecting to the Tailscale address outside my home, I never get tuner unavailable errors, and when I check Settings > Manage Sources in the iOS app it reports the HDHomeRun as "via DVR" rather than an IP address.

So rather bizarrely the Channels iOS app is currently more reliable if I connect to it outside my home than if I connect to it inside my home.

Any advice on this issue would be appreciated.

Many thanks,
Richard

Its likely that your bridge is performing NAT and you cannot connect directly to the HDHR from a client inside your network. The channels server can that's why the web client works and it also works outside your network. Turn on tuner sharing for your client and it will work inside your network. Longer term disable NAT on your bridge.

2 Likes

I'm wondering about the same thing. To me it sounds like the device you are calling a bridge is in fact a router. If it has two IP addresses it's a router.

If we are correct, then the easy way to go is to manually enter the IP of the Channels DVR on our clients treating them as if they are outside your network and in this case tuner sharing may not work yet the server can send the client the live stream and also all recorded content.

1 Like

Hi Slampman and Morris_Altman,

Thank you both for your quick replies. Just after I posted this I did some digging and discovered two settings, the one you kindly suggested [Tuner Sharing] and also [Sources]. These fixed my issues.

I found that [Tuner Sharing] fixed my issue even though the HDHomeRun still appeared in the iOS app with the wrong IP address, but setting [Sources] as well now lists the HDHomeRun in the iOS app with the correct IP address, so both issues resolved.

However regarding your suggestion of disabling NAT, I can confirm my wireless bridge is actually setup as a wireless extender with no NAT or DCHP. My main router is issuing IP addresses to all devices on my network both sides of the extender (unless they have a static IP address of course), so the HDHomeRun is working fine using the IP address that my main router has given it, and all devices on both sides of the extender are on one subnet (192.168.2.X).

Channels DVR clients on the the main router side of the extender are successfully discovering the HDHomeRun on the other side of the extender, but are listing it in the client as having the same IP address as the extender (192.168.2.26) and not the correct IP address of the HDHomeRun (192.168.2.40).

From either side of the extender, I can't connect to the HDHomeRun using the IP address of the extender (192.168.2.26), I can only connect to it using the IP address of the HDHomeRun (192.168.2.40), which is of course expected and correct behaviour.

Before I enabled Tuner Sharing my Channels DVR clients randomly worked eventually, even though they always listed the HDHomeRun as having the wrong IP address. I'm not sure how that could be possible, so I assume at some point the client gives up with the wrong IP address it discovered and uses the correct IP address the server discovered.

My two QNAP servers are on the same side of the wireless extender with the HDHomeRun, and all my QNAP apps successfully scan my network on both sides of the repeater and discover the QNAP servers with their correct IP addresses, so it does seem to be a difference with how the Channels DVR app does its scan and discovery, returning the wrong IP address for some reason.

As I have no NAT going on to disable, I will try setting the HDHomeRun to a static IP address and see if that solves the problem with Tuner Sharing switched back off. If not I'll just leave Tuner Sharing switched on and forget about it, as it is working perfectly inside and outside my network now I've done that, and everything else on my network is working fine too.

Thanks again for your help.

I'm glad you got things working. It sounds like the repeater is placing the incorrect MAC address on multicast and/or broadcast packets.

Channels DVR uses a protocol called Bonjour, also known as zero-configuration networking. Possibly your repeater is not handling this correctly. There might be a firmware update for it.

1 Like

Thanks Morris, appreciate the pointers re how my repeater may be handling MAC addresses and Bonjour, I’ll definitely check that out. In the meantime it’s great I can start enjoying Channels DVR fully again :slight_smile: