HDHRGuide for Windows

[nobody]

You can add both <new /> and <previously-shown> as they are in the XML from SiliconDust, according to this post on the Silicondust forums

[mvallevand]

That might be the XMLTV from the subscription DVR as sent by Silicondust it is much richer, and HDHRGuide passes it directly.

I am concerned about adding previously shown just because it is a past date as I mentioned that is a not true, but I will add new. Maybe a future release of NextPVR can add an XMLTVAssumeNew setting that works like DVBAsssumeNew

Martin

[sub]

I'm assuming they're getting their data from GraceNote, so might just be a case of adding their xmltv header to the list of those that assume false unless told it's new.

[mvallevand]

It does use Gracenote but the free data isn't as rich as the DVR data. The following is new on SD but what I need to do is match the midnight date 1755388800 and mark new. Where this fails is when the same show repeats during the day, but as long as the NextPVR uses the S/E to get a unique ID it should be fine.

Code:

.
            {
                "StartTime": 1755475200,
                "EndTime": 1755478800,
                "Title": "Big Brother",
                "EpisodeNumber": "S27E19",
                "Synopsis": "The head of household nominates three fellow houseguests for possible eviction.",
                "OriginalAirdate": 1755388800,
                "SeriesID": "C188043EN0T5A",
                "ImageURL": "https://img.hdhomerun.com/titles/C188043EN0T5A.jpg"
            },

Martin

[timq]

I'm just starting to explore this integration today, thanks for all of this work, mvallevand!

I found a simple resolution to one problem that I didn't see mentioned here. My first runs gave this error:
Unhandled exception. System.IO.FileLoadException: Could not load file or assembly 'System.Runtime, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)
File name: 'System.Runtime, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

After a couple of unnecessary checks on my .Net installed versions, I saw discussion here about runtime DLLs in the NextPVR folder and updated to the latest NextPVR. That fixes the assembly version loading error and seems to get everything launched. I'm lazy by design in updating software, but thought my previous NextPVR was a relatively recent one. Anyway, I hope this post helps anyone else who runs into this.

To another error naturally, but there are some clues that it is my local network setup and I'll see if I can get that sorted on my own.

[timq]

OK, I am stuck now, but it looks like I may have a problem accessing api.hdhomerun.com and HDHRGuid.exe is blocked by that. Its error includes:
Checking https://ipv4-api.hdhomerun.com/discover
Checking https://ipv6-api.hdhomerun.com/discover
https://api.hdhomerun.com/api/xmltv?DeviceAuth=[deviceAuth]
Unhandled exception. System.Net.Http.HttpRequestException: The requested name is valid, but no data of the requested type was found. (ipv6-api.hdhomerun.com:443)
---> System.Net.Sockets.SocketException (11004): The requested name is valid, but no data of the requested type was found.

I'm able to directly access my discover.json and the deviceAuth value is correct. When I directly access /api/lineup with that deviceauth I get a valid reply with correct data. But for /api/xmltv, I get a 403. Is there something about the /discover calls that needs to precede /xmltv? That would mean my manual tests aren't expected to work.

The native HDHomeRun app does seem to be showing valid show names and times. I'm a little rusty, but probably have wireshark or equivalent and could snoop on that traffic if these symptoms don't generate any other suggestions.

I'm not subscribed to SiliconDust currently, was hoping to try the free 1 day level before deciding on subscribing to it or Schedules Direct.

[mvallevand]

Are you running the 7 day guide version from post #1? That should be trapping that ipv6 message when ipv6 is not available.

Martin

[timq]

I was not running the 7 day version, the other one from post #1. I just switched and now the output includes the same 403 I see when I just enter the URLs in my browser.
Checking https://ipv4-api.hdhomerun.com/discover
Checking https://ipv6-api.hdhomerun.com/discover
The requested name is valid, but no data of the requested type was found. (ipv6-api.hdhomerun.com:443)
https://api.hdhomerun.com/api/xmltv?DeviceAuth=[deviceAuth]
403 Forbidden

I do have a network snoop and will set up postman to explore this more, starting with seeing what the HDHomeRun app does to get program info. Maybe it is not using /api/xmltv at all?

It may be a couple days before I get around to it, I'll check back to see if you have any suggestions for where to look. Thanks again.

[mvallevand]

The 403 is correct, it first attempts to get thteir PVR guide.

Martin

[timq]

I just deleted a bunch of observations from network traffic and manual tests, demonstrating how terribly clever I am. I was able to manually fetch program data based on mimicking HDHRGuide urls, and it looked like it was getting the data too. FINALLY, I took my first look for my chosen output file. It's there and looks good.

So was I just spooked by normal ipv6 failures since it's not enabled on my router? But then what's going on with /api/xmltv? That's where I see a 403.