OLD: Unofficial Kodi PVR Client for HDHomeRun DVR subscribers

[djp952]

Just checking in; I think I have resolved the 'database is locked' and/or 'disk I/O error' problems occurring on Android. It was my mistake as I expected.

If you are interested, I created a connection pool for the underlying SQLite database to facilitate proper multi-threaded access, but I failed to change the piece of code that opens the database such that initialization tasks (i.e. setting up the schema and static data) would only occur on the first connection. It looked like the problems were occurring when a new connection was opened and stomped on an existing one by trying to change things that didn't need changing, and did so before the new connection was fully set up. So far in testing I have not seen any more errors in the logs.

I've also changed over to using ipv4.my.hdhomerun.com exclusively and added a new "SD Channels" channel group. I still want to look at the behavior when bad things happen during discovery to see what can and can't be left alone so that losing connection to the web intermittently is handled more gracefully.

Looking like new version tomorrow night for ya.

[bhasse]

Can this be installed in Kodi on an Amazon Fire TV yet?

[djp952]

Can this be installed in Kodi on an Amazon Fire TV yet?

I think so; but it will need to be rooted in order to copy a library file (Kodi limitation right now). I have Android clients for all the flavors of Android that Kodi claims to support for Kodi 16.1 and Kodi 17.x. I only have one physical Android device in my possession to test on, and it's a Lollipop ARMv7 device. I have tried the code using emulators for everything else.

In a related matter, version 1.0.3 has been posted:

v1.0.3 (2017.03.05)
- Add "SD Channels" channel group
- Use IPv4 specific backend discovery URLs (ipv4.my.hdhomerun.com)
- Resolve issue with SQLite database being locked during initialization of a new connection

ANDROID USERS: You will still have to manually copy the libhomerundvr.so file from the Kodi user addons folder to the Kodi data directory manually. When upgrading from 1.0.2, if you don't close Kodi and copy the new libhdhomerundvr.so file in place you will still be running version 1.0.2 -- the newer .so file will never be loaded by Kodi.

There isn't much left on my todo list, please let me know if you run into any more difficulties on Android (or any other platform, of course)

PS - Would it be of value to produce custom-built Kodi .APKs that include this PVR to avoid the root route? I could try that; would be willing to see how that goes for 'final' Kodi versions like 16.1 or 17.0, I'd never be able to keep up with their beta/RC cadence. Then you get all the stock PVRs plus this one?

[stickly]

PS - Would it be of value to produce custom-built Kodi .APKs that include this PVR to avoid the root route? I could try that; would be willing to see how that goes for 'final' Kodi versions like 16.1 or 17.0, I'd never be able to keep up with their beta/RC cadence. Then you get all the stock PVRs plus this one?

It would be very helpful if you could get it integrated into some sort of "official" release so you don't have to keep up with it all the time. I think SPMC would be a great candidate since it is tailored specifically to Android installations. Or get it in the main Kodi release if it's not too difficult.

[ssyspro]

PS - Would it be of value to produce custom-built Kodi .APKs that include this PVR to avoid the root route? I could try that; would be willing to see how that goes for 'final' Kodi versions like 16.1 or 17.0, I'd never be able to keep up with their beta/RC cadence. Then you get all the stock PVRs plus this one?

Yes you should build Kodi .APKs or rather SPMC .APKs. It would allow non rooted devices to enjoy it also.


Edit see new post -> real issue discovered thanks to signcarver

I am still having some issues and while I do not see others posting about any I checked out clarkss12’s video and it showed that he is also having an issue with the recordings list “clarkss12 feel free to post on this to confirm if I am correct or in error”.

I am finding the issues are very inconsistent from no guide data or channel list to no recordings list with no specific time frame or action to reproduce. Logs are not providing any hint to what is happening.

I suspected a network issue of some kind but have yet to find it but here is my test results.

Using SD’s software discovery on my pc “hdhomerun_config discover” it gave me every SD device except DVR every time I even setup a script to run at random times between 30 seconds and 300 seconds so now I am not so sure the issue is network related all at least not my lan.

Using the SD servers to discover I found each URL gave a different result from no devices to only one device or all but one device none would give all devices and results were completely erratic.
http://my.hdhomerun.com/discover
http://ipv4-my.hdhomerun.com/discover
http://ipv4.my.hdhomerun.com/discover

I think the erratic discovery results coming from SD is the root cause of this issue I am having.

When Using SD’s viewer in Kodi I do not have these issues so I assume they are caching the discovery results in some way.
Whatever their method I would like to suggest that this add-on cache the device discovery data please.

For example if discovery runs returning dvr and one tuner then discovery runs again returning 2 or more tuners but no dvr then yet again discovery runs returning only dvr and so on getting the same erratic results I get by testing the discovery url’s.

I would like something like this added if possible write discovered devices to table but do not remove on next discovery just keep adding on each discovery or updating the row if same id is found only remove on kodi restart or maybe a ping test to the device ip and remove if ping fails. I could be completely off base here but think this should correct the issue with recordings list, channels list, and guide data randomly going blank. Since the issues seem to be related to devices not being discovered during updates but can not confirm because logs do not seem to show what or how many devices are being discovered.

What do you think am I on the right track here?

[signcarver]

hdhomerun_config only returns tuners... but essentially discover in kodi is done the same way a broadcast to udp 65001 and see what gets replied.

If you are having problems at my.hdhomerun.com. It works differently. what happens is when the tuner powers up or you run a channel scan and every 8 hours after that (and presumably every time it's ip changes) the tuner "phones home" SD records the public ip address that sent that information and the private ip address of the tuner (and engines which is a similar process but I think connects every hour but I think it gets dropped after 8 if it doesn't connect). They do this as a web page, especially one hosted outside your network, has no way to discover tuners (a web server on the same network though could prior to serving the page, thus provide the information). If your ISP frequently changes your public ip, the next time you retrieve this, it will have a different list of local ip addresses. Then one should loop through each "discovery" address obtained to make sure a tuner answers prior to adding it to the list to use (not sure if this app does that, as author may have assumed the list was absolute and not bothered checking... I believe they mentioned using my.hdhomerun before so I believe they didn't bother an attempt of real discovery).

[ssyspro]

@signcarver -
I know that hdhomerun_config only shows tuners but did not want to say it finds all devices when it only finds the tuners but I think a ah ha moment has just occurred for me if SD is using the public IP.

From reviewing the source the author is indeed using the discovery results from my.hdhomerun and I didn't see an issue with that but if SD servers are using the IP address that the `phone home` came from this may indeed be the issue while all the SD devices on my network have static ip's assigned through DHCP reservations on the lan my public IP does change not because of the ISP but because I have more than one ISP and more than one public IP. My connection is load balanced or a multi wan connection so the `phone home` can come from one of several IP's this explains why I can load SD's discovery page then refresh and see a different result later

Thank You for this bit of information, this thought had crossed my mind before and I dismissed it but it makes perfect sense now.

So with this new information I will setup some source NAT rules so that as far as SD is concerned the `phone home` always comes from the same public ip and see what happens.


@djp952 -
While I maybe one in a million for a multi wan connection others maybe using VPN's like PIA or a TOR connection that would cause the same issue so ignore my last request but here is a new request for improvement to the add on can you look into doing network discovery instead of relying on SD servers for the device discovery?

I will still add source NAT rules for my network to try and fix it from my side.

[djp952]

Nice job of working through that guys! I didn't even see these posts until well after you figured it out (for what it's worth, I wouldn't have been much help on that one anyway, would have probably thrown out something useless like "it just does what my.hdhomerun.com tells it to" )

At one point I was going to use the broadcast discovery, even wrote that code, but opted to stick with the my.hdhomerun.com for two reasons -- I wanted to ensure that only HDHomeRun devices supported by the DVR service would be detected (otherwise the storage engine can't stream/buffer them for live TV) and I didn't want to have to license the code under GPLv2 (I used the MIT license) by linking with libhdhomerun.

Both concerns aren't that important to me, really. It's not difficult to omit "legacy" devices from broadcast discovery at all, it tells you what they are. I can also avoid switching to the GPLv2 license by including libhdhomerun as a dynamically linked library rather than compiling it all in.

I'll have to look at the official Kodi addon under Android to see if it lays down libhdhomerun.so or not (I think it statically links), since all the .SO files end up in the same directory and I wouldn't want to step on it (or it me). Even if it does I can still just switch things over to GPLv2 and suck in the libhdhomerun broadcast discovery code, preventing any possible issues.

Let me think about this one for a couple days, but I'll go ahead and give a tentative "sure - I can totally add that for ya!". I also found a problem tonight with DateTimeOnly rules that overlap with a Series rule -- there is no feasible way to delete the DateTimeOnly rule through this client since the Series rule is taking precedence. It gets ugly, you pretty much just have to wait the DateTimeOnly rule out until it's expired and auto-purged. ugh.

[signcarver]

Are you not deleting by RuleID? (I haven't looked at your add-on as it would be useless to me as 95% of my channels are DRM, so I know kodi PVR would never be in my future but I should have some time this week to at least look at it).

[djp952]

Are you not deleting by RuleID? (I haven't looked at your add-on as it would be useless to me as 95% of my channels are DRM, so I know kodi PVR would never be in my future but I should have some time this week to at least look at it).

I am deleting by RuleID, the bug happens because when I generate the list of timers for Kodi there may be more than one for a specific episode, one from a series rule and one from a date/time only rule for example, and the series one is winning out. The date/time only Timer isn't being handed off to Kodi at all. I need to make a change so both timers show up or the date/time one takes precedence. Timers set by series rules can't be deleted (in this PVR Client) because doing so nukes the entire recording rule (by design apparently, you'd have to ask SiliconDust why they did that, but it is a documented "feature" ) I'll fix it, it should just be a small change to the query that creates the Timers from the discovery information.

As for the other problem you guys had with using the device list from my.hdhomerun.com, I have added a "Use network broadcast for device discovery" option for the next iteration. Seems to work fine on Windows/Linux, haven't tested Android yet since the emulator(s) don't allow UDP broadcasts to work -- I can test it on Krypton on my sole Android device soon, probably when we get snowed in on Tuesday .

I'll send something new out when I fix the date/time only timer concern and I also added a way to cancel the discovery tasks when Kodi is shutting down or system is going to sleep -- I just haven't implemented it anywhere yet. Soon™!

[stickly]

PS - Would it be of value to produce custom-built Kodi .APKs that include this PVR to avoid the root route? I could try that; would be willing to see how that goes for 'final' Kodi versions like 16.1 or 17.0, I'd never be able to keep up with their beta/RC cadence. Then you get all the stock PVRs plus this one?

Yes you should build Kodi .APKs or rather SPMC .APKs. It would allow non rooted devices to enjoy it also.

I agree, custom Kodi apk would be great if you can't get it in officially, this would let all of us with unrootable FireTVs be able to use your awesome DVR add on. Thanks for all the great work!

[djp952]

OK gang, v1.0.4 is out there for you. The UDP device discovery option is in there, as well as a couple bug fixes and a couple tweaks:

- Add "Use network broadcast for device discovery" option
- Fix problem with Record Series and Record Once timers that overlap on an episode only exposing the Record Series Episode timer
- Fix problem where only one episode of a Record Series timer rule was being exposed as a timer
- Cancel discovery of extended (8 hour) Electronic Program Guide data when Kodi is exiting or the system is entering a sleep state
- Execute discovery tasks initiated through the PVR Client Specific settings asynchronously

I'll look at building Android APKs next. I also have a couple pull requests for Kodi to put together if I can figure out an acceptable way to fix a few things for them

[Beerman]

I seem to be having more stupid moments installing this and when browsing to the zip file and choosing it I get an error message that says
"the dependency could not be satisfied". Do I have to rename the zip file to something else or is there something else I need to look at.
This is on Kodi 17.
Thanks!

[djp952]

I seem to be having more stupid moments installing this and when browsing to the zip file and choosing it I get an error message that says
"the dependency could not be satisfied". Do I have to rename the zip file to something else or is there something else I need to look at.
This is on Kodi 17.
Thanks!

What OS? I didn't have any problems in testing, but that certainly doesn't mean I didn't make a mistake Very limited amount of systems available here in the ol' basement. I just checked the Linux/Android libraries and nothing jumped out at me as out of the ordinary (like with v1.0.0 and needing a newer GCC)

If there is a missing dependency on Linux/Android there should be something in the Kodi log file about it. Otherwise, if I can mirror your setup I'd be very happy to give it a try!

[Beerman]

W10. I tried it on another W10 box and get the same error message. It pops up and leaves quick but the exact message is "the dependency on xbmc.pvr version 4.1.0 could not be satisfied".
I feel it's something on my end but I've done nothing different than normal when installing addons.