Add ability to specify (fixed) IP address of HDHR appliance(s) to better integrate with VPNs

[Mysterylectricity]

There is considerable interest in viewing HDHR streams remotely., IE from a different subnet One of the barriers to doing this lies in the Time-To-Live value of 3, which SD places in their IP headers.

The usual workaround is to use a VPN. Out-of-the-box, though, VPNs do not pass discovery traffic.

I suggest incorporating functionality that allows a user to specify the HDHR IP address(es) in lieu of or in addition to using broadcasts directly, or indirectly through hdhomerun.com. Presumably allowing the user to specify a public IP address directly or indirectly, IE via DDNS referral, would be of limited utility to the vast majority of users due to the aforementioned TTL issue, but whether this should be flagged with a warning or result in a fatal error is debatable.

Sadly, my programming skills, if any, are limited to BASIC(!) and assembly language. The best I could expect to do is zing the code with a hard value, after considerable effort to minimally understand its syntax.

A wider discussion relating to the experiences that led to this request follows.

Most of the utilities I've examined use local broadcasts or make a call to hdhomerun.com (which presumably uses local broadcasts behind the scenes). I've tried some of these from a site/subnet remote from the HDHR and they don't work. Admittedly I have not tested them from a system at the HDHR site to rule out the possibility there is an unrelated issue causing it to fail in my environment: but I can't imagine how it possibly could work, especially given that each of my subnets has a different numbering scheme (albeit not well rationalized).

Floundering for a way to make reasonably convenient use of the remote HDHR, I came across some simple Python code designed to create an m3u playlist, presumably by requesting the Channel Lineup page and parsing it. By redirecting the output to a file with an m3u extension, I finally get a one-click (ie by clicking on the m3u file, which launches VLC in my case) or no-click (loading VLC on login) front end of sorts for my users.

At least two versions of this code exist.

The most recent version makes a request to ipv4-api.hdhomerun.com/discover, which may itself be deprecated in favor of my.hdhomerun.com. This would seem to point to another common issue, the need to re-write dependent code when a vendor changes their scheme or closes up shop entirely.

But I digress. The point is this later version didn't work for me.

The earlier version incorporated a fixed IP address. Having previously established that I could access the HDHR landing page at the remote site by deploying WireGuard VPN, I ran the fixed IP address Python script on my local system, referring to the HDHomeRun solely by its private IP (the VPN does the heavy lifting, using DDNS and manipulating the routing table) and BOOM it just worked. I can't over emphasize how easy it was to configure WireGuard for this, simply by instructing it to route all traffic destined for the remote subnet through the VPN with a single line in WG's configuration file which was largely needed anyway. My sites are all on different subnets, and given my limited understanding of such matters, getting a VPN to "bridge" between sites would involve renumbering my hosts, considerable VPN-foo, or both.

Specifying a fixed IP was the key to this relative simplicity. True, as far as I know, there is no way to assign a truly fixed IP to an HDHR device. But, of course, making entries in the associated routers' IP reservation tables is trivial.

Convinced?

If my suggestion gains traction here I may well advocate for it in other development forums orbiting the SiliconDust solar system and spread the word among the largely frustrated remote viewing populace that things just got a whole lot easier.

Thank you for considering it. First post on GIT, apologies in advance if it's mis-flagged.

[Mysterylectricity]

To clarify, specifying a public IP would seem of little general value: it's the ability to specify a private IP routed by the VPN that's most useful, and least dependent on a more complicated VPN configuration that may be implementation-dependent.

[djp952]

Yeah, I'm OK with this, but I'll probably make it a bit hard to actually implement. I've been "away" from this code for far too long at this point (working on other stuff), but I am convinced that having something like a manually created file along the lines of a "devices.txt" file that the addon could prefer over discovery would be good for your proposed scenario(s).

The addon has been stagnant for many months at this point, and I'll probably need to do a refresh first, but yeah, OK, I'll give you a way to specifically define your HDHR devices and bypass any and all discovery.

[djp952]

Are you good with needing to define undiscoverable devices in either/or JSPON or XML format, or should this just end up as a list of IP Addresses that the addon needs to figure out what to do with?

[djp952]

I've moved this project into a "maintenance mode" since I no longer want to work with Kodi. I still need to use it too, so I am paying a bit of attention to this, but I did have to draw a line on any "new features" or anything that might require "an argument with Kodi".

I sincerely hope Team Kodi picks up the functionality they like to put in their pvr.hdhomerun addon, but I have not seen any movement in that direction to date. I hope this works for you as well as it can for as long as it can, but I'm effectively "checked out".