Unofficial Kodi HDHomeRun DVR PVR Client

[djp952]

I have good news for the Windows crew. The resolution to the above ^^^ issue has so far (knock on particle board, cross your toes, etc) solved all my Windows issues here! Many thanks to FernetMenta of Team Kodi for the fix.

Solving all my problems was kind of unexpected, since this particular issue has been around since Kodi 18.0, but after two solid days of use nobody here has seen any glitching/buffering at all. I'm still on the fence about blaming Windows 10 1909 for being a player in all of this, though. If the problem recurs here, I'm wiping the machine and going back to 1903. I did bounce the RECORD engine before re-testing as well, and haven't been hitting it while debugging things, but since only Windows has seemingly been affected and I also run Android and Linux all the time I really doubt RECORD has anything to do with it.

Over the past couple months, I have also been working with gibxxi to resolve a couple problems with audio-only streams, which are more common overseas on the DVB systems. So in total we have three audio related fixes in the pipeline. All should be in the most recent or next Matrix nightly build, and hopefully will all be accepted to go into a Leia 18.6 if there is one.

I had to build a version of Leia 18.5 to test these (obviously), so for the Windows folks that are running the Desktop x64 version of Kodi 18.5 specifically, you are welcome to grab my kodi.exe to see if it solves any of your problems. I'm sorry that I'm not really set up for building Kodi for any other platforms, nor would it be appropriate for me to start cranking out Kodi forks.

Fixed things:

• Kodi may crash and/or lock up when playing an audio-only MPEG-TS stream if a visualization is enabled
• "Resume From" on an audio-only MPEG-TS stream (typically a recording for us) will fail
• 1-2 second lapse in audio playback when stream format changes, also can cause a ton of audio sync errors in the logs

You can get the .EXE here: https://1drv.ms/u/s!AgEGEEVzGNq-jIUAK4g ... g?e=NfsJS4
File: kodi-18.5-release-audiofix3.zip

To use this, rename your local kodi.exe to kodi.exe.old or something and simply replace it. You do not need the .PDB file, but if you had downloaded the real kodi.pdb for whatever reason, rename and replace that as well. If you run into ANY problems, just back it out.

Happy remainder of the Holidays to you all, see ya next year!

[cncb]

The resume point does not seem to be saved when watching an in-progress recording (after stop, can only play from the beginning). If the recording is completed, the resume point is saved correctly. This is on an NVidia Shield client.

[djp952]

The resume point does not seem to be saved when watching an in-progress recording (after stop, can only play from the beginning). If the recording is completed, the resume point is saved correctly. This is on an NVidia Shield client.

I've looked into this before, and while the exact reason escapes me at the moment, it's that Kodi isn't asking the PVR to set the position for in-progress recordings. It was something like either it doesn't call the function if the stream is "realtime", or it was how the recording was launched from the UI.

Did you start the recording via Recordings, or by playing the channel and being prompted to switch to the in-progress recording?

I'll get the exact reason for you this evening. It wasn't too hard to track down.

[cncb]

Did you start the recording via Recordings, or by playing the channel and being prompted to switch to the in-progress recording?

Started from Recordings. Thanks.

[djp952]

Sorry for the delay in response. The problem with in-progress recordings is that I'm sending Kodi a legitimate start time instead of zero, since they are detected as real-time, so for timeshifting to work right it needs the accurate information. The call to set the resume point is only made if the start time is set to zero.

Things have changed since I first "fixed" this, I think I can re-fix it in such a way that it will work for all programs launched from Recordings. I just need to test Kodi's behavior with seeking around on these types of streams, it's always a little bit of a cat-and-mouse game

Hang tight, I may have something for you relatively soon to try out.

edit: OK, it's fixed. Unfortunately I also found that the relatively new option to use the Original Air Date as the Recording Date for Recorded TV was fundamentally flawed and was actually screwing this up. Always unintended consequences That option will need to be removed in favor of trying to do something in Kodi itself; currently Kodi doesn't have a place to store the original air date for recordings.

edit 2: New build looks good, and I try to send out any release with a bug fix ASAP, but ran out of time tonight working on a PR for Kodi. I anticipate tomorrow night (1/8/2020) for a new release that addressed the underlying issue.

[djp952]

Unfortunately a bad thing happened to CubsWin's feature in this one. Sorry - I liked it too, but it caused a problem. More below....

Version 3.1.1 (2020.01.08)

• (Windows) Use a BELOW_NORMAL thread priority for the background task scheduler
• (Leia/Matrix) Remove obsolete MPEG-TS packet filtering implementation
• (Leia/Matrix) Fix bug preventing recording resume position from being set if recording is in-progress
• Remove "Use Original Air Date timestamp for Recorded TV programs" setting

Downloads:

• Kodi 17 "Krypton" : https://github.com/djp952/pvr.hdhomerun ... di-Krypton
• Kodi 18 "Leia" : https://github.com/djp952/pvr.hdhomerun ... -Kodi-Leia
• Kodi 19 "Matrix" : https://github.com/djp952/pvr.hdhomerun ... odi-Matrix

(Leia/Matrix) Remove obsolete MPEG-TS packet filtering implementation
Those of you that have been using this since before Leia may remember the problem where some Live TV channels just wouldn't start. It took a while to track down and fix, but it was a problem with ffmpeg where it couldn't handle certain MPEG-TS streams where an SCTE PIM table was inserted into the PMT (so many abbreviations, I know). I fixed it by removing the data ffmpeg couldn't handle. However, I was looking for things to clean up and discovered that ffmpeg actually fixed this, and Kodi has been using the fixed version since Leia "Alpha 1". For Leia and Matrix, now there is no reason for me to be mucking with the MPEG-TS stream at all, so I removed that code. It was just wasting time and causing some unnecessary restrictions like forcing Kodi to always read full MPEG-TS packets so I could keep track of them. The filter is still in Krypton.

(Leia/Matrix) Fix bug preventing recording resume position from being set if recording is in-progress
This is a fix for the problem reported by cncb. In Leia/Matrix, I have to tell Kodi what the boundaries of the in-progress stream are for timeshifting purposes, and there are a couple rules to follow -- a recorded stream must have a start time of zero, being the one in play here. I was using the "realtime" indicator for the stream to decide if I should start at zero (Recorded) or use the wall clock (Live). In-progress recordings are "realtime", in that they do not have a known length and the reported end time cannot exceed the wall clock (you can't seek into the future). Kodi determines if it should request saving the resume position or not based on the start time. If it's zero, it will ask, otherwise it won't. So the fix was to essentially just keep track of if it was opened as Live or Recorded, and send the correct values.

Unfortunately, there was another bug I noted while getting that to work ...

Remove "Use Original Air Date timestamp for Recorded TV programs" setting
I am sorry to CubsWin and anyone else that was using this option, I liked it too. It needed to be removed because I need to know things like the actual recording start time using just the data being passed back into the PVR by Kodi. When the recording start time is modified to the original air date, it screws up timeshifting. Kodi still works, but it can get wonky. For something like an in-progress recording the behavior you should see is that you can seek no farther than the wall clock time, and the length of the recording should be continually increasing as time passes. What ended up happening is that the start time was zero, as needed, but the end time could have been in the distant past.

This one is a bummer, I understand. However -- not to be completely thrwarted, I have issued a Pull Request for Kodi Matrix that adds a new "firstAiring" field to the recording data https://github.com/xbmc/xbmc/pull/17153, and from there perhaps we can work on making this something Kodi can do on it's own. The change will be for Matrix only, and it's on hold since it was a breaking change to the Kodi PVR API. Once it's mainlined, I can see about working on and/or requesting a way to show this/sort by this instead of just using the recording time.

So there we have it, another relatively unremarkable set of changes that I managed to incessantly ramble on about I like you guys and gals to know what I'm thinking, especially if things have been taken away.

Enjoy!

[ddejager]

I like you guys and gals to know what I'm thinking, especially if things have been taken away.

The programmer givith and the programmer taketh away....Seriously, thanks again for all your thought and work! I think that pausing and resuming a live show at the same place is more important than the original air date option (which I, too, liked and used).

[djp952]

There is a still a way to pull it off, I can make a trip into the PVR database to get the information again, but it's a little more wonky than I would like. I would also have to figure out a better way to deal with the fact that the original air date is a date, not a date/time. You probably noticed that when enabled, all your recordings had a GMT adjusted midnight timestamp Like for me, in Eastern Time (US), everything said it started at 7:00PM

Plenty of version numbers left!

[djp952]

Would you guys be OK with a new version of "Use Original Air Date timestamp for Recorded TV programs" that may cause a (very likely unnoticeable) delay when starting a recorded stream and would always report the time component as 12:00 AM? I think I would limit this to just Leia since Krypton is all but dead at this point and I'm hoping to attain in-built support for it in Matrix.

I feel kinda bad about taking this option away, but as ddejager noted (and I completely agree), proper "core functionality" has to take precedence over optional features. I'm actually surprised that nobody (including myself) hadn't noticed the problems that enabling the setting would cause

[signcarver]

But it is an "optional" feature thus one would have the choice of one or the other.

Personally i absolutely hate resume features (even on something like netflix) as i prefer the "recap" getting a little bit each click forward. I also don't think it works well unless on a per user basis.

[djp952]

It would absolutely be optional, if it even works right to begin with. I do my best to ensure that the "out of the box" experience is as close to ideal as I can make it ; Honestly adding this option back would be a big hack job overall, which is why I'm pursuing the Kodi PR course instead.

[cncb]

(Leia/Matrix) Fix bug preventing recording resume position from being set if recording is in-progress

Thanks for this. I will give it a thorough testing this weekend with the NFL games.

[CLorox]

Is there a plan to make it into the official Kodi UWP Xbox One release? I would love to see this add-on make it to Kodi on the XB1 in my living room, but I don't want to have to put the console in Developer mode to do it.

[djp952]

Is there a plan to make it into the official Kodi UWP Xbox One release? I would love to see this add-on make it to Kodi on the XB1 in my living room, but I don't want to have to put the console in Developer mode to do it.

Kodi UWP currently can't support installation of binary addons that didn't ship with the application, so it would have to be an official Kodi addon, maintained by them.

As time allows, I was going to start trying to port the core functionality in this addon to the official pvr.hdhomerun so it can do much of the same, if they accept it. I took this project in a particular direction that wouldn't bode well as an in-box addon for Kodi. Things have changed much over three years, and now Kodi can do all of the tricks needed to work with the HDHomeRun DVR so it's just about the amount of work involved.

Short version is "no", sorry

If Microsoft ever relaxes the restriction on not being able to load DLLs that didn't ship in the .APPX it would all work just like desktop Windows. Sadly UWP seems to be on the way out so I don't think we'll ever see that changed, nor do I think Kodi would ever adopt a more Microsoft-y way of doing things (addons via the MS Store), and from my research in the past that wouldn't work too well for something like a PVR anyway.

I love Windows to death, but despise UWP. I hope XBox Series X has different options for development.

[CLorox]

I appreciate the detailed and insightful reply. That is a shame about UWP support waning. Regardless, your addon is fantastic. Thank you for your contribution!