OLD: Unofficial Kodi PVR Client for HDHomeRun DVR subscribers

[danielwlewis]

Hi NYPlayer,

Just ran into another problem (maybe something others have seen?): Some of my channels suddenly stopped playing in Kodi. They were playing, but not anymore. Other channels continue to work. When I try to play the problem channel, the progress indicator in the lower right-hand corner of the screen spins for a while and then quits without starting the playback. I've tried stopping and starting the HDHomeRun RECORD engine, tried rebooting Kodi, tried clearing the guide data - nothing seems to fix it. But I can play the channel using the SD HDHomeRun program.

Does your PVR create a log file anywhere that would be useful? (I'm assuming that the log file created by the record engine isn't relevant since I can play the station using the SD program.)

Dan

That is a known problem I have the same Problem are you using Android ? I have that problem on my Shieldtv sometimes channels will not play.

No. I'm running KODI within LibreElec running on an Intel cpu.

BTW, I added a few more symptoms to my bug report posting.

Dan

[djp952]

New Issue?

Tonight I added a Record Series Rule for Frontline on KQED (PBS) cable channel 709 here in the SF Bay Area. I set it to only record new episodes. There is a new episode S35E18 (Life on Parole) first broadcast 7/18 (tonight) at 10 pm, but rebroadcast again tomorrow morning at 4 am. Timers were created for both broadcasts of this same episode. (Same problem for multiple broadcasts of the same new episodes of Suits and Jay Leno's Garage.)

I would have expected (hoped?) that it would only schedule a single non-conflicting broadcast of each new episode.

Update: When I used the SD HDHomeRun Program to delete the timer for the second broadcast, the series rule and both broadcasts were deleted. ????

Dan

numus hit this one on the nose. You have to understand how the HDHomeRun backend works to explain both of these concerns (I also explain them in the wiki: https://github.com/djp952/pvr.hdhomerun ... imer-Rules)

I'll start with the second one first. You can't not record a single episode of a series, the DVR service doesn't allow for that. Everything is defined by Recording Rules, and there are 2 primary types: Series and DateTimeOnly. With a Series rule, you have no specific control over
what will be recorded, you can only give it a "hint", like "New Only" or "Recent". Therefore, when you delete a single episode, you are in reality deleting the entire rule. There is currently no way around this, and it's even documented by Silicondust:

https://github.com/Silicondust/document ... ding-Rules

Code: Select all

If ProgramID and StartTime are specified the airing is identified in the guide and ALL recording rules that would result in recording the specified airing are deleted.

Now, when it comes to trying to show you through Kodi what specifically will be recorded, that's also impossible. The DVR service provides a list of episodes that MIGHT be recorded. What it actually chooses to do is a mystery to an application. What I do is take that list of what MIGHT be recorded and create read-only Kodi "Timers" from them. This way they show up in the guide with the little badge icon and you can use the Timers interface to see the details (date, time, title, etc). It's important to understand the MIGHT part. It's honestly the best that can be done for now short of not showing anything at all.

Kodi and pretty much every other DVR ever allows much greater flexibility over scheduling recordings. Why SiliconDust implemented theirs differently is question for them I do the best I can with the information available to me.

[djp952]

Just ran into another problem (maybe something others have seen?): Some of my channels suddenly stopped playing in Kodi. They were playing, but not anymore. Other channels continue to work. When I try to play the problem channel, the progress indicator in the lower right-hand corner of the screen spins for a while and then quits without starting the playback. I've tried stopping and starting the HDHomeRun RECORD engine, tried rebooting Kodi, tried clearing the guide data - nothing seems to fix it.

I checked my.hdhomerun.com, and it indicates that the channel is streaming, and the HDHomeRun record engine's log indicates that it *IS* streaming to the Kodi Client.

I can play the problematic channel without any problems using the SD HDHomeRun program.

One more thing: Once this problem appears on one of my Kodi clients, *ALL* of my Kodi clients have the same problem. I.e., the bug seems to be affecting the HDHomeRun RECORD engine (despite what I said in the previous paragraph).

Does your PVR create a log file anywhere that would be useful? (I'm assuming that the log file created by the record engine isn't relevant since I can play the station using the SD program.)

Dan

I know about this, but have no solution. It's got something to do with the stream coming from the RECORD engine. If you enable "Stream directly from tuner(s)" for the PVR it will go away, but you lose seek capabilities. You can still pause.

I have a handful of these bad streams saved off and have looked at them incessantly but it's not the PVR client. All the client does is send the data from the network to Kodi, it has no involvement with decoding or playing the stream whatsoever. I have ideas, all of which are time-consuming and will ultimately cause a lot of bugs to work out, to actually decode the stream myself to see if that helps.

For what it's worth, my RECORD engine itself goes a little bonkers when these channels are attempted. I see a big spike in CPU attributed to the DVR service, stopping and restarting fixes it.

I'm convinced it's Kodi, ffmpeg, or the stream data, but my post about it to SiliconDust didn't yield anything. My research into this to date has shown it's likely something missing or not present often enough in the stream for Kodi/ffmpeg to decode it properly. I see the same problem in VLC when playing the saved stream(s) which I made directly from the RECORD engine, no PVR or Kodi involved.

[djp952]

Suggestion:

Once the series is scheduled, you can then subsequently adjust the parameters of the rule (channel, new or recent only, etc.) via this PVR Client. You may want to restart Kodi after you add rules this way to have them show up immediately -- the default interval to discover them is 2 hours -- (this can be adjusted lower)

I realize that the various discovery functions run periodically so that other Kodi clients accessing the same HDHomeRun tuner(s) see any updates to the timers, guide, etc. I think it would be helpful, however, to see an immediate update on the client where the change was made. E.g., if I create a timer or a timer rule, having it immediately update the guide to show that corresponding programs have been scheduled to record provides a visual confirmation. Is there a way to immediately trigger execution of the relevant discovery function on the client where the change is made rather than simply waiting for the next scheduled execution of the function?

Dan

It does do this on the client from which the Timer Rule was added. Any time a rule is added the episode data is reloaded for that series immediately and a trigger is sent to Kodi to update all of it's timers. If it's not setting the little badges in the EPG perhaps the rule doesn't think it applies to those particular episode(s) for some reason. As mentioned above, we are at the mercy of what the backend thinks it might do and what it tells us.

You can trigger any of the PVR discoveries manually real-time via the PVR & Live TV settings in Kodi. Click on the "Client Actions" section/tab, there will be a list of all discoveries and you can execute them anytime. You can also adjust down the discovery intervals in the Addon settings if you have multiple clients and want them to see changes made from another client more quickly.

[djp952]

Shutting the PC off for the night, couple other things I looked at:

"Any Channel" is indeed an available option when scheduling a series, even when done with a right-click in the EPG, it doesn't appear to me to be broken. Record Once doesn't have Any Channel available. In Krypton that's a limitation but I'm not sure of the value anyway since you're picking a specific date/time/channel to begin with. Leia looks like it will allow that on the Record Once rules.

Recording 'history' not being saved does appear to be a bug in Kodi Krypton. Kodi Leia works just fine for these. I don't have time right now to dig through Kodi to find out why exiting clears out the list of what you have and haven't watched, but I confirmed that the PVR code correctly reports that it doesn't handle that on its own and Kodi never asks it to. I did not test Jarvis.

[canajien]

Many thanks for this!!!!

I recently replaced a mythtv system with an HDHomeRun, and both the official Kodi PVR addon, and the Silicone Dust addon are just awful. Your work fixes everything that was wrong with the official software addons for use with Kodi and makes the HDHomeRun usable.

I was about to return the unit before I found this, and now I am going to buy another one instead.

Thanks again and maybe the people at Silicondust should start giving you a commision

[NYPlayer]

What a difference after I installed it on my Windows PC ... Performs fantastic ... the Shield just has too many problems with the Addon ... I had to remove it.

Edit.

This runs very well in the KODI app from the Windows Store.

[djp952]

What a difference after I installed it on my Windows PC ... Performs fantastic ... the Shield just has too many problems with the Addon ... I had to remove it.

Edit.

This runs very well in the KODI app from the Windows Store.

Sorry about that NYPlayer. I'm still looking into getting something with am ARM64 chipset to find out what the problem was. I have some theories, but testing in emulators doesn't do the trick Glad Windows works, regular GNU Linux should also be pretty stable.

[djp952]

Hey! Guess what I think I figured out tonight?? The channels that won't stream!!

The bad news is that it does appear to be a bug in ffmpeg. Now that I seem to know what's wrong I found the bug reports. It's been broken for a while, sadly.

The GOOD news is that I just tested a program that read in my saved off "bad" streams and converted them successfully to "good" streams. The technique should be able to be applied real-time unbeknownst to Kodi or ffmpeg

The root of the problem appears to be channels that pack extra 'private' data into the PMT (Program Map Table) packets rather than separating it out into its own packets. What I just tested was to detect PMT packets that contain this data, and modify that packet so that it will skip to the start of the real PMT data. I can add this same detection into the PVR client and make it optional/experimental.

I think this is also the reason that some channels take longer to tune than others; if they took a certain amount longer than they do now they may become the "won't stream" channels.

We'll see; this would be really cool to have a workaround for. Downside is that I'll have to make sure Kodi always gets back full TS packets when it asks for data and ensure that seek requests land on a 188-byte boundary, but I don't envision that being much of a problem to solve.

edit: VLC can play the file without waiting a couple seconds to give me video AND I even get a thumbnail for it in Windows now. This is very promising! It even plays in Windows 10 Movies & TV, and that application can barely play anything.

edit: double good news, I have a hacked up test version for Krypton that seems to work (very ugly on the inside, though). I don't have any bad channels right now, but I did find some that were slow to tune (TBS showing "Transformers" at the moment), and with the hack enabled it startup up much more normally. Filtering the TS packets hasn't seem to have any negative effect on anything, Kodi/ffmpeg seems OK with my trickery. But, given how poorly the 1.2 test version with the updated stream code worked for some people I'm leery of making any significant changes to that part of the code so if this does work it will likely be a semi-epic hack that you'll have to specifically enable. Main side-effect so far is that I have to make it wait to always fill up the Kodi buffer, which is adding a smidge of time to the initial tuning request, like a half-second to a second.

[johnny_swindle]

Excellent!!!

Hey! Guess what I think I figured out tonight?? The channels that won't stream!!

The bad news is that it does appear to be a bug in ffmpeg. Now that I seem to know what's wrong I found the bug reports. It's been broken for a while, sadly.

The GOOD news is that I just tested a program that read in my saved off "bad" streams and converted them successfully to "good" streams. The technique should be able to be applied real-time unbeknownst to Kodi or ffmpeg

The root of the problem appears to be channels that pack extra 'private' data into the PMT (Program Map Table) packets rather than separating it out into its own packets. What I just tested was to detect PMT packets that contain this data, and modify that packet so that it will skip to the start of the real PMT data. I can add this same detection into the PVR client and make it optional/experimental.

I think this is also the reason that some channels take longer to tune than others; if they took a certain amount longer than they do now they may become the "won't stream" channels.

We'll see; this would be really cool to have a workaround for. Downside is that I'll have to make sure Kodi always gets back full TS packets when it asks for data and ensure that seek requests land on a 188-byte boundary, but I don't envision that being much of a problem to solve.

edit: VLC can play the file without waiting a couple seconds to give me video AND I even get a thumbnail for it in Windows now. This is very promising! It even plays in Windows 10 Movies & TV, and that application can barely play anything.

edit: double good news, I have a hacked up test version for Krypton that seems to work (very ugly on the inside, though). I don't have any bad channels right now, but I did find some that were slow to tune (TBS showing "Transformers" at the moment), and with the hack enabled it startup up much more normally. Filtering the TS packets hasn't seem to have any negative effect on anything, Kodi/ffmpeg seems OK with my trickery. But, given how poorly the 1.2 test version with the updated stream code worked for some people I'm leery of making any significant changes to that part of the code so if this does work it will likely be a semi-epic hack that you'll have to specifically enable. Main side-effect so far is that I have to make it wait to always fill up the Kodi buffer, which is adding a smidge of time to the initial tuning request, like a half-second to a second.

[djp952]

IT WORKS IT WORKS IT WORKS

Lifetime (of all channels) is airing something 'broken' right now with the extra information in the PMT, will not tune, just hangs and streams to nowhere. I turned on my packet filter - BAM! Fires right up.

I really couldn't in good conscience hack this into the 1.1.x version, it was just too messy and 1.1.x is stable, so it will be in 1.2. Given that some folks had trouble with the 1.2 beta I sent out, I reverted the way the live stream stuff works in regard to waiting and locking and whatnot to match what the old version does. So it looks like 1.2 will be coming soon, probably a test version again to ensure that the streaming part is back to normal.

I'm going to be adding some tuning options this time as well, you will be able to control the minimum amount of data allowed from a stream read, hopefully can fix the problems with Kodi buffering after a second for those that get that problem (at the cost of longer tuning time), and the amount of time the stream will wait before giving up completely. Not sure how useful these will be, but more options are better than none at all

This is very cool, I'm extremely happy to have found a way to solve this.

[vjr]

IT WORKS IT WORKS IT WORKS

Lifetime (of all channels) is airing something 'broken' right now with the extra information in the PMT, will not tune, just hangs and streams to nowhere. I turned on my packet filter - BAM! Fires right up.

This is very cool, I'm extremely happy to have found a way to solve this.

Terrific work Michael.. Everyone here really appreciates the hard work you've done and continue to do on this add-on. The withering disdain towards kodi, hdhomerun and the logitech universal remote has disappeared in our household. Thanks a million for that!

[djp952]

IT WORKS IT WORKS IT WORKS

Lifetime (of all channels) is airing something 'broken' right now with the extra information in the PMT, will not tune, just hangs and streams to nowhere. I turned on my packet filter - BAM! Fires right up.

This is very cool, I'm extremely happy to have found a way to solve this.

Terrific work Michael.. Everyone here really appreciates the hard work you've done and continue to do on this add-on. The withering disdain towards kodi, hdhomerun and the logitech universal remote has disappeared in our household. Thanks a million for that!

You're quite welcome. I got a lot of new WAF tonight installing the updated version, she wasn't able to watch "Silence of the Lambs" on Sundance HD

Sadly I ran into a serious problem testing the new version on Raspbian. LibreELEC worked fine on the Pi 3, trying to sort out what's going on with Raspbian. I'd release the other builds now except I'm worried that the problem may be exactly what was seen on the NVidia Shield with the older test version, which means I may need to change how things are working somewhere; it may lead to a nice performance boost for all the embedded platforms.

I'm hoping for tomorrow night, but can't promise I really want this build to go out cleanly, otherwise I'll just sit here scratching my head again wondering what to change. Getting the same code to work the same way on so many devices is hard! LOL

[djp952]

Turns out that my Raspbian issue was a configuration issue (somehow got set to 64MiB of video memory), and my Firestick issue was a Wifi issue (Firestick no likey high 5GHz channel numbers, switch to 36 if you can), so without any further delay ...

Version 1.2.0 (Build 6415)

• Update libhdhomerun library to version 2017.06.12
• (Jarvis) Fix disabling of seek for Live TV when "Stream LiveTV channels directly from tuner device(s)" is enabled
• Remove custom addon callback implementations in favor of the standard ones provided in Kodi source code
• Update MPEG-TS stream implementation to support Recorded TV as well as tuner-direct Live TV streams
• Detect and remove MPEG-TS SCTE PIM (0xC0) table when inserted before the PMT (0x02) table in the same PSI packet
• Add "DVR stream read operation timeout (milliseconds)" advanced option
• Add "DVR stream read operation minimum size" advanced option
• Add "DVR stream ring buffer size" advanced option

https://github.com/djp952/pvr.hdhomerun ... /Downloads

I don't have a lot of time tonight to update the Wiki, so I'd like to give some information about the bolded items above here:

Update MPEG-TS stream implementation to support Recorded TV as well as tuner-direct Live TV streams
This is what makes it "1.2.0" as opposed to "1.1.2". All HDHomeRun DVR content is now streamed via the internal stream code for this PVR. The old versions used a deprecated Kodi feature to just pass it a URL that is slated to be removed, so this change was inevitable. Note that based on feedback from a test version of 1.2.0, I did revert the way it handles threading and synchronization to the same basic models prior versions used since it was more stable approach. Also note that this is a breaking change for "DS Player", it will no longer function as it relies upon that deprecated feature to be used by the PVR Client. Version 1.1.1 is the last build for DS Player (sorry!!)

Detect and remove MPEG-TS SCTE PIM (0xC0) table when inserted before the PMT (0x02) table in the same PSI packet
This is the big fix everyone has been hoping for, myself included. This change examines all mpeg-ts packets as Kodi reads them and detects the packets giving us problems with streams starting but never playing. I plan on putting the nitty-gritty in the Wiki, but the shorter version is that in North America, cable channels add information to indicate when local commercials can be inserted. If a channel chooses to combine this information in the same packet as the Program Map Table (PMT), ffmpeg, the decoder Kodi uses, can't handle it - it's a bug. This causes ffmpeg to examine the streams to figure out what they are; if this takes too long it gives up. The change I made simply removes the 'bad' data from the packet before sending it to Kodi, and seems to have completely resolved the problem!

Add "DVR stream read operation timeout (milliseconds)" advanced option
New tuning option. This controls the amount of time to wait for stream data to be available before returning a zero to Kodi, which generally stops the stream -- in the Kodi log you'll see something like "stream stalled". The default is 2500ms. The old non-configurable default was 5000ms. In reality if you can't stream a single packet of data in 2.5 seconds your experience is already pretty miserable, but you can tinker with this if you'd like.

Add "DVR stream read operation minimum size" advanced option
New tuning option. The idea behind this one is for the folks that report streams start and then buffer fairly quickly, then are fine. That indicates a condition known as starvation, there isn't enough data coming in fast enough to satisfy Kodi. By telling the PVR to wait until more data is available this condition might be avoided. Note that in reality this is more of a "hint" than a hard limit, and is adjusted on the inside to ensure whole mpeg-ts packets are returned. If you set this too high, it will take longer for your live streams to start and longer to recover after a seek operation. The old value here would have been zero, the new default is 1KiB, and you can tinker with this too to see if helps anything for you.

Add "DVR stream ring buffer size" advanced option
New tuning option. Not complicated, this is the amount of memory used as a ring buffer to hold the stream data as it comes in. It may be tempting to increase but in reality has little value if you do; the best case I could make for a larger buffer is that micro-seek requests from Kodi (which happen a lot more than you'd expect) may be able to be fulfilled with the data already in the buffer. The old code was fixed at 4MiB, which is still the default now. To get a read on how much that is in reality, 4MiB equates to about 2 seconds of an HD stream. Even quadrupled to 16MiB, you're still not going to get a hit for a -10 second video seek. I suppose if you play a lot of SD content maybe it's useful to crank it up, but honestly 4MiB should be quite sufficient.

I will make every attempt to get the Wiki documentation fully updated ASAP.

Enjoy!!

[RockerC]

Hi all! I wanted to let you folks know that I have written a Kodi PVR Client for the HDHomeRun DVR service. I think it works pretty well and have been using it exclusively for a month or so now -- it has even gained the holy grail of "WAF" in our house. I had to dump Windows Media Center once and for all, and (sorry SD) we really didn't like the official HDHomeRun app/plugin options available to us.

This is different than the official Kodi HDHomeRun PVR Client -- this specifically works with the DVR service, and exposes as much of that back end as I deemed possible. If you don't subscribe to the DVR service or have older tuner device(s) that don't work with the DVR service -- this is not for you -- use the official Kodi HDHomeRun options available to you.

@djp952, why is this/your unofficial Kodi PVR Client for HDHomeRun DVR not discussed in the official Kodi community forums at kodi.tv? I've been a relativly active user on the Kodi community for years and I first learned about your PVR client addon today! Any chance that you could start a new forum thread for it there so more people in the official Kodi community at kodi.tv can get to know about it?

https://forum.kodi.tv/forumdisplay.php?fid=250

The only other PVR API client addon for HDHomeRun (which is called "HDHomeRun PVR native addon") is also an 'unofficial' PVR API client for Kodi and looking today it seems to be abandoned or at least development for it have stalled. Discussions of all HDHomeRun addons, unofficial or not, are of course more than welcomed on the official Kodi community forums at kodi.tv!

https://forum.kodi.tv/showthread.php?tid=246658

As you probably know, the official HDHomeRun for Kodi is a python script based addon which does not use Kodi's PVR API, and IMHO it sad that SiliconDust spends time/money on developing that addon for Kodi when it does not even use Kodi's own PVR API, as they will never have a real PVR addon for Kodi until they uses PVR API (which python addons cannot do today).

PS: Should note that I am not personally a subscriber of SiliconDust's HDHomeRun DVR service, and personally I would prefer if a PVR client addon for HDHomeRun could give me an option simply record/save the streams locally on my Kodi devices (direct attached USB harddrives on Linux and Android) without me having to setup a backend at all. As requested here => https://github.com/kodi-pvr/pvr.hdhomerun/issues/7