HDHomeRun, Detect My Devices, bug using wrong hostname/port

[rocky4546 1]

Before I go on, don't laugh.  I am working on getting a complete hdhomerun device stood up for locast.  I know there are lots of them out there, but I found an issue that really needs to be fixed with the "Detect My Devices".  Here is the scenario.  Emby sends out a multicast packet requesting all hdhomerun devices to respond.  All respond including my locast device.  Emby is then suppose to take "HDHOMERUN_TAG_BASE_URL" id 0x2A from the packet received containing the URL and emby will query for /discovery.json.  Instead emby takes the hostname from the IP connection (which happens to be the same) and port 80 (always) instead of what is provided.  Although, it is normal for HDHomerun devices to run on port 80, that port is almost always being used, so the locast device is on a separate port (6077).  For now, I have added a re-direct on my port 80 web server for /discovery.json to have emby work; however, this is not a viable solution for everyone.  It would be great if the code would be fixed to use the correct URL.

[rocky4546 1]

To get into the weeds, the issue is in HdHomerunHost.cs located at /Emby.Server.Implementations/LiveTv/TunerHosts/HdHomerun.  The issue is found at line 700 and 705 where the device_id uses the UDP host instead of the data within the packet received.  The format of the packet looks like the following:

 msg_type: '0003'  (HDHOMERUN_TYPE_DISCOVER_RPY)
 msg_len:  '006b'
 header: '010400000001'
 device_id: '020401010101'
 device_auth: '2b18' + '[passcode-24chars]'
 base_url: '2a19' + 'http://xxx.xxx.xxx.xxx:1234'
 tuner_count: '100102'
 lineup_url: '2725' + 'http://xxx.xxx.xxx.xxx:1234/lineup.json'
 crc: 4 bytes

The base_url of type 2a is what you should use for info.Url instead of http://[UDP IP address]:80/ as seen on line 705.  It looks like the software does not extract any of the info in the packet and instead connects to discover.json for the lineup_url, as well.  If you need additional information, I would be happy to provide.

[Carlo 4330]

Hi, Couple of things.

HDHomeRuns use "discover.json" without a "y" which was likely just a typo.

I've never seen a HDHomeRun use any port other than 80.

The rest of what you said is very true.

@LukeCan we get this trivial change made?  It's come up a few times with different proxies trying to emulate HDHRs

[rocky4546 1]

Yes, it is /discover.json.  Also, the app also is going to also work with tvheadend using its dvb interface. This interface uses the same discovery as emby (well almost).  I have the discovery and getset commands working, so far.  When you have an update, I will be happy to run a test.  My device testing uses hdhomerun_config which sends 65001 commands to the device under test.

[rocky4546 1]

I have finished the updates and only the host/port was an issue. On Linux, I put a redirect on the Apache 2 server to the 6077 port.  On windows and in a Docker vm, port 80 would not be an issue.  Just FYI... the version I have works with the free and subscription versions of Locast instead of only the subscription version.  The TVHeadend interface using the UDP port has not been successful.  This is because the IPTV restream of the antenna ATSC data causes the ATSC packets to be updated to empty shells.  The end result is the PCR_PID and TSID are the same for all stations and channels which would not be valid information.  However, the TCP interface to video streaming works fine.

[Luke 37054]

Hi, I'll be looking into this and making the changes to update to it. Thanks for reporting this.

[wouterdebie 5]

@rocky4546Is your project open source? I'm the author of locast2dvr and I'm working on auto discovery. I ran into the same issues you had, but would love to see how you solve things.

[rocky4546 1]

Hi wouterdebie, I see you are the author for locast2dvr.  Along with fHDHR, there seems to be quite a few of us working on the solution daily.  My project is at

https://github.com/rocky4546/tvheadend-locast

and is wrapped around on locast2plex.  This way I do not have to manage some of the general interfaces and I am getting synergy from his issue list.

[wouterdebie 5]

@rocky4546cool stuff! I took some stuff from locast2plex, but rewrote it, since I didn't find the code very consistent, documented and workable. I've also been chatting with the guy who works on fHDHR and we have been exchanging some ideas. He focuses on having a full fledged interface between media servers and all sorts of backends, while I focus only on locast.

[rocky4546 1]

FYI @Luke I have been looking at Plex HDHR I/F and they have similar issues using port 80 instead of the port provided.  They use SSDP instead of port 65001, but the issue is similar.

[Dan_Austin 62]

@Luke In case this is going to be addressed with the new LiveTV release and not patched in the current, I have a small feature request/suggestion to build on this.

The fHDHR proxy at the moment supports around 16 sources of media.  It does not require one proxy instance per source, instead it uses a unique URL per source that is presented to the media server/client.
The base url for Ceton:  http://<IP>:<port>/hdhr/ceton
The base url for Locast:  http://<IP>:<port>/hdhr/locast

During a discovery event it returns one packet per source which could(should?) be interpreted as a unique tuner.  Manually creating tuners using those base urls works, and is not really a difficult process, but once Emby actually uses the presented <ip>:<port>, it would be super sweet if it used the whole base url to determine if a tuner was unique, and not just the IP.