Unofficial Kodi HDHomeRun DVR PVR Client

[fletchb1]

Fixed before I even saw the post! Nice. HTTP used to be the default but I recently switched it over to use UDP broadcast by default by popular demand HTTP discovery works perfectly well, the only problem with it is that if you turn something off it will still show up in the list for up to 24 hours. If you aren't in the habit of turning things on and off, there should be no problem at all!

Glad you like it, have a great remainder of your weekend.

What do you mean that it will show up in the list for 24 hours? I did noticed that my main TV no longer has the program guide and can't record anything like it lost the record engine.

The discovery data in the cloud (HTTP) has no means of knowing if you turned something off and will continue to report the device as available for around 24 hours.

The guide data and the ability to add/manipulate tuners depends on the information reported from your tuners. The RECORD engine, ironically enough has nothing to do with those. If the discovery data about the tuners is out of date the PVR may be sending stale authorization strings to the could backend and cause this. Can you provide a Kodi log from this system? I pretty much log everything useful at this point it should be pretty easy to identify the root cause from that

Sure I can send you the logs when I get home tonight but just to be clear your addon is working fine on my chromebook. I just saw your 24 hour comment and wondered what you meant as I ran into another problem that may or may not be related:

Moments after I got Kodi working on the chromebook , I just happen to notice that the guild stopped working on our main tv (Android running on Shield) and could not record any shows.

I was too tired to fool with it last night but noticed it was working again this morning so not sure if they were related or not. Tonight when I get home from work, I will fire up the chromebook and see if the issue returns.

[djp952]

So I've upgraded to Kodi 18.3 plus the beta version of the PVR Client in three different environments (my house, and two friend's houses). All seem to be working well. In my friends houses there is NO recorder and previously they would experience the video buffering spinning circle. This no longer happens when they are using the UDP option. (though they do get occasional pixelation if a UDP frame get corrupted.

I can get some bad pixelation on my Windows laptop over Wifi as well streaming an HD channel. On the same machine I ran hdhomerun_config to compare what I was seeing via the PVR with what that tool says, and unfortunately I got what I was expecting to get -- lots of network errors:

Code: Select all

hdhomerun_config XXXXXXXX save /tuner2 null
....n...n.n...n..n.n.n..n.nnnn.nnn.n.n.............n.n.n..........nn.nn.
-- Video statistics --
70489 packets received, 0 overflow errors, 30 network errors, 0 transport errors, 0 sequence errors

I'll throw some breakpoints in the code and see if there is anything I think I can do to improve it, but it's looking like UDP is just being UDP. I fear it will come down to what kind of problems are preferred on less than ideal networks -- with UDP you may miss packets of data but won't cause incessant Kodi buffering. with HTTP (TCP) you get reliable data but can't deliver it fast enough to Kodi.

Having this behavior on my Windows laptop is ideal for trying to do something about it, though. I'll spend some time on it this weekend and see if there are any tricks I might be able to play. Low probability, though - libhdhomerun is pretty tight - it would be rather arrogant of me to think I could somehow do better (I can't).

I'll let you know one way or the other!

So back to this for a minute. I did code up a RTP/UDP test application that does nothing but sit there and receive packets from the tuner using the low-level socket API instead of libhdhomerun. My theory was that the worker thread and/or the processing overhead in libhdhomerun might be contributing to the packet loss and that I might be able to do better without all that in play.

Short version: Doing it all myself yields a pretty insignificant set of improvements; there is no measurable benefit to bypassing libhdhomerun. The only way I think to make this better is to start messing with QoS on the Wifi router.

Long version: RTP provides a sequence number that can be checked to see if packets have been lost. Even with getting rid of the overhead code in libhdhomerun completely I see basically the same number of missed packets that libhdhomerun does and at basically the same frequency. The only improvement I got was a slightly smaller delta when packets are lost (i.e. I lost 10 packets instead of 14, or 8 packets instead of 10), but that doesn't seem to really matter much in the end -- the video is going to glitch anyway. Here's why I think that: I learned that HDHomeRun devices will always send 7 MPEG-TS packets as part of a single RTP/UDP payload. So every lost RTP/UDP packet loses 7 MPEG-TS packets with no hope of recovering them. From my observations losing 7 MPEG-TS packets isn't that horrible depending on what they had in them, but any time a "gross" error like losing 10 UDP packets (70 MPEG-TS packets) happens there is little that can be done.

Adjusting the QoS settings of the Wifi router, if available, may be of benefit. Trying to prioritize UDP over TCP for the tuner(s) and the target device could conceivably reduce the packet loss while streaming. Unfortunately it looks like the best way to use RTP/UDP is the same as it always was -- use a wired network. Of course, once you have a wired network available HTTP (TCP) is a far superior choice, negating the need for RTP/UDP.

Also want to add some props for SiliconDust here, libhdhomerun RTP/UDP streaming seems entirely too complex at first glance but as always they know their stuff and it's close to impossible to realistically improve upon it!

[ddejager]

Thanks for the testing and info. I agree with your conclusions, but hope you will leave in the UDP option in the mainline release. Still a mystery: why using HTTP at my friends house the channel startup problem occurs. All wired connection from the Firestick to the tuner. No recorder in his system.

[djp952]

Thanks for the testing and info. I agree with your conclusions, but hope you will leave in the UDP option in the mainline release. Still a mystery: why using HTTP at my friends house the channel startup problem occurs. All wired connection from the Firestick to the tuner. No recorder in his system.

Oh it will stay in don't worry about that. It's useful! Useful is good. I haven't fully declared defeat yet either, I'm wiring up the straight UDP socket code into the PVR to see if the assumptions of "no meaningful difference" are accurate. I went this far may as well see how it works for reals

I'm hoping the logs will help with what's going on with the fire stick over HTTP. My guess is still something with ffmpeg .. you might have to turn on debug logging for us to see that. I checked the Kodi ffmpeg changes and they last updated it with Kodi 18.2 so it could be a prime suspect. We shall see.

[fletchb1]

What do you mean that it will show up in the list for 24 hours? I did noticed that my main TV no longer has the program guide and can't record anything like it lost the record engine.

The discovery data in the cloud (HTTP) has no means of knowing if you turned something off and will continue to report the device as available for around 24 hours.

The guide data and the ability to add/manipulate tuners depends on the information reported from your tuners. The RECORD engine, ironically enough has nothing to do with those. If the discovery data about the tuners is out of date the PVR may be sending stale authorization strings to the could backend and cause this. Can you provide a Kodi log from this system? I pretty much log everything useful at this point it should be pretty easy to identify the root cause from that

Sure I can send you the logs when I get home tonight but just to be clear your addon is working fine on my chromebook. I just saw your 24 hour comment and wondered what you meant as I ran into another problem that may or may not be related:

Moments after I got Kodi working on the chromebook , I just happen to notice that the guild stopped working on our main tv (Android running on Shield) and could not record any shows.

I was too tired to fool with it last night but noticed it was working again this morning so not sure if they were related or not. Tonight when I get home from work, I will fire up the chromebook and see if the issue returns.

Not sure what happened last night but just tried it again and Kodi/your app working great and hdhomerun app on main tv still working fine. Did not lose guide data or recording ability. Only difference and I just now noticed: I did a test recording on kodi last night and it is not showing up. Just did another test when I had kodi open and it is recording and it is showing up on main tv like it should.

Not sure about anything at this point- Just a coincidence? I have seen weirder things before. Anyway just throwing this all out in case you or someone else runs into this in the future.
Thanks again for your work!!

[signcarver]

You do realize there was a guide outage at the time of question that affected everyone due to an expired security certificate.

[fletchb1]

You do realize there was a guide outage at the time of question that affected everyone due to an expired security certificate.

No I didn't but the issue is still going on and off with the HDHomeRun app.

Kodi/his app on 2 devices still working fine.

the next day the fonts on the app changed - got larger and I could not exit the app without doing a force close.
When I got home I restarted and everything fine other than the fonts being larger.

Today still large fonts but stuck on 1 channle. No menu, no DVR. Kodi on that device still works fine. If you hit the pause button 13 or so times, it says no DVR available.

Backroom tv. It is older version of app. It took about 3 attemps to start but once it did, it is working fine at the moment.

Not sure what is up but they are still having problems.

[djp952]

You do realize there was a guide outage at the time of question that affected everyone due to an expired security certificate.

No I didn't but the issue is still going on and off with the HDHomeRun app.

Kodi/his app on 2 devices still working fine.

the next day the fonts on the app changed - got larger and I could not exit the app without doing a force close.
When I got home I restarted and everything fine other than the fonts being larger.

Today still large fonts but stuck on 1 channle. No menu, no DVR. Kodi on that device still works fine. If you hit the pause button 13 or so times, it says no DVR available.

Backroom tv. It is older version of app. It took about 3 attemps to start but once it did, it is working fine at the moment.

Not sure what is up but they are still having problems.

I've only used the HDHomeRun app on Windows, wish I could help more. Do you have an Android phone to try it on as opposed to the Chromebook? I don't know anything at all about Android apps on Chromebook (never used one), but I assume there is still some compatibility layer in place. There could be glitches there, I would think on Android the SD app still uses native code modules like ffmpeg that maybe Google has difficulties with still or may even need to be recompiled for a newer/older NDK version or something.

This is mere speculation, of course. Outside of the very occasional use for watching a DRM channel I really don't use the official application at all. Sorry!

[fletchb1]

You do realize there was a guide outage at the time of question that affected everyone due to an expired security certificate.

No I didn't but the issue is still going on and off with the HDHomeRun app.

Kodi/his app on 2 devices still working fine.

the next day the fonts on the app changed - got larger and I could not exit the app without doing a force close.
When I got home I restarted and everything fine other than the fonts being larger.

Today still large fonts but stuck on 1 channle. No menu, no DVR. Kodi on that device still works fine. If you hit the pause button 13 or so times, it says no DVR available.

Backroom tv. It is older version of app. It took about 3 attemps to start but once it did, it is working fine at the moment.

Not sure what is up but they are still having problems.

I've only used the HDHomeRun app on Windows, wish I could help more. Do you have an Android phone to try it on as opposed to the Chromebook? I don't know anything at all about Android apps on Chromebook (never used one), but I assume there is still some compatibility layer in place. There could be glitches there, I would think on Android the SD app still uses native code modules like ffmpeg that maybe Google has difficulties with still or may even need to be recompiled for a newer/older NDK version or something.

This is mere speculation, of course. Outside of the very occasional use for watching a DRM channel I really don't use the official application at all. Sorry!

Dip952:

Your kodi add on is working great on both the chromebook and my main tv- it's only their official app that is having issues. I am going to downgrade the app to the previous version on my main tv tonight and see if there is any difference. Backroom bedroom tv is older version of app and it worked fine after a few restarts.

Thanks..

[djp952]

Update on the whole RTP/UDP thing for ddejager (and anyone else that might want to use this).

I finished the "for reals" version of my custom UDP implementation enough to do some real world testing and measurements. As I feared I really don't see any tangible difference between using the provided code in libhdhomerun as opposed to doing it myself. But ... after digging in a bit on a Pi (3B+) there are measurable, if not minor, improvements. What I've been able to confirm is a very slight drop in CPU utilization. It amounts to around 1-2%. I attribute this to eliminating the worker thread libhdhomerun uses. That thread was taking up about 5% of the process time. The entire 5% doesn't disappear because of course the work still needs to be done, I just opted to do it differently.

From past experience with the PVR on very low power devices, like the first gen FireStick, having a worker thread involved with the stream was sub-optimal. I also think any CPU% improvement, no matter how small, may be of benefit in these cases. Maybe it will equate to nothing, maybe it will reduce the quantity and/or severity of drop-outs. What it won't do is take a stream that glitches on RTP and magically make it perfect. For Linux and Android, I also added a call to increase the socket priority as high as it can go without being root. I am unsure of the benefits here, but it didn't hurt

I have one more missing piece to implement (tuner keep-alive packets), so once that's done I'll dig out the first-gen FireStick from wherever I put it and make sure it works there. If it works on that, it should work on anything - lol.

So it looks like there will be a 2.2.0~beta2 with this for you to try out. The preferred protocol settings will change to "HTTP", "RTP" and "UDP (experimental)", with "HTTP" still being the default. Maybe one or two more evenings. The cURL version with my UWP (XBox) issue fixed is available now as well, I have been waiting for that so I can undo a kludge I had to put in for the last cURL version.

[dugiehowsa]

Also, for dugiehowsa, I found nothing I could point to in the PVR that could cause your issue. The only memory leaks I was able to detect are when the DirectX system (Windows only) is shutting down in Kodi, and when SQLite is shutting down since I have an "automatic extension" set up, there are a couple benign, very very small, memory leaks there. All of this only occurs when the system is unloading anyway, not while it's running. I see that at least one other Kodi user has the same problem you do, didn't sound like they are using this PVR.

If I find anything that might help, I'll let you know. I think this is squarely a Kodi-level concern, but as time allows I don't mind poking around Kodi at all.

Just wanted to let you know that I had disabled your addon two weeks ago in order to rule out variables, and the issue has happened again. So your addon is definitely in the clear. Just wanted to close the loop on this.

[djp952]

Also, for dugiehowsa, I found nothing I could point to in the PVR that could cause your issue. The only memory leaks I was able to detect are when the DirectX system (Windows only) is shutting down in Kodi, and when SQLite is shutting down since I have an "automatic extension" set up, there are a couple benign, very very small, memory leaks there. All of this only occurs when the system is unloading anyway, not while it's running. I see that at least one other Kodi user has the same problem you do, didn't sound like they are using this PVR.

If I find anything that might help, I'll let you know. I think this is squarely a Kodi-level concern, but as time allows I don't mind poking around Kodi at all.

Just wanted to let you know that I had disabled your addon two weeks ago in order to rule out variables, and the issue has happened again. So your addon is definitely in the clear. Just wanted to close the loop on this.

I am both happy and sad to hear this. Happy in that it's not my fault, but sad I can't be of help to ya Thank you very much for letting me know!

[djp952]

On July 20th, 1969 humans first walked on the moon. On July 20, 2019 djp952 gives you something that doesn't quite measure up to that particular feat ... lol

Version 2.2.0 (2019.07.20)

• Update cURL library to version 7.65.3
• Update libhdhomerun library to version 20190625
• Update SQLite database engine to version 3.29.0
  
• Add support for legacy RTP/UDP streaming directly from tuner devices
  
• Add "Append repeat indicators to applicable episode names" setting
• Add "Preferred tuner streaming protocol" advanced setting
• Prevent error logging of every channel when EPG has been temporarily disabled due to an error

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


Nothing Earth (or Moon) shattering, this is a maintenance release that formalizes a couple user requests and updates the third-party libraries to the most recent versions available. I've droned on about them in past pages, let me know if you would like me to expound upon anything, I'm happy to do so.

In regard to RTP/UDP, I did not include a work-in-progress feature to use a custom UDP stream. While it was fun to make and it does perform ever so slightly better CPU%-wise I still can't find a case where it makes any difference whatsoever over using the RTP/UDP implementation provided by HDHomeRun. Even on a first-gen Firestick running Leia I get exactly the same results. There are a couple/few bug fixes in here regarding RTP/UDP that weren't in the "beta1" release to test it out. I think it's solid and suits the niche case it intends to nicely. As always, let me know if you feel differently or have some case where you think an extra 1-2% CPU might actually change things for you. I have the code tucked away in git on a Leia-upstream branch, so it's not deleted or anything.

We will also now find out how well auto-update (Leia) actually works on Linux! Woot.

Enjoy, and be sure to watch at least one thing about Apollo 11 this weekend! What we do today with computers pales in comparison to the sheer magnitude of what those that came before us did. Some truly great men and women, taking a bunch of transistors and helping get to the moon. Of course not long after, pop-up ads and spam were invented, so there's that

[ddejager]

Thanks for the update info! I did not get to my friends house this week to check the log with http. I assume that the 2.2.0 release will automatically replace the beta and he will see the problem again because it will go back to HTTP. Correct?

[djp952]

Thanks for the update info! I did not get to my friends house this week to check the log with http. I assume that the 2.2.0 release will automatically replace the beta and he will see the problem again because it will go back to HTTP. Correct?

It should™ auto-update but keep the settings from 2.2.0~beta1 since they are the same. It should™ just work. The final does fix a couple bugs with the implementation, the only one you may have seen was that I was leaving the channel tuned on the tuner. It was properly unlocked and had the stream stopped, so just an annoyance (and perhaps a few milliamps of electricity your friend didn't need to pay for)

Disclaimer: should™ is a registered trademark of the software development community. It may be used when a developer actually has no idea what will happen but crossed both their fingers and their does since they didn't test that particular item

edit: my Android phone had 2.2.0~beta1 on it set for RTP/UDP. It auto-updated to 2.2.0 and kept all the settings as anticipated. I'm getting kinda good at this ...