Unofficial Kodi HDHomeRun DVR PVR Client

[djp952]

NOTE: As a rule, I do not accept donations. I deeply appreciate the offer, but it's reward enough for me to have so many people getting use out of the project. I've got a day job; this is a hobby

Just upgraded my OSMC after months of avoiding it as it usually breaks stuff. All PVRs broke, none able to be installed on Kodi 18, but thanks to your awesome work, I was able to get HDHR working again. Are you sure you don't take donations?!?! Bitcoin? Monero? Litecoin? ZCash???

Kind words are my currency. Saying "awesome" is payment enough -- you are quite welcome! Besides, this way I still have "you get what you pay for" in my back pocket as an excuse for whatever horrible defect I accidentally introduce next

[djp952]

Fix bug in database layer that could cause unhandled exceptions processing NULL column values (ddejager)
This resolves a few really dumb mistakes on my part. If a PVR database query returns a single row with just a NULL value in it, there were a handful of places I was taking that NULL result and attempting to assign it to an std::string object instance. SQLite converts NULL to a null pointer if you ask to coalesce a value into a string, and std::string::assign() doesn't accept null pointers. So far this will manifest if there are no tuners detected on your local network, but I applied the fix for it across the entire database layer.

Thanks you! Your beta version no longer crashes on the system where 2.0.1 did crash. Any idea why it would only crash on some systems? My system (no crash) has only about 13 direct broadcast channels. The system where it was crashing has about 80 cable channels.

The defect in this case would mainly affect the new function to retrieve the device authorization strings. A SQLite function I used, 'group_concat' unexpectedly returns NULL instead of just not returning the row, which tripped me up. There were a handful of other instances of the code defect, but they should never get triggered because the query would just return no rows as expected.

In v2 when I rejiggered this stuff, I added this function to better support users with no DVR subscription. I check the backend services against each tuner to see if any are authorized. If none are, and you try to do something with Timers (Recording Rules), I can pop up that message that you need a DVR subscription. So a lack of detected tuners OR a lack of tuners with a DVR authorization string should have triggered it at one point or another. You hit the nail on the head for me when you said "no tuners were detected" - that got me into my usual SWAG (Scientific Wild-A** Guess) mode, and it worked out!

[usafle]

So I just applied the v2.0.2 BETA 1 (May 4, 2019) on my LibreELEC device since I was having issues watching LiveTV, lately had an error that said "Live Stream creation service failed" (I honestly don't recall the exact error message). So now with the v2.0.2 BETA 1 (May 4, 2019), LiveTV works once again. However, I can no longer "See" my DVR recordings. When I go into the Client Specific settings on the Kodi PVR settings and list discovered devices, I get the LiveTV Tuner but the Record engine shows up as "Unknown 000000"

[djp952]

So I just applied the v2.0.2 BETA 1 (May 4, 2019) on my LibreELEC device since I was having issues watching LiveTV, lately had an error that said "Live Stream creation service failed" (I honestly don't recall the exact error message). So now with the v2.0.2 BETA 1 (May 4, 2019), LiveTV works once again. However, I can no longer "See" my DVR recordings. When I go into the Client Specific settings on the Kodi PVR settings and list discovered devices, I get the LiveTV Tuner but the Record engine shows up as "Unknown 000000"

Do you have the setting "Use network broadcast for device discovery" enabled in the PVR settings?

During broadcast discovery, I default the device ID for a storage engine to "00000000" (8 zeros, not 6) if it cannot be determined from the URL provided in the discovery data. It looks like nothing would set the device ID to "Unknown" except a call to libhdhomerun on Windows exclusively that tried to use the system registry to get the device ID. Knowing the value of that PVR setting would help to understand where the "Unknown" part is coming from.

In general, this seems like a problem with communicating with the RECORD engine. The banner message "Live stream creation failed" happens for any error that results in not being able to successfully start a Live TV stream. The underlying error that caused that banner message to appear will be in the Kodi log. Would it be possible to get that?

Also, do you see your RECORD engine and Device ID if you navigate to this URL from a web browser: http://ipv4-api.hdhomerun.com/discover ? If it's missing or says "Unknown" or "000000" in the data, something is definitely going screwy with the RECORD engine.

[usafle]

Do you have the setting "Use network broadcast for device discovery" enabled in the PVR settings?

Just Checked and yes. I didn't change anything in the settings from before until now. But I double checked just to make sure the S.O. wasn't in there messing with stuff when I wasn't looking.

Also, do you see your RECORD engine and Device ID if you navigate to this URL from a web browser: http://ipv4-api.hdhomerun.com/discover ? If it's missing or says "Unknown" or "000000" in the data, something is definitely going screwy with the RECORD engine.

This is the output from the url you linked. Not sure if any of this should be redacted or not? It all looks like local LAN IP addresses so I'm thinking it should be "safe" to post here?

Code: Select all

"DeviceID": "132527(Removed last two just in case)",
        "LocalIP": "192.168.86.31",
        "ConditionalAccess": 1,
        "TuningResolver": 1,
        "BaseURL": "http://192.168.86.31:80",
        "DiscoverURL": "http://192.168.86.31:80/discover.json",
        "LineupURL": "http://192.168.86.31:80/lineup.json"
    },
    {
        "StorageID": "f46fa8c6-d8bd-2b3e-df3d-14092fd(Removed some letters/numbers just in case)",
        "LocalIP": "192.168.86.102:65002",
        "BaseURL": "http://192.168.86.102:65002",
        "DiscoverURL": "http://192.168.86.102:65002/discover.json",
        "StorageURL": "http://192.168.86.102:65002/recorded_files.json"

[djp952]

I do the same thing (redact), but I don't think there is any danger in folks knowing what your HDHomeRun device local IPs are Mine is 192.168.0.160, .161. and .220. Let's see if anyone can hack me - lol (that is NOT a challenge, folks! Please don't).

Everything looks fine to me. Maybe try switching to HTTP discovery? I don't see anything specifically wrong with broadcast here, but my sample size is limited to just my network. I tried Android, Windows, and Linux and didn't have a problem.

Have you tried the official SiliconDust app on Windows (if available)? It uses broadcast discovery by default, I would think you should see the same weird results. If that works fine I may have to ask SD what I may be doing wrong in the libhdhomerun code. Perfectly willing to do that, of course.

All I have for you right now would be to switch back to HTTP by disabling that setting. Those results looked fine and I would expect to resolve the issue.

edit: It just so happens that I rebooted my RECORD engine device, and I started getting "Live Stream Creation Failed". It was because the port number changed. Restarting Kodi or forcing a discovery would resolve that. If broadcast discovery is on the fritz, that would cause the same thing. This sounds like a "Known Issue" to document on the wiki. I could fix that by forcing a discovery on such an error (and may do exactly that).

[djp952]

You know I was shooting for May 4th (Star Wars Day), but you know, things happen ...

Version 2.0.2 (2019.05.08)

• Update SQLite database engine to version 3.28.0
• Prevent multiple Kodi threads from simultaneously requesting EPG data
• Prevent individually malformed EPG data request results from aborting all remaining requests
• Fix bug that allowed extraneous EPG entries to be transferred to Kodi
• Fix bug that prevented successfully setting channel visibility flags
• Fix bug in database layer that could cause unhandled exceptions processing NULL column values

Downloads:
Kodi 16 "Jarvis" : https://github.com/djp952/pvr.hdhomerun ... odi-Jarvis
Kodi 17 "Krypton" : https://github.com/djp952/pvr.hdhomerun ... di-Krypton
Kodi 18 "Leia" : https://github.com/djp952/pvr.hdhomerun ... -Kodi-Leia

Release History:
https://github.com/djp952/pvr.hdhomerun ... se-History

Most of this has already been discussed or was in the "BETA 1" release, so I'm only going to touch on one line item here. Let me know if you want additional detail on any other line items.

Prevent individually malformed EPG data request results from aborting all remaining requests
This is a stop-gap measure I put in place to give me some time on a greater set of ambitions. I found that the dreaded "Malformed JSON" still rears it's ugly head from time to time when accessing EPG data. This change is intended to not allow multiple "Malformed JSON" errors from completely aborting the EPG data load, but does not specifically get me any closer to the root cause. I added a reference to "rapidjson" (http://rapidjson.org/) and pass each individual EPG request result through it to check for parsing errors. For this release, if a problem is found, that block of data will just be ignored. The 'greater set of ambitions' would be to re-queue these failed requests for a second try, as well as expand that logic to all of the backend data HTTP requests.

While I need more time to burn down the backlog (see Post #3 of this thread), I wanted to make sure that the bug fixes for this release were disseminated as soon as I was able to be confident in them. Having Kodi crash for any reason is both annoying and difficult to work around.

Thank you all as always ... feedback, no matter how positive or negative, is always welcome.

PS - The Leia auto-update repository for Windows/Android/OSX has been updated, but it may take upwards of 48 hours for Kodi to actually go check for a newer version and install it.

[usafle]

Everything looks fine to me. Maybe try switching to HTTP discovery? I don't see anything specifically wrong with broadcast here, but my sample size is limited to just my network. I tried Android, Windows, and Linux and didn't have a problem.

Have you tried the official SiliconDust app on Windows (if available)? It uses broadcast discovery by default, I would think you should see the same weird results. If that works fine I may have to ask SD what I may be doing wrong in the libhdhomerun code. Perfectly willing to do that, of course.

Ok, I just updated to Version 2.0.2 (2019.05.08) thinking maybe that would fix the issue. However, the problem still persists. Sorry, I was away on business for a few and couldn't test anything out.

I had HTTP discovery enabled. So I disabled it and forced a discovery, the only thing that came up was the Tuner, the RECORD disappeared. So I enabled HTTP discovery, forced a discovery, the Tuner showed up and then the Unknown 00000 came back. I still can not see DVR recordings nor can I enable/disable any DVR recording rules.

Everything still works on my OSMC box and my Nvidia SHIELD box based on (now) two versions earlier (unless the updated while I was away on business)

Caveat: I am running my DVR engine on my unRAID home-built NAS using a docker for it. I was using this docker since time began however, the developer had abandoned it I guess as it hasn't been updated. One of the unRAID people went ahead and made a "new" docker based off the binary that SiliconDust released a bit ago.
When I went to my.hdhomerun.com I used to get a big, fat red X next to my record engine but after the gentleman did his update to the docker, everything is "green" across the board.
So, I'm not sure WHAT the issue is?

[djp952]

Everything looks fine to me. Maybe try switching to HTTP discovery? I don't see anything specifically wrong with broadcast here, but my sample size is limited to just my network. I tried Android, Windows, and Linux and didn't have a problem.

Have you tried the official SiliconDust app on Windows (if available)? It uses broadcast discovery by default, I would think you should see the same weird results. If that works fine I may have to ask SD what I may be doing wrong in the libhdhomerun code. Perfectly willing to do that, of course.

Ok, I just updated to Version 2.0.2 (2019.05.08) thinking maybe that would fix the issue. However, the problem still persists. Sorry, I was away on business for a few and couldn't test anything out.

I had HTTP discovery enabled. So I disabled it and forced a discovery, the only thing that came up was the Tuner, the RECORD disappeared. So I enabled HTTP discovery, forced a discovery, the Tuner showed up and then the Unknown 00000 came back. I still can not see DVR recordings nor can I enable/disable any DVR recording rules.

Everything still works on my OSMC box and my Nvidia SHIELD box based on (now) two versions earlier (unless the updated while I was away on business)

Caveat: I am running my DVR engine on my unRAID home-built NAS using a docker for it. I was using this docker since time began however, the developer had abandoned it I guess as it hasn't been updated. One of the unRAID people went ahead and made a "new" docker based off the binary that SiliconDust released a bit ago.
When I went to my.hdhomerun.com I used to get a big, fat red X next to my record engine but after the gentleman did his update to the docker, everything is "green" across the board.
So, I'm not sure WHAT the issue is?

What platform are you running LibreELEC on again? Intel x86_64?

Was the JSON data you posted last time complete? I assumed it may have been an excerpt, but it's malformed if it was complete. When you get a chance, can you turn on HTTP, let it fail, close Kodi, then look in the Kodi log for "Malformed JSON"? The start and end tokens aren't present, if the PVR encountered this exact data it wouldn't work.

I have been struggling with "Malformed JSON" for a while now. It seems to be limited to the EPG data (mostly mitigated), and device discovery. Unfortunately I can't catch it in the act. One of my backlog items (Post #3) is to detect and retry any HTTP operation that results in "Malformed JSON". That didn't make it into v2.0.2. What did make it into v2.0.2 was to detect bad JSON specifically during EPG load and just skip that block of data. Without doing something, repeated EPG load attempts would shut down the EPG loader entirely for a while (intended to prevent unauthorized clients from slamming SD's servers).

edit: You can use wget on LibreELEC to see what that machine is getting back from the server via http. If you have SSH enabled, try SSHing into the box and executing this command:

wget -q -O - http://ipv4-api.hdhomerun.com/discover

Here, I see the full JSON data. Does this look OK to you? Perhaps it's something specific to the machine?

[usafle]

What platform are you running LibreELEC on again? Intel x86_64?

Here, I see the full JSON data. Does this look OK to you? Perhaps it's something specific to the machine?

I'm sorry if I mentioned LibreELEC, I am running CoreELEC on a Minix Neo (Android) box. I just went to my.hdhomerun.com and there is now NO DVR listed. I went to my subscription and noticed it had expired from the "early beta test @ $60 for the year".

I promptly submitted payment, but still no DVR is showing up under my account. So, perhaps the issue isn't with your plug-in but rather on Silicon Dust's end?
When I go to http://ipv4-api.hdhomerun.com/discover there is only one device now listed. A few days ago there was two...

[djp952]

What platform are you running LibreELEC on again? Intel x86_64?

Here, I see the full JSON data. Does this look OK to you? Perhaps it's something specific to the machine?

I'm sorry if I mentioned LibreELEC, I am running CoreELEC on a Minix Neo (Android) box. I just went to my.hdhomerun.com and there is now NO DVR listed. I went to my subscription and noticed it had expired from the "early beta test @ $60 for the year".

I promptly submitted payment, but still no DVR is showing up under my account. So, perhaps the issue isn't with your plug-in but rather on Silicon Dust's end?
When I go to http://ipv4-api.hdhomerun.com/discover there is only one device now listed. A few days ago there was two...

Very possible. Perhaps a wait-and-see is in order for a day or so? I better go do the same, I was an early beta tester too

edit: I will set up my CoreELEC device again either tomorrow or over the weekend to see if I can corroborate anything.

[leopheard]

Kind words are my currency. Saying "awesome" is payment enough -- you are quite welcome! Besides, this way I still have "you get what you pay for" in my back pocket as an excuse for whatever horrible defect I accidentally introduce next

Thank you for you hard work! But whilleeeeee I'm here! I'm having issues having keeping the server running. I start it, and then around 15 minutes later I do a status check and it's not running again. Any logs I can check to find the issue? I've had a look but there's no logs?

Edit: Just found this log from now - one thing I'm noticing is the time is out? It's currently just gone 1900 hrs but this is saying it's just gone 2300? Is that causing the issue? The RPi time is correct. Do I need to forward that port listed to the HDHR box?

Code: Select all

[i]HDHomeRun RECORD 20190417 Linux
20190510-22:50:15 System: file limit = 4096
20190510-22:50:15 Recording: RecordPath[0] = '/media/pi/NAS/HDHR/'
20190510-22:50:15 Recording: RecordPath /media/pi/NAS/HDHR/ = ext
20190510-22:50:15 System: LocalIP: 192.168.1.101 255.255.255.0
20190510-22:50:15 System: website port = 37231
20190510-22:50:15 Recorded: RecordPath '/media/pi/NAS/HDHR/' (ext)
20190510-22:50:15 Recording: discover on 192.168.1.255
20190510-22:50:15 Status: Resource: nbk=0 dmk=133
20190510-22:50:15 Status: ticks = 271428164
20190510-22:50:15 Recorded: directory /media/pi/NAS/HDHR/ with 1 subdirs and 0 recordings
20190510-22:50:15 Recorded: directory /media/pi/NAS/HDHR/Jimmy Kimmel Live/ with 0 subdirs and 0 recordings
20190510-22:50:15 Recording: deviceID lineup request success (found 37 channels)
20190510-22:50:15 Recording: discover on 192.168.1.255
20190510-22:50:15 Recording: discover response from DEVID: lineup url = http://192.168.1.120:80/lineup.json
20190510-22:50:15 Recorded: recorded sync to record-api.hdhomerun.com
20190510-22:50:15 Recording: event download from record-api.hdhomerun.com
20190510-22:50:16 System: server time = Fri May 10 22:50:16 2019 (correction of 0s)
20190510-22:50:16 Recorded: recorded sync success
20190510-22:50:16 System: server time = Fri May 10 22:50:16 2019 (correction of 0s)
20190510-22:50:16 Recording: event download success
20190510-22:50:16 Recording: disk space available = 0GB
20190510-22:50:16 Recording: current time = Fri May 10 22:50:16 2019 (correction of 0s)
20190510-22:50:16 Recording: no timer events planned
20190510-22:52:15 Status: Resource: nbk=0 dmk=147
20190510-22:54:15 Status: Resource: nbk=0 dmk=147
20190510-22:56:15 Status: Resource: nbk=0 dmk=147
20190510-22:58:15 Status: Resource: nbk=0 dmk=147
[/i]

[djp952]

Thank you for you hard work! But whilleeeeee I'm here! I'm having issues having keeping the server running. I start it, and then around 15 minutes later I do a status check and it's not running again. Any logs I can check to find the issue? I've had a look but there's no logs?

Edit: Just found this log from now - one thing I'm noticing is the time is out? It's currently just gone 1900 hrs but this is saying it's just gone 2300? Is that causing the issue? The RPi time is correct. Do I need to forward that port listed to the HDHR box?

Code: Select all

[i]HDHomeRun RECORD 20190417 Linux
20190510-22:50:15 System: file limit = 4096
20190510-22:50:15 Recording: RecordPath[0] = '/media/pi/NAS/HDHR/'
20190510-22:50:15 Recording: RecordPath /media/pi/NAS/HDHR/ = ext
20190510-22:50:15 System: LocalIP: 192.168.1.101 255.255.255.0
20190510-22:50:15 System: website port = 37231
20190510-22:50:15 Recorded: RecordPath '/media/pi/NAS/HDHR/' (ext)
20190510-22:50:15 Recording: discover on 192.168.1.255
20190510-22:50:15 Status: Resource: nbk=0 dmk=133
20190510-22:50:15 Status: ticks = 271428164
20190510-22:50:15 Recorded: directory /media/pi/NAS/HDHR/ with 1 subdirs and 0 recordings
20190510-22:50:15 Recorded: directory /media/pi/NAS/HDHR/Jimmy Kimmel Live/ with 0 subdirs and 0 recordings
20190510-22:50:15 Recording: deviceID lineup request success (found 37 channels)
20190510-22:50:15 Recording: discover on 192.168.1.255
20190510-22:50:15 Recording: discover response from DEVID: lineup url = http://192.168.1.120:80/lineup.json
20190510-22:50:15 Recorded: recorded sync to record-api.hdhomerun.com
20190510-22:50:15 Recording: event download from record-api.hdhomerun.com
20190510-22:50:16 System: server time = Fri May 10 22:50:16 2019 (correction of 0s)
20190510-22:50:16 Recorded: recorded sync success
20190510-22:50:16 System: server time = Fri May 10 22:50:16 2019 (correction of 0s)
20190510-22:50:16 Recording: event download success
20190510-22:50:16 Recording: disk space available = 0GB
20190510-22:50:16 Recording: current time = Fri May 10 22:50:16 2019 (correction of 0s)
20190510-22:50:16 Recording: no timer events planned
20190510-22:52:15 Status: Resource: nbk=0 dmk=147
20190510-22:54:15 Status: Resource: nbk=0 dmk=147
20190510-22:56:15 Status: Resource: nbk=0 dmk=147
20190510-22:58:15 Status: Resource: nbk=0 dmk=147
[/i]

I'm afraid I can't really help much with the server side of things, other than just speculate of course. Suggest asking SiliconDust by posting in the "Software Setup & Troubleshooting (Live & DVR)" forum:

viewforum.php?f=119&sid=0aa5d8b9115e6a6 ... 99e1ffc030

(sorry)

[djp952]

What platform are you running LibreELEC on again? Intel x86_64?

Here, I see the full JSON data. Does this look OK to you? Perhaps it's something specific to the machine?

I'm sorry if I mentioned LibreELEC, I am running CoreELEC on a Minix Neo (Android) box. I just went to my.hdhomerun.com and there is now NO DVR listed. I went to my subscription and noticed it had expired from the "early beta test @ $60 for the year".

I promptly submitted payment, but still no DVR is showing up under my account. So, perhaps the issue isn't with your plug-in but rather on Silicon Dust's end?
When I go to http://ipv4-api.hdhomerun.com/discover there is only one device now listed. A few days ago there was two...

Still looking into this, again it's hard without having the exact same problem. However, I did find something unexpected. The SQLite JSON parser I'm using accepts the string "null" as valid (turns out it is), but when used like a table, instead of no rows which I what I expected, it returns one row with a single NULL value.

It may not be relevant, but almost every SQL query in this code relies upon treating JSON data like a table. One of my backlog items is to replace my generic HTTP request database function with a JSON specific one that runs the data through a different parser (rapidJSON) first before returning it, and I want it to automatically retry a failed JSON request at least one time.

Let me know if things improve for you with the subscription fixed!

[usafle]

Still looking into this, again it's hard without having the exact same problem. However, I did find something unexpected. The SQLite JSON parser I'm using accepts the string "null" as valid (turns out it is), but when used like a table, instead of no rows which I what I expected, it returns one row with a single NULL value.

It may not be relevant, but almost every SQL query in this code relies upon treating JSON data like a table. One of my backlog items is to replace my generic HTTP request database function with a JSON specific one that runs the data through a different parser (rapidJSON) first before returning it, and I want it to automatically retry a failed JSON request at least one time.

Let me know if things improve for you with the subscription fixed!

Opened a support ticket with S.D. after I made payment and the DVR was still not showing up. There is an issue with the unRAID container I'm running it in apparently. So, I guess I'm S.O.L. with the DVR stuff until someone fixes the docker container.... I certainly don't have the technical know-how to fix it. I can't do any further testing on your plug-in if I can't get the DVR to work.