(OLD) Unofficial Kodi PVR Client for HDHomeRun DVR subscribers

[djp952]

Its an Nvidia Shield using your latest APK. All hardwired 1000T networking. The only thing thats different on my end since this started happening is I did have AT&T fiber internet installed but its not actually plugged into my system yet. Its only running as a seperate WiFi network inside my house. I wont be integrating it until this coming weekend so let me do that and report back. I couldnt imaging that this would affect things but you never know. And never a reason to apologize. I just threw the statement out there just in case anyone else was seeing the same thing before I investigated it any more deeply and submitted logs. I know my post was not helpful at all in helping solve the issue!

No worries! Are you running the Leia or Krypton APK? Leia is behaving badly for me on the Shield. I tried the latest nightly APK and it was better in places, but still problems. I can toss out an updated Leia APK against that nightly if you want to try it, it's not a problem, but I don't think it really fixed anything satisfactorily.

My recent spelunking into Leia is leading me towards it not finding the PTS (timestamp) it expects for the audio stream, and a recent code change they made to "pause realtime streams instead of flushing the buffers" may be related. For that, what I'm seeing on the latest nightly kinda matches what used to happen in Krypton is a stream isn't marked as realtime, it pauses for a bit then resumes (as opposed to showing the buffering circle on Krypton). It's odd that it doesn't happen if you enable tuner-direct streaming, but as mentioned in the past I saw that the streams are a little different for some reason. I would expect SD to buffer/retransmit the stream straight from the tuner, but they seem to have a reason to do some level of processing. Mine is not to reason why there - they are the gurus!

You know what's funny, the wife and I were watching TV about an hour ago (Krypton/Windows) and the damn thing buffered for absolutely no reason I think it's Karma biting me in the rearend for being slightly annoyed last night for no good reason!

Let me know if you want to try a "1.3.4a" against the nightly I was using, it really only takes about 30-35 minutes to put a new build together if there are no code changes to specifically test.

edit: what I was looking into last night and tonight is to see if there is a reasonable way to report stream statistics (speed, buffer fill %, etc) non-invasively for these difficult to diagnose platforms. I'd like to know if Kodi is still asking for data or not but in such a way that you guys could also use that. Spamming the Kodi log with messages isn't super useful and slows things down too much. I was thinking of maybe hacking the signal strength UI indicators in Kodi to display fake information we could use for diagnostics.

[riviera128]

Hey, just some feedback on version 1.34...

No more crashes/reboots on Pi 3B+ units running OSMC or Raspbian with version 1.34! Also, some other annoyances have gone away- namely sporadic short stretches of garbled live TV and those error messages on the client startup stating that live stream failed when "continue last channel on startup" is selected. Thanks again so much for the update!

On an unrelated note- a question:
Let's say I'm watching live TV and halfway through the program I'm watching (which I have been watching from the beginning) I decide that it is worthy of recording. If I go into the EPG and navigate to the current program and hit record, the recording starts at that moment, not the beginning of the program. Is there a setting or method which allows recording the current program (in progress) from the beginning? Just curious, since it appears that the DVR service keeps the live tv recordings from about the past hour (maybe more) in the Live TV folder in the HDHomeRun directory.

[Hardax]

Its an Nvidia Shield using your latest APK. All hardwired 1000T networking. The only thing thats different on my end since this started happening is I did have AT&T fiber internet installed but its not actually plugged into my system yet. Its only running as a seperate WiFi network inside my house. I wont be integrating it until this coming weekend so let me do that and report back. I couldnt imaging that this would affect things but you never know. And never a reason to apologize. I just threw the statement out there just in case anyone else was seeing the same thing before I investigated it any more deeply and submitted logs. I know my post was not helpful at all in helping solve the issue!

No worries! Are you running the Leia or Krypton APK? Leia is behaving badly for me on the Shield. I tried the latest nightly APK and it was better in places, but still problems. I can toss out an updated Leia APK against that nightly if you want to try it, it's not a problem, but I don't think it really fixed anything satisfactorily.

My recent spelunking into Leia is leading me towards it not finding the PTS (timestamp) it expects for the audio stream, and a recent code change they made to "pause realtime streams instead of flushing the buffers" may be related. For that, what I'm seeing on the latest nightly kinda matches what used to happen in Krypton is a stream isn't marked as realtime, it pauses for a bit then resumes (as opposed to showing the buffering circle on Krypton). It's odd that it doesn't happen if you enable tuner-direct streaming, but as mentioned in the past I saw that the streams are a little different for some reason. I would expect SD to buffer/retransmit the stream straight from the tuner, but they seem to have a reason to do some level of processing. Mine is not to reason why there - they are the gurus!

You know what's funny, the wife and I were watching TV about an hour ago (Krypton/Windows) and the damn thing buffered for absolutely no reason I think it's Karma biting me in the rearend for being slightly annoyed last night for no good reason!

Let me know if you want to try a "1.3.4a" against the nightly I was using, it really only takes about 30-35 minutes to put a new build together if there are no code changes to specifically test.

edit: what I was looking into last night and tonight is to see if there is a reasonable way to report stream statistics (speed, buffer fill %, etc) non-invasively for these difficult to diagnose platforms. I'd like to know if Kodi is still asking for data or not but in such a way that you guys could also use that. Spamming the Kodi log with messages isn't super useful and slows things down too much. I was thinking of maybe hacking the signal strength UI indicators in Kodi to display fake information we could use for diagnostics.

I am using the Leia APK as I've been using the Netflix add-on that only works in Leia.

I would be happy to try a new version based off of a nightly.

For what ever reason, tonights live TV viewing seems to be going a lot better. Ive gotten some buffering pausing but tonight the pause has not caused the audio out of sync like it has been lately.

[djp952]

Hey, just some feedback on version 1.34...

No more crashes/reboots on Pi 3B+ units running OSMC or Raspbian with version 1.34! Also, some other annoyances have gone away- namely sporadic short stretches of garbled live TV and those error messages on the client startup stating that live stream failed when "continue last channel on startup" is selected. Thanks again so much for the update!

On an unrelated note- a question:
Let's say I'm watching live TV and halfway through the program I'm watching (which I have been watching from the beginning) I decide that it is worthy of recording. If I go into the EPG and navigate to the current program and hit record, the recording starts at that moment, not the beginning of the program. Is there a setting or method which allows recording the current program (in progress) from the beginning? Just curious, since it appears that the DVR service keeps the live tv recordings from about the past hour (maybe more) in the Live TV folder in the HDHomeRun directory.

In this case, all I am able to do is make the request to the RECORD engine via the web services and then "poke" it so it goes out and finds the new request. The ability to convert an in-progress live stream to a recorded stream isn't currently possible (or not documented if SD does have that capability). This would be a question for SD, if they can implement it we should be able to leverage it here.

I don't poke around in the HDHomeRun share, everything is done with the web services exposed by the backend and the RECORD engine. All I keep in memory is a couple megabytes of recent data to act as a buffer and to allow for small micro-seeks to be satisfied without stopping and restarting the stream. Note on that - it turns out the micro-seek thing was/is only really a problem on Windows, there was some bug that Kodi fixed in Leia with certain hardware now the seeks are so fast I think the complexity involved with trying to seek within the buffer isn't even really worth it anymore It does save a few milliseconds here and there!

[djp952]

I am using the Leia APK as I've been using the Netflix add-on that only works in Leia.

I would be happy to try a new version based off of a nightly.

For what ever reason, tonights live TV viewing seems to be going a lot better. Ive gotten some buffering pausing but tonight the pause has not caused the audio out of sync like it has been lately.

There is a new nightly that actually hits all the Android and UWP targets for a change, so I've rebuilt against that. There is one new commit I see out there that *isn't* in the latest nightly that looks pretty relevant to the problem at hand, but I guess we'll find out next build? bleeding edge is fun!

I still have to update the Leia Android build environment to use clang instead of GCC to follow suit with Kodi, but I don't think there are any real concerns there at this time. I could be wrong, of course

FWIW, this build solves nothing for me, but your mileage may vary. At minimum it seems to work....

Leia 1.3.4a:
https://github.com/djp952/pvr.hdhomerun ... eia-1.3.4a

[mkbrimley]

GANG -- Version 1.3.4 *does* fix (at least some) Linux/OSMC/etc crashes with corrupt streams! So far I've gone through 3 of the 5 corrupt recordings I still have from you guys on OSMC and they all work!

I am not silly enough to think this solves every single one of the problems we've seen but it's looking really good for a 'most of them' statement here. I've sent some PMs to users that have been specifically affected and sent me the file(s), forgive me if I didn't hit you specifically yet. I may have lost who the file came from, or I haven't gotten around to that file yet.

I'm both thrilled and ashamed at the same time right now. I'd really like to know if the folks having crashes, specifically those on OTA where corrupt streams are much more likely, have any better luck with v1.3.4. I'm going to hook up an antenna later and see if I can get OSMC to crash out or not.

edit: I found no immediate problems with ANY of the mpeg files I have from you guys. I hope I didn't forget what to look for - lol.

This whole event may be worthy of a commemorative v2.0 or something to celebrate. Perhaps another new thread? This one got ridiculously long again.

I just wanted to chime in and say that this fixed my issue! I no longer have the freezing problem when I rewind DVR'd or live TV streams on my Shield. Thanks so much for fixing this!

[riviera128]

In this case, all I am able to do is make the request to the RECORD engine via the web services and then "poke" it so it goes out and finds the new request. The ability to convert an in-progress live stream to a recorded stream isn't currently possible (or not documented if SD does have that capability). This would be a question for SD, if they can implement it we should be able to leverage it here.

I don't poke around in the HDHomeRun share, everything is done with the web services exposed by the backend and the RECORD engine. All I keep in memory is a couple megabytes of recent data to act as a buffer and to allow for small micro-seeks to be satisfied without stopping and restarting the stream. Note on that - it turns out the micro-seek thing was/is only really a problem on Windows, there was some bug that Kodi fixed in Leia with certain hardware now the seeks are so fast I think the complexity involved with trying to seek within the buffer isn't even really worth it anymore It does save a few milliseconds here and there!

Ok, thanks for the info!
And thanks again for 1.34!

[jasonthemann]

Question, is anyone using this plugin with the HDHomerun Quatro and Premium TV service? I currently use it with an HDHR Prime, but I am thinking about cutting the cord and would like to keep the same layout and functionality. I would appreciate any feedback. Thanks in advance.

[ringerlin]

I'm using Duo with Premium service. This pvr addon is working great with it.

[jasonthemann]

I'm using Duo with Premium service. This pvr addon is working great with it.

Thanks for the response.

[djp952]

Have an enhancement idea I wanted to run by you guys before I dive into it. I want to make sure this won't adversely affect anyone:

https://github.com/djp952/pvr.hdhomerundvr/issues/42

Given the prevalence of people that have the problem with HTTP discovery not finding their RECORD engine, I think it would be nicer to add some logic to fall back to broadcast automatically.
Here's my current plan:
If HTTP discovery is ON and no RECORD engine was found, try a broadcast discovery
If broadcast found a RECORD engine, auto-enable the broadcast setting and notify the user
If broadcast did not find a RECORD engine, do nothing. Discard the broadcast discovery results and leave HTTP ON
I think this is a pretty good way to handle it, it should help the people that first install this thing and have to research out or ask why it's not working, while at the same time not interfering with the people that legitimately don't have a RECORD engine running -- they should see no difference at all.

The HTTP discovery not listing a RECORD engine has been such a problem all along for many people (still unsure why that would be), so my idea here is to finally just deal with it. It wouldn't be hard to just execute a test broadcast discovery and see if that found a RECORD engine, and switch you over to that mechanism automatically.

I would notify you with a message of some kind (probably cryptic, you know, developer-speak), and you would only see that message once since the setting would be switched on you after that. I would never change your settings without letting you know, that's just bad form.

This test/switch/message would only be done at startup, I wouldn't put something in there that would interrupt you while you're happily watching your favorite program.

I think the only real annoyance factor would be if your HTTP discovery has been happy all along and then didn't work once for some reason while you're firing up Kodi. Today you just wouldn't see any recordings/etc, and probably just restart Kodi and forget all about it if it worked the next time. With this change, you would be switched to broadcast discovery (and notified!) and you would have to manually go in and switch back to HTTP if it was indeed a transient condition.

Thoughts? Concerns? Risk vs. Reward sound OK on this?

edit: Wanted to give props to user jlippold for not only using the PVR addon, but for giving me pause to think about a better way to handle this for everyone. I don't want anyone else new to be frustrated by this particular quirk.

[signcarver]

In my opinion any app or server based system should use broadcast discovery... the only time http discovery would be a better way is if they have multiple subnets or poorly configured networks (bad masks) (and I prefer for such systems to not do such discovery allow manual input/configuration). And even then your isp can't be using a carrier grade nat or frequently change you ip (the http service only gets updates every 8 hours, while broadcast is "now").

Http discovery is only meant when one can't perform a broadcast such as from a remote hosted web page (unlike a locally, same subnet, hosted page where that server can do the discovery). Its beginnings actually began many years ago with the SD app on samsung when samsung wouldn't give the app that access to the network so SD had to "host" the ip addresses of the tuners (I forget if it wouldn't allow broadcast, or wouldn't allow knowing the local subnet).

[riviera128]

Would it be possible for an option just to be able to input the IP address of the device running the record engine?

My record engine is on a server with a static IP, but I would think the IP address of most people's record engine device isn't going to change, is it? Even without a DHCP reservation, won't most routers keep the same IP for a given device's MAC address?

Just a thought as another option for situations where the record engine isn't discovered.

[signcarver]

One potential issue with that is the port of the engine in addition to the ip address... it might change if restarted unless you set a static port for the dvr service (config file for linux, registry entry for windows).

[riviera128]

If I remember correctly, there is a port defined by default in the Hdhomerun config file (65001 I think) for discovery.

I just thought allowing the manual setting of the the IP of the device running the record service might be a possible solution, as I know that other frontend-backend systems either allow or require you to enter the IP address of the backend.