[Fuzzard]

Hi,

I've been doing some dev on the pvr.hdhomerun plugin, and i see requests for using the older models of SD's devices. Unfortuantely, i only have a newer gen device, so testing for any work ive been doing can only be done against that.

Im looking for someone who could provide some information/output from an older generation device (HDHR3-US/EU or older)
If you would be interested in assisting me with this, can you reply here and ill get back to you with what im looking for at this time.

[MatthewLundberg]

I have an HDHR3-US here.  There are a few differences in how you handle the device.

You must retrieve the lineup URL from the device.  You can get that by accessing "discover.json" on the device.  That also gives you the tuner count and a legacy flag.  See https://github.com/MatthewLundberg/pvr.h.../Tuner.cpp lines 104-134.  You can also retrieve the lineup URL for modern devices this way (rather than building it from a pattern).  Retrieving the guide is identical to newer boxes; that always comes from SD.

Of course the biggest difference is the lack of DLNA (TCP) support.  You must open a local UDP port, then program the tuner to send to that port on your machine.  This pretty much rules out passing a URL to Kodi.  It is possible to pass a URL which Kodi can read, but you need to open the port before you start the tuner sending.  Unless you configure the tuner to keep sending in the face of UDP port unreachable ICMP messages, but if you do that you have the potential that the tuner will never be released.

What else are you looking for?

[Fuzzard]

Thanks Matthew. The discover.json was one of the outputs i was wanting to look at on a legacy device. My understanding is that SD setup discover.json/xml on all devices with a firmware update a while ago, so was wanting to see the difference, if any, with that between an older and a newer device. I figured it would be a similar process for device discovery and lineup. I was wanting to confirm device discovery using libhdhomerun using hdhomerun_discover_find_devices_custom_v2 to see if it lists all found devices (new and old) into the struct hdhomerun_discover_device_t and whether its a just the variable is_legacy is set to true.

Im not too worried about the udp side of things. Ive got a branch up and running (https://github.com/fuzzard/pvr.hdhomerun...ivestream2) that uses libhdhomerun to lock/release and set target/vchannel. You can then send a local udp url (udp://127.0.0.1:5000) to getchanelstreamproperties to get the feed. what ive come to realise, is the need to implement open/read/closelivestream to be able to handle channel changes appropriately. the *streamproperties functions dont play nice with udp sources that change without a url change. Ive got an old branch that implemented those livestream functions, so that shouldnt be a problem.

The last thing i wanted to check was how the guides work on the old devices. Thats a complete unknown to me. Havent really seen or read anything relating to that on older devices. I thought i had read that it doesnt use the my.hdhomerun.com site like the newer devices, but wasnt completely sure.

edit: just read you answered my guide questions, haha. teach me to not read everything properly first.

[Fuzzard]

Another question is whether https://my.hdhomerun.com/discover returns legacy devices, and whether there is anything on that different to newer devices.

Long term i think thats a terrible way to discover devices, but i like to know all the ins and outs

[MatthewLundberg]

Im not too worried about the udp side of things. Ive got a branch up and running (https://github.com/fuzzard/pvr.hdhomerun...ivestream2) that uses libhdhomerun to lock/release and set target/vchannel. You can then send a local udp url (udp://127.0.0.1:5000) to getchanelstreamproperties to get the feed. what ive come to realise, is the need to implement open/read/closelivestream to be able to handle channel changes appropriately. the *streamproperties functions dont play nice with udp sources that change without a url change. Ive got an old branch that implemented those livestream functions, so that shouldnt be a problem.

If you have the tuner accept ICMP UDP port unreachable messages, you must first open the local port, then start sending.  That will require a separate thread (or e.g. a future) to get the timing correct.

If you take the easy way out and have the tuner ignore ICMP UDP port unreachable messages, you can lock out the tuner (e.g. if Kodi crashes).

Reading the stream directly rather than passing a URL is easier than it sounds, even for the DLNA traffic.

[MatthewLundberg]

Another question is whether https://my.hdhomerun.com/discover returns legacy devices, and whether there is anything on that different to newer devices.

Not sure.  I'm using the discovery API (like the original), then connecting to each tuner to get its discover data directly.

[MatthewLundberg]

Another question is whether https://my.hdhomerun.com/discover returns legacy devices, and whether there is anything on that different to newer devices.

Not sure.  I'm using the discovery API (like the original), then connecting to each tuner to get its discover data directly.     

I should have just clicked on the link.  It does return legacy devices.  In the return there is the value "Legacy": 1.  The lineup URL is missing from the legacy device, present on the modern devices:

Code:

{
"DeviceID": "10389E40",
"LocalIP": "192.168.1.50",
"BaseURL": "http://192.168.1.50:80",
"DiscoverURL": "http://192.168.1.50:80/discover.json",
"Legacy": 1
},
{
"DeviceID": "10490497",
"LocalIP": "192.168.1.52",
"BaseURL": "http://192.168.1.52:80",
"DiscoverURL": "http://192.168.1.52:80/discover.json",
"LineupURL": "http://192.168.1.52:80/lineup.json"
},