Extended Channel Names Not Displayed In Kodi (18.0 - RC3)

[djp952]

Extended Channel Names Not Displayed In Kodi (18.0 - RC3)

[djp952]

Hi! I have zero experience with anything outside of the US (sorry!), can you help me out a bit more? If you go to your HDHomeRun tuner web page and select "Channel Lineup", are those the descriptions you want to see?

How it works today is that I use those channel names (the ones from the tuner) until / unless they become available via the EPG, then it will use those instead. It would not be hard to allow you to choose to keep the ones provided from the tuner, it shouldn't really affect anything since the channel numbers are used for things like scheduling recordings and whatnot.

If you see the names you want on the tuner page, let me know and I can add an option for you to keep those. Actually, I may as well do that anyway, it certainly wouldn't hurt :)

Thanks for using the PVR! I've never actually heard from anyone outside the US that used it. Other than this, does it generally work for you?

[gibxxi]

Hi,

If you want, I can provide you with screenshots of what i'm seeing in the SiliconDust App versus what I'm seeing in Kodi.

As for general functionality, Playing channels works fine. Did have a couple of minor stutters during playback last night, but it wasn't a major problem, and at this early stage, can't put that down to your add-on with any great degree of confidence anyhow. I will monitor it going forwards.

The system used for testing was a full-sized HTPC based on a Core-i5 4670K with a GTX950 graphics card and 16GB RAM, so I think it's more than capable of handling this. I'll follow up this post with some screenshots when I get a bit more time.

Essentially, the way OTA updates work in the UK, is that each transmitter has 4-5 muxes, and the channel names (and numbers) are broadcast separately to the channel streams, but on the same mux as the actual streams as far as I'm aware. This information contains the (full) extended channel names, where as the streams only contain abbreviated channel names, which are limited to about 4-8 characters. This makes it difficult to decipher what channel your looking at in Kodi versus the "full" channel names the SiliconDust app is able to decipher from the EPG data / mux data.

P.S: I did have a recording event i added that never started, but my NAS (QNAP) was setup with a QNAP Add-on that "pulled" recordings from the HDHomeRun hardware, as a pose to Kodi "pushing" the recordings via SiliconDust's software, or via Kodi. I've reverted back to stock config, and will try setting another timer and see what happens. I am a fully-paid-up DVR subscriber btw.

[gibxxi]

It would also be beneficial to us Kodi / GitHub users if the add-on content was in the root folder of your GitHub project, so we can sync changes / updates direct to Kodi via that, rather than downloading periodic releases. Not a big issue, but this would enable us to update changes / bug-fixes on the fly without having to wait for the next point release.

As it is, with the add-on content in a second-level subfolder, under the project folder Kodi ignores any add-on content in sub-folders so I can't use GitHub / SyncBackPro to sync your add-on directly to my Kodi install.

Not a big issue, but I am doing the above with a couple of my other Kodi add-ons that are "in development" and thought it was worth mentioning (as a potential feature request).

[gibxxi]

Here's a screenshot of the (extended) channel names, as SiliconDust's settings app sees them (from OTA EPG / Mux data):

https://imgur.com/nwwR8bm

And here's the first two pages of channels, as they appear with your add-on, within Kodi

https://imgur.com/u65vnpJ

and:

https://imgur.com/OupjRvf

If you would like me to also provide screenshots of the channels, as they appear in Kodi with Zoltan Csizmadia's HDHomeRun PVR add-on for Kodi (Which doesn't contain DVR / timer / recording functionality) I can do so, but i'd have to disable / remove yours and enable his first.

[gibxxi]

...Ignore the fact Channel 4 appears twice. The second one is from the Wenvoe (Welsh transmitter) that is farther away, to the north-west of my location, versus the closer Mendip transmitter (North East) so sometimes I get duplicates. The HDHomeRun is pretty good at biasing the channel list with the strongest signals first, but it doesn't always get it perfect. It's just a caveat, us down in Somerset (SW UK) have to put up with.

:)

[djp952]

I got ya. It was indeed trivial to add.

edit: Sorry, it's not Kodi it's the tuner truncating it. Hopefully not an issue for your tuners, ATSC channels have sucky metdata :) The truncated descriptions I see match what I see in the source data. False alarm.

before:

after:

[djp952]

      It would also be beneficial to us Kodi / GitHub users if the add-on content was in the root folder of your GitHub project, so we can sync changes / updates direct to Kodi via that, rather than downloading periodic releases. Not a big issue, but this would enable us to update changes / bug-fixes on the fly without having to wait for the next point release.

As it is, with the add-on content in a second-level subfolder, under the project folder Kodi ignores any add-on content in sub-folders so I can't use GitHub / SyncBackPro to sync your add-on directly to my Kodi install.
Not a big issue, but I am doing the above with a couple of my other Kodi add-ons that are "in development" and thought it was worth mentioning (as a potential feature request).

I was thinking of setting up a Kodi repo at some point so the PVR can auto-update, if that's what you mean? Now that Android devices are valid targets for binary addon updates, it seems like the best plan.

[gibxxi]

I'd be able to work with that m8. If anything that would be easier (and better) than GitHub syncing as it is a bit of a kludge, even though it works.

I often forget to keep track of updates to software since I have so much I have to keep track of software-wise, so any automated / semi-automated solution you could provide would be a enormous help. 3rd party repos are not an issue for me, I already use several for other custom add-ons, made by community members (nothing illegal I might add, I don't use piracy add-ons in Kodi).

Dan / Gib.

[gibxxi]

With regards channel names, they're not just truncated. There's no spaces, and they're all in "All Caps" so I'm convinced they are coming from different sources on the HDHomeRun hardware.

Obviously, DVB-T/T2 (which is what we use) is different to ATSC (what you guys in the US use) but I'm assuming there should be something in the API SiliconDust provide that solves the issue for both cases?

Also, it's not just the UK. All of Europe uses DVB-T/T2, so if this add-on of yours becomes popular with HDHomeRun owning Kodi users like myself (No reason why it shouldn't), this issue will undoubtedly come up again I think.

[djp952]

I think this is what you want, the descriptions in Kodi will match what you see in HDHomeRun Setup and the HDHomeRun App (confirmed both). There are only two places I can get it from - the EPG or the tuners, the new option works and allows you to use whichever you prefer! I've defaulted this to off, since this is the first time this has come up and the bulk of users are here in the US and as we've noted - our metadata is crap :)

One note about this -- you will still get the EPG (short, like "WBFF") channel names for recordings, provided the HDHomeRun RECORD engine isn't set up differently for DVB. The channel names I display for Recordings come from the recording metadata, it tells me what channel name to display, I don't do any type of lookup there. It's actually encoded into the start of the .MPG file, you can pop one open with a binary editor and see the metadata SD encodes (and change it, too).

I should get this out to everyone tonight, just doing some Leia housekeeping first, let me know if you think another option to try and marry the recording channel number back to the lineup to get the current channel name is warranted.

[gibxxi]

No, I'm fine with the truncated names in recordings, personally. Once an item is recorded I'm not really bothered what channel it came from. But browsing / watching TV is a different matter. I don't record much anyhow. Got an issue where the timer(s) set are working, but nothing ever gets recorded to the NAS even though the proper "recording started" and "recording completed" messages appear in Kodi.

This may be a permissions issue with the NAS, and it may be that the "HDHomeRun" share isn't on the first HD partition, but the second. I will have to do some more testing with this and check what's being written to the log. It used to work when my QNAP only had a single partition for data, but I've recently taken advantage of QNAP's advanced partition-management structure in order to segregate apps from media and data for security as well as fragmentation prevention.

Given the flakey nature of recent QNAP firmware it would not surprise me one little bit if these changes are causing a problem.

[djp952]

OK. v1.3.8 is "live" for the grabbing -- https://github.com/djp952/pvr.hdhomerundvr/releases

The new option is called "Use channel names from tuner device(s) in channel lineups". I suggest restarting Kodi after changing this so that the EPG will also get the new names.

I've only tested it on Windows, will link it up properly and announce on SD forum after I try at least a couple more platforms.

[gibxxi]

Roger that. Will give it a test within the hour.

Thanks for your efforts.

:)

[gibxxi]

Well I've installed the add-on, enabled the option & restarted Kodi as advised...

https://imgur.com/vkOQBkV
https://imgur.com/JljvrgJ

I think we can call this a success. Intriguingly, the startup channel scan seems a lot faster too. Before there was at least a .5 of a second between each channel appearing in the progress dialog at startup. It's now progressing MUCH faster.

Again, thanks for your efforts. Much apprieciated. Now to diagnose why nothing is being saved to the NAS when timers are set.

Dan / Gib.

[djp952]

Anytime! Glad it was something I could turn around quickly for you. When you get the NAS working (and if you're ok with it) I would love to get my hands on a short DVB based recording file to run through the PVR. Being unable to test DVB I just want to make sure that the MPEG-TS packet filter isn't going to do any harm. I filter out a specific piece of data that breaks Kodi and use the stream data to do the timeshifting indicators. From what I've read there should be no impact to DVB but it would be nice to be sure :). Let me know of any other concerns as well. Hitting up SiliconDust's forums regarding the NAS may also bear fruit for you as well. Happy Holidays!!

[gibxxi]

Once I get it working, I'll record a short program and upload it to cloud storage and send you a link. I'm pretty sure I can find something (10 mins or so) that will suit your needs. Like I said, I have had this working before with your add-on, but that was on Krypton.

The issue with the channel names also existed on Krypton too, I just assumed it was a minor bug down to the fact the add-on was new, and / or maybe I was doing something wrong at the time. I didn't spend a lot of time using it until I updated to the Leia Betas, and then suddenly realised I couldn't use Zuki, because it wasn't ready for Leia at that point.

I'll repost here as soon as I have something for you. It might take a while, as I have 3 systems all capable of running Kodi here, all of which also have access to the HDHomeRun device. For clarity, mine's a HDHR-Connect (HDHR4-2DT) running 20180817 firmware at this time. I think starting with the native SiliconDust Windows app first will be the best starting point and work from there.

Happy Holidays & many thanks for your quick solution.

:)

Dan / Gib.

[gibxxi]

@djp952:

Please check your Kodi forum PMs m8, I've sent you a link to an DVB-T mpeg sample via PM (assuming I've got the right username). Let me know if/when you have it so I can delete it from my cloud storage.

Cheers,

Dan / Gib.

[djp952]

Thanks again for the sample! I'm going to flag this particular issue as Closed to remove it from the list. If you have any other problems or requests please feel free to reopen or submit a new one!

[gibxxi]

Yep, no worries. I do have an issue where Radio channels and TV channels all appear in the "TV Channels" list, and the radio channels category (in Kodi) remains unpopulated, but this may equally be down to the way the HDHomeRun device works. Everything plays, so this is a minor issue, for which I may (or may not) raise a seperate issue for.

Thanks again for your help.

:)

[djp952]

Interesting. I wonder if your metadata provides any differentiation between "Radio" and "TV" channels? If it does, I could actually move those channels over into the "Radio" area of Kodi for you. Here in ATSC/QAM land the audio-only channels come through as TV channels, there is nothing in the metadata to indicate if they are audio only or not.

For what it's worth, it seems that folks in the US with truly audio only channels have problems with the PVR and/or Kodi. Unfortunately my provider (Verizon FiOS) doesn't give me any pure audio only channels to play with. I get "Music TV" channels, there is a static video image on the stream.

If you are game, I would like to have a look at your discovery data to see if it includes any flags we might be able to key off of here. The easiest way would be to grab the "hdhomerundvr-v1.3.db" file from the Kodi userdata/addon_data/pvr.hdhomerundvr folder, that will have all the most recent discovery information in it. Another way is to interrogate the device directly from a web browser:

http://my.hdhomerun.com/discover, then find and navigate to the "LineupURL" listed to the tuner. You get back a bunch of JSON text that lists the channel lineups and all the metadata we might be able to use. I'm hoping for some unique flag on the audio-only channels or even just a lack of a "VideoCodec" flag.

[gibxxi]

I believe our setup here in Europe is the same as yours. We use DVB-T/T2 (SD/HD) with DAB (Digital Audio Broadcast) for radio stations. However, quite a few (if not all) the DAB radio stations as broadcast from the local transmitter are MPEG2 Video streams, MP2 audio, with a static picture as you say.

In fact it's not 'static' per se, it's the same picture re-broadcast at the given frame rate of the MPEG2 video stream, so for us, 25/50fps. I've never seen the video data displayed in any Kodi add-on for the HDHomeRun, not yours or any of the others. I think this was also the case when I used a dedicated TV Card & later a dongle, in the HTPC. At least not through Kodi. Said static image is visible via my dedicated Set-Top-Box DVR though (Toshiba RDXV60).

If you still want the data, I'll conjure up the items you've already asked for with a sample recorded stream from a DAB station and post it up to cloud storage as before.

An interesting note is that traditional radio (AM/FM) is not broadcast by the local transmitter AFAIK. Instead, each town has 'repeater' transmitters that output AM/FM to that locality so far as i'm aware. Whether this has always been the case, or only since the 'Digital Switchover' I do not know.

[djp952]

Understood. I'm tinkering with a way to actually remove the video stream from these channels and move them into "Radio", but so far no success. The best I may be able to do is give you guys a way to manually specify that channels should be under "Radio" instead of "TV", but otherwise just leave them alone.

Seeing the discovery data would still be helpful, there probably isn't anything in there we can use to automatically move things around, but I can also ask SiliconDust if they would be willing to add something. I assume their EPG provider must know if a channel is TV or music in nature?

[gibxxi]

Rgr. I would say that if it ends up being a kludge to get it working, then leave it as it is. There are regional variations on broadcast radio channels in the UK, depending on the county you reside in (BBC Somerset, BBC London, BBC Wales, etc, etc. That's in addition to the regular Radio 1, 2, 3, 4, 5 Live, etc, etc.

At the end of the day, most skins provide the ability to hide unused home menu items, so it's not a major issue, just something that would be nice to have, like other TV cards, dongles, etc. The HDHomeRun is a bit unique in some aspects, but it's better than having to install TV reception hardware in all my networked PCs.

As I said, in Kodi, I never see the video stream in Kodi anyway. But I'm not sure if this is Kodi's doing, or that of the HDHomeRun device itself.

[djp952]

Sorry for the delay in getting back to you here. First, thank you for the sample file and your PVR database, it was great to be able to see what kind of data is being used for DVB, and really great to finally have an audio only MPEG-TS sample stream!

In regard to breaking out the audio channels, I don't see anything in the data that would allow me to automatically make them 'Radio' channels, but I tinkered around with a few things. I think it still falls under the category of 'kludge', but I'll propose it anyway to see what your thoughts are:

I could add a table that tracks whether or not a channel should be considered "TV" or "Radio", defaulting all channels to "TV" at first. I can add right-click context menu items in the Kodi Channels view(s) that allow you to specify something like "Set channel as Radio" and/or "Set channel as TV". Selecting this would move the channel to the correct view as is appropriate. I can also add a PVR level "Client Setting" to let you reset that table to make everything "TV" again. I think this would be a bit awkward to use but still operates within the normal Kodi UI elements. It's also tucked away enough that people that don't care to use it shouldn't be bothered by it.

There are, of course, challenges to deal with. The first concern I foresee is that I would need to be able to differentiate between TV and Radio Recordings. Kodi asks for those separately. As long as the channel number metadata from the DVR matches the current channels database it's all great, but if there is no match the Recording will have to go to "TV" and show up there. The other main challenge I can see is that if I put this information into the PVR database you would have to set it up on every Kodi device you have individually, and if you uninstall the addon the mappings go away on you.

I can't think of a good solution for the Recordings pitfall possibility, but to overcome the PVR database being local to the machine one thing we could do instead would be to define a file format and use a flat file the user can specify instead. If this file were in a shared location, all Kodi instances could pick it up and read it.

I'm game to pursue this, I've already gotten most of it to work offline, and I recommend as a first try going with the option to use the PVR database as opposed to a flat file on the network. It would allow people to try it out without any real impact to those who don't care, and hopefully gather some constructive feedback for possibly better or more seamless ways of doing this.

Let me know what you think -- I have plenty of disabled "music" channels to play around with. Kodi doesn't seem to care if they have audio/video or just audio - it plays them regardless :)

[gibxxi]

Hi djp952,

While the end goal is to have a PVR (DVR) system that works for all, It worries me that an excessive amount of "workarounds" (for want of a better word) may result in in issues further down the line. Because it's not only the vagarities of the HDHomeRun devices and the supporting firmware / software we have to deal with here, but also the inherent vagarities of Kodi itself.

Since the main issue here seems to be the playback of radio channels (at this time) and recording doesn't seem to be a problem, why not just examine Zoltan's HDHomeRun add-on and see how he manages to get his add-on to work without issue, and compare his code to yours to see if there's a way we can bridge the gap? While I'm not an advocate of plagiarism or anything of that ilk, it does seem to me like we might be trying to "re-invent the wheel" here.

From my position, which probably differs from yours by quite a margin, as a simple user, my goal is to have a DVR add-on for Kodi & HDHomeRun devices that just works. It plays back all the channels I can receive, and it records all the channels I can receive, and the likelihood for it breaking at some point down the line is low. It's not my concern (as a simple user) how we get to that point, just that we do.

I understand this is your project, and you want it to be the best it can be, and also code it in such a way that your happy with it, and can stand behind it as a developer. I totally understand that. And if we have to force a kludge to get to that point, I'm not against that either (assuming it doesn't have a negative knock-on effect). But I do think it may be an idea to reach out and see if there's a chance of pooling resources here. Both to achieve the desired end result, but to also avoid you having to put in a ton of work that is at best, a 50/50 as to whether it proves to be a long-term fix / solution.

Also, since I last messaged you, I stumbled across this thread on the Kodi forums...

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

...look somewhat familiar to you? The OP's issue is based on completely different usage scenario to mine, but, the effect he's seeing is exactly the same as what I am. So it may not be an issue with your add-on after all. I'd hate for you to do a ton of work, then have it turn out that the issue lied elsewhere all along. I can only report what I'm "seeing". But while I can put 2 & 2 together, I'm not a developer or a coder, and what I'm seeing, and believing may not exactly tally up with what's actually happening under the hood.

Lastly, there used to be a thread on the Kodi forums for this add-on. Is it still active? Because I can't seem to find it now. I think this discussion would be better served, being posted there, so other potential users of your add-on can add their input, as well as advertise it's existence and get more people (testers / users) on board. Maybe my situation is unique, maybe it's not, but as a single user, I am not a big enough user-base to judge the issues (or lack thereof) that may exist in this add-on, to be fair.

If we can get to a point where it works without issue, I'll be happy with that, whatever you decide to do in the long run. I'm happy to test for you in any case, and report back my findings. But again, I re-iterate that my setup isn't exactly "stock" either, what with the NASes being the recording targets and all, and me utilizing Powerline technology. So i'm not exactly your average user to be basing code standards against IMHO.

Dan / Gib.

[djp952]

It appears that I may have inadvertently insulted you, I assure you that was never my intention. I was trying to respond to the Radio vs. TV concern open on this issue, as opposed to the "audio only doesn't work" issue, which I have been treating separately (apologies). Regardless, I appreciate your feedback and concerns and also want to provide the best possible solution that works for as many people as possible :)

When compared to the mainline Kodi HDHomeRun addon, there are two primary differences that have to be taken into consideration. That addon hits the tuner device(s) directly as opposed to the accessing the DVR engine, which results in provably different MPEG-TS streams. The DVR engine adds lead-in metadata that the tuners do not, and also makes modifications to the PES (PMT) packets at a minimum, and there may be more alterations that I am unaware of. It also just sends a URL to Kodi to handle as opposed to handling the stream data directly, which until Kodi 18 "Leia" couldn't be made to work with the DVR engine properly and has no support for PVR timeshifting. It also has no way to deal with the "poison pill" SCTE packets we get here in the US that screw with ffmpeg to the point where channels won't stream at all.

The stream content difference can be tested by setting "Stream Live TV channels directly from tuner device(s)" to ON, which should provide the same behavior as the mainline addon does. You won't be able to seek on the stream, but may alleviate the concern. Unfortunately I don't currently have a way to completely remove the custom streaming implementation, but I have been assisting a developer that has been working to port my PVR to mainline Kodi to replace their existing addon and we did come up with a way to make that work. I am unaware of a release timeline there, he's been working on it for quite some time without any public releases.

I never had a specific thread on Kodi.TV for this addon, mainly because I "do my own thing" build-wise, but there is a thread on the SiliconDust.com forums (https://forum.silicondust.com/forum/viewtopic.php?f=88&t=65776). It kind of ebbs and flows activity-wise, lately has been kind of quiet. I hope that means it's all working pretty well, but it could also mean nobody is using it anymore!

I haven't had any problems with the sample file you provided, but as time allows I am trying to see what I can break. The linked post on kodi.tv does indeed sound exactly the same, I hope it's a Kodi/ffmpeg issue in the end since all I really do is take the data from the HDHomeRun and hand it to Kodi, but it's difficult to make a recorded MPEG-TS file appear to be "Live". Kodi/ffmpeg behave differently when they can seek anywhere in the stream as they appear to do when they cannot. It's a "process", for lack of a better term :)

I'll give up on the Radio vs. TV stuff since there doesn't appear to be anything I can do that isn't at least a little bit of a hack and try to double down on the root streaming issue here.

[gibxxi]

Hi djp952 / Mike,

You didn't offend me in any way m8. I greatly appreciate the work you have put in so far to get this add-on viable for use, even in it's current state. My message above was simply an attempt to clarify where I am, what I'm seeing, and ultimately where I'd (ideally) like to be.

I dabbled with Turbo C++ and Turbo Pascal many moons ago, and I know only too well how frustrating it is to spend a large amount of time on a project, only to realise that halfway in, you've been following the wrong path and have to go back and make major changes to the code because you failed to observe a critical flaw early enough. It's for this sole reason, I voiced my concerns. I'd hate for you to have to add a ton of code now that proves to be a wasted effort, later on down the road. That would not sit well with me. I would feel a ton of guilt about that. I hope this clarifies my reasoning well enough.

:o)

The native HDHomeRun "View" program isn't very user intuitive, and is pretty awkward to use in it's current form. So when you wish to make recordings from an armchair, armed with nothing except a remote control, it's use becomes almost impossible. Not to mention the fact, as a Kodi user, a solution that exists within Kodi, is the preferred choice anyway.

The above isn't true for all the systems I run Kodi on, but I like to have consistency in the way I do things. Just call me OCD, lol.

The thread link you posted may actually be the one I was thinking of, as I'm also a member of the SiliconDust forums. I probably got the two mixed up.

With regards the provided sample, I never anticipated you would get any issues with it, as the actual recording of streams from the HDHomeRun tuner is essentially, completely external to Kodi. Kodi initiates the recording, but the stream is passing from the tuner to the recording target directly (in my case, the NAS), and Kodi is only really involved when it comes to relaying status messages to the user.

I will try the "stream direct from tuner" option. The confusion for me comes from the fact that, under a vanilla install of Kodi (i.e: no 3rd-party add-ons) I get no issues. Load up my usual selection of add-ons, and it doesn't play ball.

I do have both the "Simple Cache" and "Common Cache" add-ons installed, and did wonder if one of these might be to blame. What's even more confusing (to me) is the fact that Video Channels playback fine (albeit with a slight delay before getting a picture & sound after the channel is selected). But radio doesn't. Like I said, I get no issue with the current official (unofficial) Kodi PVR add-on. I do also have SiliconDust's Video plug-in installed, but haven't used this in a long time.

I guess we'll have to wait and see what your contact can conjure up. It may be warranted to add a note about this issue to the UI for the "stream directly from tuner" option though (assuming I can verify it as a solution), in case any other European users like myself attempt to use this add-on, and experience the same issue.

Thanks for your work, and your friendly ear. Much appreciated.

:o)

Dan / Gib.

[gibxxi]

Update: Tried the "Stream Direct From Tuner" option. It has no effect. The audio stream still stops after 500ms. Any attempt to stop the stream playback, or back out of the Music Visualization screen causes Kodi to hard freeze, requiring termination of the process via Task Manager.

Dan / Gib.

[gibxxi]

Update 2: Tried another vanilla Kodi install by renaming my "portable_data" folder, and restoring your add-on + it's settings from the old add-on data folder.

Was able to get radio to play without issue. Stopped the stream, exited, patched back in some skin-related settings, and re-installed the skins they belonged to, and attempted another radio station playback. Again, playback without issue.

So now I've reversed the setup, and copied all the databases from the new install over the top of the old ones, and renamed back the portable_data folder.

I'm not going to attempt playback 3 until both the video & audio databases are fully populated, which at 1,400 films, 2,700 episodes and 48,000 music tracks, probably won't be before I hit the sack tonight. I'll leave it running overnight, and test again after work tomorrow night, just to see if there's a database corruption issue going on here.

I can't disable the "Common Cache" plug-in as that's a dependency of at least 5 of my installed add-ons. So at this stage, I hope it's some kind of database corruption.

Remember: I regularly manually copy my "portable_data" folder between machines, then tweak where I need to, to allow for variances between those systems. I don't want to have to administer 3 separate Kodi installs from the ground up, and the amount of changes required are fairly minimal between the three systems I run.

The theory here is, that a crash during testing on the desktop, may have corrupted something in the databases, or some entry about a played stream may not have ben properly cleared. Thus later on, the problem migrated to the other systems with the portable_data folder.

Time will tell. Leia has not been one of Team Kodi's better builds IMHO. It's been riddled with crashes and issues since I started using the early betas, and is still only borderline stable for me at RC5.2. However, the add-ons I have installed may be partly to blame too. Time will tell. I'm not running any piracy-based or dodgy add-ons, for the record.

Dan / Gib.

[djp952]

I'm not home right now so I haven't read everything here yet (I will tonight), but as a quick note I started adding some entry point logging for us. It will be a bit insane for things like Read() but for troubleshooting very valuable. I'm hoping to see exactly what Kodi is asking for right before it stops. Guessing is only going to get us so far :). I'm doing it 'real' style as in making it a formal option under Advanced. More as I have it and after I can sift through all the info! Thanks again for your help and of course patience!!

[djp952]

Now that I've read everything, I'll sit in a hold pattern and wait to hear back. Turns out adding entry point logging was a bad idea anyway, just the action of checking if it should be done had a measurable impact on the streaming functions and there is just no wiggle room there. Need to read my own comments from time to time - ha.

I truly appreciate the time and effort you have been putting in to get to the bottom of this. I was thinking that if it's truly all good after your databases are reloaded and reset, we could diff out the prior portable_data and the new one to see if we can find what was afoot here. I can definitely help there if privacy concerns aren't an issue (I'm a pretty honest guy, but of course both honest and dishonest people say that), and I can also provide you with a compatible version of the SQLite command-line tool we could use to deep dive into the Kodi (and PVR) databases. I don't ship that with the PVR, but I do build it for all platforms and use it here for diagnostics all the time.

While I of course hope it's fixed, if it turns out not to be there is another thing we can do as well. It's not too complicated to manually grab a tuner stream and dump it into an .MPG file. You can do it with a number of tools, "wget" works well. This is how I eventually found and fixed the SCTE issue, I hand-compared the streams from the tuners with the streams from the DVR engine using a tool called "MPEG-TS Packet Analyzer", and ultimately came upon the different PMT packets as being the poison pill that was killing Kodi.

Have a wonderful night (early morning, actually), let me know how Test #3 goes!

[gibxxi]

Alas, Kodi forced closed (again) during the night. No idea if the library had completed or not. I imagine so since the library scan at startup was fairly quick. Alas, tuning the radio channel resulted in the usual behaviour. Seeing a lot of "failed to add packets to renderer" in the log, but no outright plugin errors. So that rules out the core databases. Frustrating thing is, the *elapsed* duration is up at 14 hours once you get the music vis screen up. If I could isolate where it's getting that value from, I'd be well on the way to solving the issue. It's not Common Cache either, as I cleared it's database. Dan / Gib.

[djp952]

Hi Dan! I apologize, my notification for this post was lost in a heap of spam. Can you show me a screen shot of where you see the 14 hours elapsed time? I can probably tell where Kodi is getting that based on where it's displayed.

The way things are supposed to work with the UI timers for live streams should be a combination of EPG data (program start and end times) and data I generate. If you haven't seeked on the stream at all and don't see the "Timeshifting" bar in Kodi that can eliminate one of the hokey parts of the code (figuring out the point in time you are actually viewing/listening to right now). There could very well be a problem with the data I'm generating for these streams, which could lead to UI behavioral issues :)

[gibxxi]

Hi Mike,

Here's a screenshot I took last night. It seems to be accruing all playback time ever encountered (since last reset). The value on the right, is the current playback duration, and it seems the one on the left is total playback time (cumulative). If you choose the "Stream direct from tuner option" only the current session playback time is then shown. Both values increment on a per-second basis. Also notice that the program displayed in the top-right seems to be inferred from this as well, as the "current" program title in this screen shot is actually the next program in the EPG. The reason for it only showing about 2 hours, as a pose to the 14 hours I reported, is that this screenshot was taken on the desktop, not the HTPC. But rest assured, the 2 hours is the same symptom as the 14 on the HTPC, since at the time this screenshot was taken, the stream had only been active for about 7 minute.s (as indicated by the duration to the right). Usually these values in other streaming add-ons, are switched in terms of position (if it matters).

https://imgur.com/B8lmdJO

If I wipe out my "addon_data" folder (or simply rename it), I don't get an issue with the stream freezing, but if I put it back, it freezes. I tried disabling most options (aside from channel names from back-end) in the HDHomeRun plug-in, it worked on one Kodi run, froze again on the next. Tried disabling / removing add-on settings for some of the other suspect add-ons in that folder one by one with similar effect.

I've since remembered something. My Powerline adapters (4x) are two TP-Link TL-PA9020p (V1) kits. TP-Link enforces QoS on these things with no option to turn it off. You can only select between 4 different modes. I have mine currently set to "Media". So it may be the case that the stream is being blocked by them initially. I do get a 30 second delay when using a "Save As" dialog via any program (on any of the PCs) to either NAS, but not when browsing shares via Windows Explorer. However, the HTPC is connected to the same Ethernet switch as the HDHomeRun device, so if this is indeed the case, I would expect issues on the desktop & laptop, but not on the HTPC. Unless the switch is so cheap (also TP-Link) it doesn't do smart routing to other devices on the same switch like Netgear consumer switches seem to do.

EDIT: Scratch that. The Powerline adapters are rated at 1200Mbps (across the two Ethernet connectors they feature). Both the HTPC and laptop are connected to Port 1, on their respective Powerline adapters, the switches at those locations, are connected to port 2 on each. The desktop and primary NAS (TS453-Pro) are connected to a Netgear GS108Tv2 managed switch which is then connected to the Powerline adapter at that location.

It may also be down to a buffer size limitation, but I can't compare with the other HDHomeRun addon as I don't think it gives you the option to tweak the buffer size.

I can give you a list of add-ons I have installed that automatically re-populate the addon_data folder automatically, and thus are likely to be suspects if it is an add-on conflict. My money was on script.common.plugin.cache and/or script.module.simplecache, but have since changed my mind. The crux of the issue certainly seems to be network related, with regards to the "failed to add packets to renderer" error messages being reported by CDDVDPlayer in the Kodi log, but the cause still eludes me.

What's even more frustrating is the fact that TV playback on your add-on, and all playback on Zoltan's plug-in seem to work without issue.

One thing I can confirm, is that Kodi is processing radio channels as audio-only streams, not video streams (with audio). I use the Aeon Madnox skin, and have it set to go to the Music Vis screen on playback start. When starting a radio channel, it does just that. Milkdrop2 is visible in the background, and I get a pop-up about CU-LRC Lyrics attempting to find lyrics for "-random hash value here-.pvr" and obviously failing.

Dan / Gib.

[djp952]

Hi sir! I haven't necessarily been ignoring you here, some other things came up. Both real work and this work. Just wanted to ping you quick to let you know I didn't abandon ya :)

[gibxxi]

No worries. I've switched my two daily-driver systems (HTPC & Laptop) back to the other HDHomeRun PVR add-on for the time being. Being able to play channels without Kodi falling on it's face is more important ATM, than recording functionality.

I've also installed Deamonrik's "HDHomeRun DVR UI" add-on on one of the NASes, so that I can at least queue recordings, albeit outside of Kodi.

The setup on the desktop has not been altered, as that install is meant for testing purposes only anyway.

From what I've been seeing locally, there is certainly an issue with regards buffering / streaming of radio shows. I did an extended playback test on one of the occasions it played without instantly losing the stream. It lasted for about an hour before failing. Bringing up the HDHomeRun Tuner status webpage showed the tuner in use, but no data being pulled / pushed to / from my desktop PC.

Dan / Gib.

[gibxxi]

...Also, I tried changing the "priority" mode of the Powerline adapters to a option I don't personally make use of.

Out of the 4 options available (Music & Video, Internet, VoIP & Online Game) I chose VoIP, since I do not own or use any VoIP-based tech at this time. The rationale being that if it's set to that, and no VoIP traffic is detected, other things will not suffer as a result, as there will be no need to apply the brakes on other traffic types to prioritise VoIP. This is obviously assuming that these adapters don't reserve bandwidth for the chosen option on a permanent basis.

It's had no effect, either positive or negative that I can tell at this time.

Dan / Gib.

[djp952]

Great information, thank you. I would discount the network and/or QoS as a root cause. If the in-built PVR is working without a hitch, it has to be my code. The regular PVR uses Kodi's cURL "file" code to stream as opposed to doing it on it's own, which leads me to ....

I have a new theory about the audio-only playback based on the additional details. What I think might be happening here is buffer starvation. This really never happens with video streams, there is so much data to be processed if none comes in within a reasonable timeout window it can be assumed that it's dead. A significantly lower bandwidth stream could, theoretically, actually have no more data available when asked. I definitely am not accounting for a scenario like that. I'm going to poke around Kodi's cURL implementation and see if I can get any pointers there. I also need to come up with a way to try that out here. (This entire problem probably wouldn't exist 2+ years in if I had one of these channels!)

As for the other issue with the UI reporting weird progress, I also have a theory there. I'll start with that I installed Aeon Madnox on Leia, it doesn't look like your screen shot at all - what skin are you using that shows the progress like that - I'd like to see it first-hand if possible? Regardless, what I think may be going on based on the screen shot is that the skin is showing you the "Timeshift" progress as opposed to the "Realtime" progress. Stock Leia (Estuary) has 2 individual progress bars. I only report "Timeshift" progress to Kodi if you are streaming from the DVR engine, since you can seek on that stream. When streaming direct from a tuner I tell Kodi to pound sand when it asks for this, since it can't be timeshifted. It would fit the symptoms, at least.

Timeshift progress is supposed to tell you a few things: 1) Are you timeshifting? 2) How far back does the timeshift buffer go? and 3) What time is being played right now? To get this information is hard and in my case probably a little hokey. I scan the input stream for the arbitrary timestamps inside of it and use that information to answer all three questions. It's imperfect, but works most™ of the time. It's also designed to shut itself off if the answers become unreasonable, like if the timestamps suddenly go backwards.

If we can prove that the skin is using the Timeshift progress instead of the realtime, that can easily be made into an option to just turn it off or we can talk to the skin author about it. I don't think many of the in-built PVR addons try to report timeshifting.

Let me know if you can about the skin used for the screenshot, and I'll start tinkering around with what happens if a stream temporarily has no more data to give but hasn't actually ended. This may tie into an older issue I'd love to fix which is how I can reconnect to a dropped stream automatically. Should be similar, if not identical, concepts.

Thanks again for all the info, and of course your patience :)

[gibxxi]

Hi Mike,

I am indeed using the Aeon Madnox (Leia Version) skin. The screenshot I sent you was from the EPG screen from the Arctic Zephyr skin I also have installed, but as the same values are displayed in both, didn't think it would matter. I am not active in the thread for it on the Kodi forums for personal reasons. I can't find the correct forum thread at the moment, but you can sync it via GitHub from here:

https://github.com/mikesilvo164/skin.aeon.madnox

The original thread for this skin (mod) can be found below, but be advised: That thread is only for the "Jarvis / Krypton" builds of Aeon Madnox, not the Leia build. The guy responsible for Aeon Nox SiLVO is also concurrently maintaining the "Leia" build of Aeon Madnox (on behalf of Mad_Mike_Doc) and providing support / bugfixes (but no enhancements) for that build. It is entirely possible I've been banned from the thread, thus I can't see it, as I was pretty scathing towards the maintainer (MikeSiLVO) about his attitude and practices with regards the maintenance of the Leia version of this skin.

https://forum.kodi.tv/showthread.php?tid=230821&highlight=Aeon+Madnox

Be advised: "Aeon Nox SiLVO" is a fork of the "Official" Aeon Nox 5 skin, and is nothing to do with Aeon Madnox. MikeSiLVO is maintaining both on behalf of the community (for Leia).

I'm also beta testing for another skinner, called "Mr V." who is in the process of recoding Aeon Madnox from the ground up, for Leia and beyond. His version is simply called "Madnox (2.0)". I can't provide you a link to that, as it's by invitation only at this time. Regardless, I've not used that version with your add-on anyway (AFAIK).

I have used time-shifting on my systems, both mistakenly (pressing wrong key to stop stream) and on purpose. However I would expect this to be reset at the point Kodi is exited / restarted. or the stream is stopped by the proper means and then restarted. The weird time values might suggest that this is not happening.

I have had issues with Live TV channels freezing too, but put this down to decoding, as the render mode selected (Auto vs. DXVA) was also having an issue with de-interlacing not being applied. When changing this option from "Auto" to "DXVA" explicitly, the problem seemed to disappear.

It may be the case that the same thing is happening in both cases, as you don't get on screen duration info with TV channels, so any time-shifting issues wouldn't be so instantly recognizable. However, I'm not experiencing any instant lock-ups with TV streams either (at this time), so maybe not. One thing is for sure, Kodi is treating Radio streams as Audio-only (music) streams, and processing them as such.

At the point the stream is stopped manually (even if time-shifted), then the HDHomeRun deletes the "Live TV" folder from the NAS's recording share, and any streams it contains. This may be the reason we're getting freezes here.

The add-on could be looking for packets of data from a (time-shifted) stream that no longer exists physically.

Dan / Gib.

[gibxxi]

Had an interesting experience today, using Zoltan Csizmadia's HDHomeRun PVR Add-on on the laptop...

...It lost the stream in exactly the same way as happens when I use your add-on. The difference? Unknown to me at the time, Acronis TrueImage was performing a cloud backup / check from the same machine.

Now I'm going to say right now, that I don't think Acronis TrueImage is the definite cause. Reason? 99% of the time, I've had no issue with the other PVR add-on for streaming, and I'm reasonably certain, since Acronis backups occur on all my systems at set times, that the constant failure of streams on your add-on cannot be attributed to it directly. Also, for note, backups it does run are set to the lowest priority I can in the software, specifically to avoid this kind of issue.

The reason for posting this message, is that I have a theory as to what might be occurring here, and it's not the fault of your add-on or Zoltan's (specifically) either.

I lay the blame at the HDHomeRun device and it's handling of streams. As I noted above, upon the disconnection of a stream, with your add-on, which does support time-shifting, it appears if the connection is lost, the device will "clean up" automatically. It deletes the time-shift buffer and stops sending packets of data, or attempting to send packets of data to the remote IP. In the case of Kodi, it's then waiting for data it will never receive, as the connection has been lost and the HDHomeRun device has already deleted the buffer.

Also, Kodi, through either PVR add-on, seems to be unable to recover the lost stream once it has failed, and I believe it's due to the above issue on the HDHomeRun device itself. Or rather the way the two interact with each other.

The fact is, that while Kodi has lost the stream, and is not outputting any audio at this stage, it's not frozen / crashed at that stage. The visualization is still active, and the on-screen channel icon (& spinning CD) are still quite happily being displayed / rotating. The instant you perform any action that requires a GUI update though, and Kodi will freeze, waiting for a response from the HDHomeRun box it's never going to get. That includes attempting to stop playback, using the Backspace or ESC keys to back out of that screen, or even the "backslash" key to switch between full-screen or windowed modes. At that time, no more entries will be added to the log, and it's necessary to task-kill Kodi and start again.

For me, with my Powerline setup, it's entirely possible, that other processes (within Kodi) or other services on the system are taking bandwidth that cause the Powerline adapters to put the brakes on the stream, because it's not being recognized by them as "audio or video", and it's then prioritizing those other transactions.

Powerline is like Wi-Fi and Ethernet combined. The Mbps connection rate can fluctuate wildly, although generally not as wildly as Wi-Fi, nor as much. But the other caveat to it is, AFAIK, only one node can transmit or receive data per cycle, much like non-Mimo Wi-Fi, so even if services on the current system aren't affecting the connection, other systems connected to other adapters might well be doing so.

Either way, that's somewhat irrelevant. The relevant thing is, that (broken) streams from the HDHomeRun appear to be impossible to recover once failed, and some kind of timeout needs to exist to tell Kodi to stop / give up attempting to retrieve packets from a stream that is now essentially dead. Doing so is far from ideal, but is much better than Kodi persisting in the attempt to get data from a non-recoverable stream, so it doesn't lock up the entire system.

Also, the time-shifting status needs to be reset at the point we determine the stream is non-recoverable or it has been manually ended, thus doing a "clean-up" of the connection that was broken / stopped. Assuming Kodi isn't hung / frozen by the PVR add-on, we can always retune or attempt a reconnect a cleanly terminated connection. While a PITA, it's better than having to force-close the whole app each time.

Unfortunately I cannot offer you access to my local setup to test, Sorry.

Dan / Gib.

EDIT: I'd also like to point out at this point, while I did have to force-close Kodi, using Zoltan's add-on, since it does not support time-shifting, once the bandwidth restriction was removed, upon a restart of Kodi, attempting to connect to a radio station worked as usual, without issue. Once the same thing happens with your add-on, Kodi is still under the belief that it should attempt to connect to the previous (time-shifted) buffer, which it appears to do (while still playing 500ms of audio from the current tuner output) before falling on it's face.

Therefore it might be an idea, to clear any add-on time-shift cache / buffer content at add-on start as well, as at the end of playback, in order to be safe. Since a time-shifted stream shouldn't exist across multiple runs of Kodi, and Kodi does have a tendency to crash often, this will prevent issues for users who run more "standard" setups than me, who have the misfortune of Kodi crashing on them (for an unrelated issue) while time-shifting using your add-on.

[djp952]

I was thinking much along the same lines, actually. This morning I found a nice little tool called "Clumsy" that allows me to simulate various network problems (https://jagt.github.io/clumsy). I've only tinkered with it so far (today is daddy daughter day), but it seems like it will be quite valuable.

My intention is to sit down with it and see what types of behaviors I can mimic effectively, and how cURL and Kodi react. The main thing I need to see the differences for is in-progress recordings; they appear as "Live" until they are done, but if you don't seek I don't get new HTTP headers to tell me it now has a length. That can be worked with :)

I think you're onto something with the buffer disappearing on the DVR. Stopping and restarting the stream would take care of that, the timeshift information will be reset, since it needs to be assumed that you can't go back any farther than when you started.

Kodi is indeed very fussy about this stuff, and Leia has been doubly annoying. Too many changes in one release in my opinion.

At a minimum I should be able to get you something with at least some additional logging points to see if we can come up with the proper methodology for when to give up on a stream and try to start it over again. I will also be adding some logging points to indicate the timestamps being used, what will be reported for timeshifting, etc. Honestly it will probably take a few iterations to come up with the right series of "stuff" to smooth this all out.

(Or I can send you a spool of Cat 6 and a 1000-BaseT switch - bright blue wiring strewn across the floor solves everything! LOL)

[gibxxi]

I already have a 15m CAT5/6 cable that can be utilized if necessary, and The HTPC area, and laptop area are both connected to the Powerline Adapters via TP-Link switches, so it is possible for me to "create" a direct connection. Not easy, due to the way things are laid out here in my 1-bed flat (apartment), but doable nonetheless. I'll PM you (on the Kodi forums) some photos I already have of my setup(s) when I get time.

I can't remember off the top of my head how the desktop connects. My GS108Tv2 is sat behind my NAS in a small cubby-hole in the desk, and getting at it is a problem. I have a feeling though, that the switch connects to the Powerline adapter there, and to the router, as well as the primary NAS and desktop PC. There isn't any issue with network loops though, it was all planned out in the right way before assembly.

Both the primary NAS and the desktop PC use LACP teaming, but it's broken (again) on the desktop at the moment due to ongoing issues with Intel's Ethernet driver compatibility (ANS) with the recent RS5 Windows release (October Update).

I'll download Clumsy and get it installed on the desktop. If you have any specific things you'd like me to try, let me know.

With regards remote connections, it's not that I have anything to hide per-se, but I wouldn't feel comfortable allowing anyone I don't know personally accessing my local system(s) without me being there to monitor what they're doing, and since I only get two days a week (on average) to dedicate any time to this "project", and the fact that our active times are off by a minimum of 6 hours, it's not doable for me (at least at this time).

If I book some holiday from work in the next few months, that scenario might change. If it does, and we're still at an impasse, I'll be sure and let you know, and we can work something out. I have a TS3 server running here, and TeamViewer, so I'm sure we can work something out at a time more suitable.

FWIW: I notice that a lot of people on the Kodi forums posting issues about PVR and stuttering and performance issues with Kodi 18. Some using the ServerWMC back-end, some using NextPVR (I used this when I had a TV card in the HTPC), and some issues with Nvidia's Shield device (Android).

I think we can however rule out our initial assumption that it was something to do with the stream itself or the way it was constructed. I will need to do some research on how DAB Radio is packaged. I know it's an MP2 stream (MPEG-1, Layer 2), but I do not know if it's also encapsulated in a MPEG2 transport stream like the TV channels are. It's not possible to trust the Live recordings from the HDHomeRun, as there's probably on-the-fly transcoding going on there anyhow, for playback consistency.

I also want to do some testing with Live TV and time-shifting, to see if this issue is indeed only related to radio channels, or whether my previous issues were down to the same problem. Unlikely to get time to look at that in any depth until next weekend though. If I see anything that I think I ought to report, I'll do just that.

:)

Dan / Gib.

[gibxxi]

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

Might suggest that my suspicion that there's a Kodi issue with the PVR service is not misplaced (See last post by eddieleong).

Dan / Gib.

[djp952]

Thanks for the link! It does sound familiar :)

I have a couple questions that may sound dumb to you, but I have to ask anyway (this thread has gotten very long). 1) What version of my PVR are you using right now on Leia, have you updated to the latest (v1.3.12)? 2) What platform / OS were you running when you took the screen shot from Arctic: Zephyr?

I ask because what I'm seeing in Arctic: Zephyr is different than what you saw. What I see are the raw stream times being reported, as in "00:00->XX:XX", where "XX:XX" is the number of seconds since the live stream was opened. There was a bug on 32-bit platforms for a couple versions that would send the "end time" being reported into negative territory. Regardless of that, the stock Kodi skin actually uses the stream time data in conjunction the EPG to figure out where you really are. What I can do here is play with the values I'm reporting to see if I can get the starting point to be accurate. The ending point is hard, if the skin doesn't check the EPG it will have to go on what the PVR tells it, and I have to base this answer on when "now" is. I'm not done with this analysis but wanted to ask you these questions.

What I have really been looking at is the drop/timeout conditions. I believe I have a bug here that I need to address. When simulating a drop-out I found that my code will go into a generally infinite loop trying to satisfy Kodi's read request. What it should do is decide at some point that there is no more data to be had and hand over what data is available to Kodi, or just send it zero bytes which will kill the stream after Kodi retries a couple times.

I have not yet duplicated a server-side network concern, but I watched the HDHomeRun DVR share's Live TV folder when the client is having a problem and found that the HDHomeRun DVR will keep the live stream file out there until it thinks the client(s) have disconnected. Since I'm sitting in a loop waiting for data, the connection is technically still open, and the file isn't going away until I kill Kodi.

Please let me know on the addon version as well as the platform / OS versions so I can be sure to replicate exactly what you are seeing skin-side to be sure I'm barking up the right tree. In the meantime I will see how the skins react to changes in the time(s) being reported.

No actions requested on the loop problem - I clearly see it and don't think it's a difficult fix. I just need to pick a method to use.

Thanks again for the time and effort you have been putting into this. Trying to get the software 'perfect' is the main priority, and from my chair you being banned from that thread wasn't necessary. :)

More as I have it.

[gibxxi]

Hi Mike,

At the point of writing this message, I have version 1.3.9 of the HDHomeRun PVR DVR add-on installed. Which was downloaded at the point you added the back-end channel names fix I believe.

All my systems are running Windows 10 Pro - RS-5 (October 2018 Update - Build: 17763.rs5_release.180914-1434). I'm running a registry hack that displays the version info on the desktop.

You do realise we've been communicating in the wrong thread all this time too don't you? Having said that, once we get a solution, I'd feel happier if these posts are deleted in preference to a "summary" in the right thread, as I've done a lot of waffling here, and divulged more details that I should of on a public, open platform such as this.

The version of Arctic Zephyr I'm running is BeatmasterRS' Leia Mod (At this time). I also have the vanilla Arctic Zephyr installed as well, now that Jurialmunkey has finally made it Leia compatible. It's not in the Kodi repo at this time though (neither are).

BeatmasterRS - Arctic Zephyr (Leia Mod): https://forum.kodi.tv/showthread.php?tid=337862

Jurialmunkey - Arctic Zephyr (Original Version - Updated for Leia): https://forum.kodi.tv/showthread.php?tid=217174

For Beatmaster's version, I'm using his repo for updates. For jurialmunkey's version, he doesn't provide one, so I'm syncing to the Kodi folder with a combination of GitHUB Desktop and SyncBack Pro. (I also use this combination to keep Audio Addict, Aeon Madnox, and Mr.V's Madnox 2.0 - Pre Alpha updated). I de-select the syncing of any GitHub related files/folders, and de-select all other add-ons that reside in the "portable_data/add-ons" folder so that SyncBack Pro won't attempt to remove them during sync (because they exist at the destination folder, but not at the source). The profile used in SyncBack Pro is the "Mirror" profile.

SyncBack Pro is available from here (30-day trial): https://www.2brightsparks.com/syncback/sbpro.html

Hope this helps.

:)

DM.

[djp952]

I know it's technically the 'wrong' place, but there is little need to follow protocol here :) I do that stuff all day. My goal is to try to solve the problems, how that gets done isn't that important to me. I see no need to close it out. We did solve the actual problem for this issue a ways back, but let's keep it going.

I'll reinstall 1.3.9 tonight on both x86 and x64 Leia and see if that changes things, display-wise. That bug shouldn't have affected Windows builds regardless of architecture, the Visual C++ compiler behaved differently than GCC for that.

If it's OK I'm going to look at fixing what I found with never allowing a dead stream to close out first, as that will enable me to test the ability to actually retry connecting to the server/tuner again, which has been an issue for a number of folks. Rumor has it that the FireStick 4K still changes IP addresses every so often, which is really killing people since the DVR disconnects the client.

But really, no worries about where and when and what to post. You should see my incessant ramblings! Together we could fill our own forum! LOL

[gibxxi]

FWIW, I also tried the latest version, with no difference.

I have, at several points earmarked several add-ons that may be responsible for generating enough traffic to cause the problem, by renaming the "portable_data" folder, and adding add-ons back in one at a time, between runs, to attempt to identify a suspect.

Unfortunately, each time I think I have a winner, and remove it (and / or it's settings folder), it has no effect. Once there's breakage, it carries over between runs of Kodi, regardless of the presence of the suspect add-on or not and I have to start from scratch.

At this stage I've done a full wipe of the "portable_data" folder and will attempt a complete setup from scratch. The only issue with this is Kodi doesn't allow you to see / download dependencies directly any more, so installing / restoring those add-ons I sync via GitHub will be a problem, as side-loading them will not trigger their dependencies, and i'll have to check each one manually, and force-download them through the dependencies menu item.

Even though I plan to do this, i'm not confident it will improve the situation any. Ideally, going back to Krypton would be the ideal test, as I have run this add-on on Krypton (for a short time) but cannot remember much about the experience.

Dan / Gib.

[gibxxi]

I believe there's an issue with the Time-shift buffer and the HDHomeRun add-on and device.

Starting with only a bare-bones install of Kodi, plus the skins (and all dependencies) and nothing else, radio streams play back fine, until you attempt a time-shift / seek action. At that point you lose audio and the install is borked.

On this setup, for me, the only (installed) add-ons that have created addon_data folders are:

peripheral.joystick
plugin.program.autocompletion
pvr.hdhomerundvr
script.module.metadatautils
script.module.simplecache
script.openweathermap.maps
script.skinshortcuts
skin.arctic.zephyr.mod
skin.estuary
weather.openweathermap.extended

Out of the above, the only add-ons I can imagine that would save any data relating to PVR, are pvr.hdhomerundvr and possibly script.module.simplecache. I've deleted the contained databases from both, and restarted Kodi, then attempted to re-tune the previous radio station. Usual scenario persists. I get about a second of audio, and then the stream quits.

Checking the tuner status will yield the following for that tuner on the HDHomeRun device's web page:

https://imgur.com/ZMshMHs

Attempting to do absolutely anything in Kodi from this point, will result in a freeze, as Kodi is waiting for packets from the HDHomeRun device it will never receive, meaning a force-close is required. Attempt a restart or reboot, and the same will happen, but only for radio shows.

So with the above being true, data about the current time-shift status must be being sent to SiliconDust's cloud servers, as is the case for recordings / timers. There's nothing that I can find in my Kodi install, that I can clear, that will result in a resolution of the issue. At this point in time, even renaming the addon_data folder is not making any difference.

If this was simply an add-on or buffer / cache issue, then clearing out the addon_data folder should do the trick. AFAIK Kodi won't store session / user specific data anywhere else, so the duration of the stream (which is also incorrect) must be coming from the HDHomeRun device or SiliconDust's cloud server. This data must be cleared at add-on start to prevent carry-overs from previous ill-fated runs IMHO.

It would seem that the way DAB radio is broadcast differs somewhat from the way the TV signal is broadcast. I do know that in the UK, the local antenna for your area (In my case, Mendip) does not broadcast FM/AM Radio. This is handled instead by a number of regional sub-transmitters in each town. Can't remember where I read this, but read it I did. It does however broadcast DAB radio. What I do not know, is how these streams are encapsulated. There must be some difference to the TV stations, otherwise there wouldn't be the performance difference we're currently seeing with TV vs. Radio channels.

However, there does seem to be a definite difference between DAB Radio (UK, Europe, etc.) and HD Radio (US). I found a page that mentions this specifically.

https://www.toptenreviews.com/electronics/articles/how-digital-radio-works/

All this does however assume that there isn't some kind of inherent problem with Kodi itself. As there are at least a half-dozen threads on the Kodi forums where people are having issues with (various) PVR setups, but at the same time, a major portion of these users also seem to be having issues on Android devices like the Nvidia Shield, specifically.

It might be the case, that until you start advertising this mod on the Kodi forums, your not going to get any Europeans using it to corroborate what I'm seeing. IMHO, the SiliconDust forums are too niche to give this add-on enough exposure (for those seeking to use it with Kodi, who also reside in the UK/EuroZone), again, IMHO.

That's all for now.

Dan / Gib.

EDIT: I think this is specific to the NextPVR PVR Add-on for Kodi, but the symptoms described seem to fit with what we're seeing. How this bears relevance, since your add-on makes no special provisions for radio channels (vs. TV channels) I cannot say, but worth a look in any case...

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

[djp952]

There are a few competing factors at play here, and I think I have a build that will help figure out where things are going wrong, or at least maybe help finally point the finger into or out of the PVR.

First off, I can assure you that the PVR makes no changes to the installed state of Kodi whatsoever. Everything it does is private to itself, there are absolutely no changes being made to the Kodi configuration or other addons or anything. The data it uses is 100% dynamic, but it does cache it off in a small database to be able to limit the number of times it has to go ask for it. You can even delete the PVR database completely (there is an option for that too, but it's hard to find in the Kodi UI) and it just picks up where it left off since all of the data is completely volatile.

Now, as for the changes I've made …

There were a couple bugs to eliminate that would occur if the connection was completely dropped. The main one was that the PVR would allow Kodi to continue to try and read from a dead stream indefinitely. This would cause Kodi to pretty much lock up since the PVR would just sit there in a loop waiting for data that would never come. Fixed that one. There was also an inherant inability to detect a dropped stream, which exacerbated the first problem quite a bit. That is also (apparently) fixed, but there is a side-effect. Instead of waiting forever for something that will never happen, a dropped/errored connection has to be reported via the logs and a notification banner only - Kodi does not obey it's own API and will continue to try and read until the stream gives it back a few zeros, it ignores the "error happened" result. It's also not immediate - I had to tell cURL to stop and error out if it sees less than 1 byte per second over a 5 second sample period. In testing, this ended up more like 6-8 seconds before cURL would error out for me, and it has to be a complete drop -- either the client or the server has to be good and dead.

Resuming a dropped stream is seemingly impossible with Kodi, it has to close the stream on it's own and start it up again (which it doesn't do). Truly resetting things and starting over with the same URL sends Kodi into la-la land -- all the metadata and properties it had are now invalid. I tried this in response to the theory that the PVR was reporting some manner of "all time" data, but that just isn't the case. Every stream is unique and all properties/metadata about it are calculated when the stream is opened.

For the special build I'm going to link to below, I added some extra logging so we can find out for certain where the weird times come from. It has a mainline change that will now log the properties of a new stream (Live or Recorded) when you start it that we can examine, but I also added one-off logging to periodically report the times being reported to Kodi via the new Leia API call, and they will be reported as both Unix epoch (time_t) and converted into readble local time. There is also a special set of logging for Live TV seek operations -- this build will report the current stream position when seek was called, and what it ended up at. These are byte positions, so I will need to compare what Kodi asked for with what it will get to see if there is anything weird there. I don't think there will be, a problem in seek would affect everyone.

If you get a timeout or some other HTTP/cURL error with this test build, the stream will stop completely and you will get a banner notification. Remember it will take a few seconds, but once a stream is dead it will be truly dead. This behavior change applies to both seek and read operations.

So when you can, if you wouldn't mind installing this build on a system and making it break, there should be enough evidence in Kodi log to determine what the next step will be :)

Link to test build (all platforms, you can use whatever one you'd like): https://1drv.ms/f/s!AgEGEEVzGNq-i9Usd4MUjS-3WjooDQ Let me know if you have trouble accessing it, it's just shared from OneDrive

I hope this will resolve enough and provide enough evidence to keep going!!

[gibxxi]

Hi Mike,

Gave it a try, but no change in behaviour from before within the Kodi UI. I've attached the Kodi log from that run for you to examine (minus advancedsettings.xml section, as this contains personal data, paths, passwords, etc.).

https://1drv.ms/u/s!Am5WO9nIAax8gZRcm1AmgW4qlM0yrA

Dan / Gib.

[djp952]

This is great, thank you. Scanning through, I'm not seeing anything wrong with the PVR client yet. All of the information it's reporting seems perfectly accurate, especially the stream times. They are a perfect match for the corresponding Kodi timestamps. So no help on the UI issues yet.

It looks like both live streams had Kodi-level problems. The first live stream for channel 1 is reporting a lot of these, I would expect to see only one of these messages, my assumption without digging into Kodi is that it's retrying over and over to figure out how to play the stream:

WARNING: CVideoPlayer::OpenStream - Unsupported stream 0. Stream disabled.

The stream then appears to start and work for about 35 seconds and then 4 seconds later the stream ends. The logs I added are periodic, so this gap could be a normal stop event that you executed, or the stream returned zero bytes multiple times without actually 'dropping'. But, as we suspected there is no indication from Kodi or the PVR that anything actually went wrong.

The second stream, channel 705 appears to have started smoothly and quickly but started throwing these errors out:

ERROR: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer

Again I don't know exactly what causes this, but based on the message I'm guessing starvation. Data isn't coming in fast enough and Kodi is upset about it. Another thing I'll have to dig into Kodi to find why it may do that. That stream ended about 1 minute and 15 seconds after you started it, with no indication of an anomaly.

Here's what I'd like to do next with you, provided you are still game. I want to add logging of the HTTP response headers coming from the DVR engine to see if we get something different for these streams. I think the streams themselves are fine, as in they are still valid MPEG-TS (the sample you sent is), another concern I have is the data transfer rate. Playing a Live stream is different in that Kodi has to wait for data, so me playing your file as a Recording isn't the same -- it can seek and load data as fast as it wants.

As for the time display issues, I've got nothing. Everything seems perfect. I assume this is a lower priority concern, of course, but if I think of something else to log that a skin or Kodi might be using, I'll add it.

I can probably get you a new build with some adjusted logging late tonight, New York time. I may add something to dump the stream MPEG-TS metadata in there as well to see if can determine why Kodi hates that stream 0 coming from channel 1.

edit: quickly poking around Kodi, you may want to try tinkering with your Audio settings in Kodi. It seems these errors can be caused by a result of various hardware decoding and/or conversions taking place. It's a shot in the dark and probably won't do anything. Just an observation.

edit 2: I'm also going to increase the wait period for data significantly for you to see if that has any effect, as well as add logging anytime the PVR will return zero to Kodi from a read. The current wait is 500ms, if nothing at all comes in at that time it makes one more attempt and then gives Kodi what it has, which may be nothing at all. We can make that really high to see if changes things, it shouldn't negatively affect streams that are keeping up, but it will introduce a 'pause' of sorts if data stops flowing.

Good info as always, appreciate you sticking with this!

[gibxxi]

I went to look for my 15m ethernet cable in a bid to connect the switch at the HDHomeRun box directly to my router... and it's gone. I may have lent it out, and if it was to I think it may have been, i'm not speaking to the guy at the moment, so I probably won't get it back any time soon.

The thing that is still baffling me, is why the other PVR add-on and video on yours are working fine, without issue. Video / Live TV especially, since this is going to use more bandwidth than an audio-only stream. This leads me back to the Powerline adapters and their enforced QoS. If the stream is being detected by them as not being "audio or video" then it could be being blocked. It could be a firewall issue, but I doubt that since Kodi has full access through Windows Firewall, as does the Windows HDHomeRun software.

One thing to note, channel 705 is BBC Radio 5 Live, which is broadcast in the UK, on AM as a mono broadcast. It's also broadcast on DAB as mono as well. Having said that, I also tried BBC Radio 1, but the same thing occurred. Also, the audio is always quitting out in Kodi at exactly the same time-frame, and only once "time-shifting" has been invoked for an audio-only stream, (with a vanilla install) at least once.

I can play that channel (and have done) for an extended period on a vanilla install of Leia without any issue whatsoever. Finally, there are no permissions issues with the "HDHomeRun share" on the NAS, as I see a stream being saved to that share, and incrementing in size properly, as I would expect, when queuing any channel (either radio or TV) from your add-on, and the HDHomeRun VIEW software also has no issue streaming any channel.

In Kodi, it all goes south once Time-shifting is invoked on a radio channel. No issue time-shifting with the TV channels. I'm literally at a loss. Also this is frustrating the hell out of me, because it shouldn't be happening. It defies logic from where I sit.

Once you invoke time-shifting once on a vanilla install, that install is then borked. Up till then it seems to be OK. For two pins, i'd uninstall Leia, and re-install Krypton and an earlier version of your add-on and see what happens then.

Dan / Gib.

[djp952]

I may have an answer, next build I give you may reveal if it's true or not. I tried hard-coding the PVR to always hit a live MP3 internet stream instead of what it's supposed to (http://icepool.silvacast.com/JACKFM.mp3 - Jack FM Berlin, my favorite station!) and … nothing happened. It just sat there streaming along merrily yet not producing any audio at all. I got it to work by hard-coding the MIME type of the stream reported to Kodi (this is new in Leia) to "audio/mpeg" instead of "video/mp2t". For what it's worth, I throttled and inserted 90% drop-outs on that stream and both the PVR and Kodi handled it just fine (it's only 48Kbps, so 6000 bytes/second). But of course this isn't coming via the HDHomeRun DVR engine, it's a direct link.

I was working on a mainline change to extract and report the MIME type from the real stream properly but ran into a snag -- Kodi is asking for this BEFORE the stream has been opened. This is a big problem since I can't know what the MIME type of the stream is until I open it. I am working on a workaround for that, but I think I'll also probably need to issue a Pull Request for Kodi to make that call happen after the stream is opened; I can imagine this being a problem for a lot of PVRs, especially the IPTV ones.

This may tie into why you have problems time-shifting radio streams. The same new function that gets the MIME type also gets a real-time flag, which right now will apparently always be false (erroneously) because the stream isn't open yet so I default to that. It's definitely being misreported right now.

The in-built HDHomeRun PVR does nothing but hand a URL off to Kodi, Kodi is then determining how to deal with it. To me, this means the evidence of sending in the wrong MIME type is mounting -- I'm always telling Kodi it's "video/mp2t" and have now proven that if the stream isn't actually that bad things happen.

None of this would explain why time-shifting on a vanilla install would somehow corrupt Kodi, of course. That one is a real head-scratcher -- that is one hell of a defect, and you are honestly the first person to indicate this happening. This operation is an "everybody does it" thing, it definitely should have happened to somebody else by now -- but as you indicated 99.9% of my users are in the US on QAM/ATSC, DVB streams may be causing me or Kodi some level of unknown heart failure.

Even though I'm stuck on the MIME type thing I think it would still be valuable to get the response headers for your audio-only channels, so I'll still try to get you a new build that logs those tonight. If the workaround I'm thinking of (start the stream when it asks for this information instead of when it asks to start it) pans out reasonably well, that would be much better. I have an hour or so left before I have to give up- lol :) If nothing tonight, expect something tomorrow night for sure.

[gibxxi]

OK, will wait on you then.

I decided to bite the bullet and try Krypton. I copied out my Leia "portable_data" folder, uninstalled Kodi Leia, and reinstalled Krypton, I then downloaded the latest version of your add-on from the Wiki section on GitHUB for Krypton and installed that.

It forced Kodi to quit to desktop on install, but upon restart it seems to have installed fine. I queued up the same radio channel (5 Live), and while there was a split-second audio dropout at about 3 seconds, it was only split-second. The stream resumed OK from that point onwards.

I have witnessed this behaviour generally, on all PVR related streaming. I think it may be Kodi syncing the video with the audio or applying (or not) de-interlacing on PVR as this split-second dropout occurs on TV channels too at about the same time period on Krypton or Leia, however the stream resumes without issue on Leia for TV.

Here's a screenshot of Kodi Krypton, with version 1.3.12.6972 of the PVR add-on. Notice how the current playback duration is correctly on the left, with the total programme duration (correctly) on the right...

https://imgur.com/Frt8Nkk

... I'm occasionally seeing the timeshift buffer status appearing while playing back the station for a split-second (see screenshot below), but it's literally only on screen for a split-second. There are no stream dropouts when this happens. Playback is fluid...

https://imgur.com/kIcKIZ9

...I tried "full-on" pausing the stream (again, see screenshot below), and when un-pausing the stream, playback resumes without issue. Stopping the stream takes a couple of seconds to process before Kodi returns to the guide screen, but it manages to do so without issue. I would assume this to be network latency between the desktop and the HDHomeRun device (over Powerline). The link between the desktop and the device is the strongest of all the Powerline links I have set up (4) though...

https://imgur.com/8tUL87D

I've never seen that time-shift progress bar shown in the screenshots, in Leia, period.

Finally, attempting to (re)start the same channel from a stopped status, also works without issue. You (again) get a minor blip / dropout between 3-5 seconds for about a second, but audio returns without issue after that period. I even tried stopping the stream, quitting Kodi completely, re-starting, and retuning the stream, and it works without issue.

I forgot to switch audio from DirectSound to WASAPI during this testing, but did so while the stream was playing, and it seems to work the same, regardless.

I've attached a log from this test (not debug). If you can't get the attachment, it's also on my OneDrive account, at: https://1drv.ms/u/s!Am5WO9nIAax8gZRis8mGVlnobpFMCw

kodi.krypton.log

Dan / Gib.

[gibxxi]

I must point out too, that I've again, temporarily switched back to the default SiliconDust RECORD engine (set up via the Windows App), but since demonrik's QNAP package uses the same engine as it's base, I doubt this will have much of a bearing.

I had to re-disable the "SMB 1.0/CIFS Automatic Removal" item under Windows (Add/Remove Windows Components) -> SMB 1.0/CIFS File Sharing Support in order to get the service to install, otherwise the setup app fails to find the Windows SMB service and won't install the RECORD engine on the NAS.

Dan / Gib.

[djp952]

Sorry I didn't get a build out to you to test yesterday, and thank you as always for the additional details.

I came up with a solution for not being able to provide Kodi with an accurate media type (MIME) and realtime indicator in the new Leia functions. I basically just open the stream earlier than Kodi wants me to in order to get this data. Stream is still only opened one time.

The good news here is that I can actually stream raw MP3 without any problems through the PVR now. If we are looking at pure audio and/or other non-MPEGTS we will get farther now.

The media type of the stream will also now always be logged. I still want to get you something with HTTP header dumps and an increased data timeout, though. Hopefully later today. The other changes have become mainline for Leia.

[gibxxi]

When you post here to let me know it's up, also let me know what (if any) additional logging you require in Kodi, so I can provide you with the level of feedback (in addition to potential screenshots) that you might require.

Somewhat eager to test out the next build to see if we have got a workable solution. My interest yesterday in my Krypton testing was to identify a root cause for the issue, and I think it's safe to say that Leia changes are that root cause we were looking for. The performance certainly seems to rule out hardware configuration, or lack of bandwidth as being the root cause. Also, the blame doesn't really lie with your add-on, as it worked fine on Krypton.

Just the usual scenario that Kodi upgrades may fix things, but it's equally likely to break things at the same time.

:)

Dan / Gib.

[djp952]

I agree, Leia has been a serious pain in the rearend. I added a variable called "close stream hack", that's how annoying it is. When I said earlier "stream is only opened one time" I lied. Now it is, but I hate the implementation since Kodi can break it on me later. I definitely need to let them know about this or propose a change, it makes no sense to me to require the MIME type of the stream be known before you open it, that's extremely limiting for all PVRs. I can see the IPTV folks pulling their hair out over this too.

Anyway, here is some code. Let's hope it doesn't make anything worse! It's all the mainline changes I've made the past few days plus it logs all the HTTP response headers and increased a wait operation from 500ms to 2500ms (probably pointless since Krypton and Jarvis are perfectly happy with 500ms - they all use the exact same code).

https://1drv.ms/f/s!AgEGEEVzGNq-i9VIv3ZUdhqSILhatg

(Windows 32/.64-bit .zips are there right now, rest will be added to the folder when the full build completes)

[gibxxi]

I've only done a quick test as I've been up most of the night trying to set up most of the other add-ons I use from scratch, and as luck would have it, while using Artwork Beef to update local artwork for the music library, a scheduled automatic library update kicked in, so then both tasks got bogged down fighting for DB access.

Once that was out of the way, I was able to load the new test version. Unfortunately, while it played fine on 1st run, including pausing & then resuming a radio stream as well as stopping it completely and re-starting it, once Kodi was exited, and reloaded, we're back to square 1. Exactly the same behaviour (& Kodi log content) as before. I did make sure to cleanly stop the stream before exiting Kodi after the 1st initial (successful) run.

Since UK radio broadcasts do have either a MPEG2-TS or MJPEG video component, it might warrant putting in a toggle whereby we process the radio stations as if they were TV stations, and see if that has any bearing. Just a thought.

Dan / Gib.

[djp952]

Can I get that Kodi log? I don't know if a stream is audio or video until it's opened. I would love to see what the HTTP headers reported for both the before and after attempts.

I still have no idea what is going on with your Kodi install in that it changes on you after the first time. I wonder if we can start clean, zip the whole thing up, let it break, and zip it up again to see what exactly is changing on you here. I have no reason to say it's my PVR at this point but I would really love being able to tell you what is actually happening!!

[djp952]

PS - I now officially hate Kodi 18 :)

[gibxxi]

Actually, I might be wrong on the above. On my dad's old analogue TV (with a connected set-top-box), he gets an image, on my Sony Bravia, I get the TV's built-in screen-saver (using the TV's own digital Freeview tuner).

Here are the logs from the last two runs...

kodi.old.log
kodi.log

I'm off to bed m8, as I'm shattered. But I appreciate your efforts, and echo your sentiments about Kodi 18. This build has been cursed from the get-go, and it's been nigh on 2 years in the making, which makes the fact even more surprising.

Dan / Gib.

[djp952]

got the files - if you want to delete the links. Will analyze tomorrow, I'm burnt too :)

[djp952]

Actually, I think I give up now. I clearly am incapable of fixing these problems for.you. I can't reproduce them and I can't find anything wrong with anything that has been tried -- these logs match what I expect perfectly across then board. No header anomolies, no unexpected drops, no nothing! I honestly have no idea where to take this next other than to say "US ATSC/QAM video streams only" or "sorry gang but I'm just too stupid". Maybe it's Kodi maybe it's me, but either way Leia has done me in.

I sent Kodi 2 pull requests tonight that may or may not be accepted, but they don't fundamentally change anything of value.

I try not to back away from a challenge easily, but the white flag is officially out now. Kodi Leia has beaten me. I have no way to fix this. That feels pretty awful to say for the first time, too. Damn you Kodi "Leia"... Krypton was workable, Leia is not.

My statements above require sleep before any real permanent changes are committed of course. "Give up" is so uncharacteristic of me.

[djp952]

BTW, I hit "close" by accident last night. I'm also done whining :) I think this just requires a new approach. I need to get myself set up as exactly the same as you are as possible, I'll work on that.

One new thought on the "works after a clean install and then doesn't" -- is it possible that there are any addons auto-updating on you? It doesn't look that way from the log(s), just thinking out loud.

I also wonder if the behavior would be any different if you didn't use the -p switch to hit portable_files for everything. I do that here as well, this way I can have all the Kodis alive and kicking, but it could be worth a shot. Let Kodi just be Kodi without any tricks or addons other than the minimum needed to play around and see if anything changes?

[gibxxi]

Hi Mike,

I need to do some more investigation with regards my setup here, from a Hardware point of view, just to rule out certain things. I have had similar behaviour from Zoltan Csizmadia's DVR add-on over the past 48 hours on the laptop, which runs a single partitioned SSD, but also portable mode just like the other systems.

All the systems I have here are Intel based. Two Haswell (Desktop & HTPC), & one Ivy Bridge (Laptop). I don't want Kodi's userdata on the SSD's on the desktop or HTPC to prevent excessive wear on the SSD's in those systems, as I can't afford to replace them.

I wouldn't go marking your add-on as US / ATSC only at this stage, as it might be a quirk of my setup here that's having a bearing on this. Until you get someone else from the UK / EU report similar issues, I'd leave it as-is. Who knows, this might be down to Kodi itself, perhaps not. Perhaps I've done something dumbass here that's causing it, again, at this point, I just don't know.

I'm putting this on the back-burner for now as I have other issues (real life issues) that are more pressing at this time. If I come across something I feel is the cause, or if 18.1 magically improves the situation (unlikely) I'll update this thread with the info.

Thanks for your efforts looking into this though. I hate unsolved mysteries, but I've spent enough time messing with this at this time. I'm going to take the easy route for now, and look at this again some other time.

Regards,

Dan / Gib.

[djp952]

I understand and concur completely. I need a break from this too :) My mini-rant the other night proves it. See you when you get back, and thank you as well for time and patience you've put into this alongside with me!!

[gibxxi]

Hi Mike,

We have a winner...

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

I've disabled Milkdrop 2 on the only system I have running your add-on currently installed on (desktop) and it plays back fine, or at least, seems to at this time. I tried to tune the stream on two separate runs of Kodi after disabling the visualizer, and had no issue with subsequent playback attempts. The time info is still screwy. I think only current playtime should be being displayed, not total duration + current playback time, as I'm not attempting to record that stream, but I can't blame your add-on for this issue, since it might be a Kodi issue / skin issue as to what I'm seeing with regards duration.

Dan / Gib.

[djp952]

emveepee (Martin) had said that a couple times, I think I was just too focused on trying to find a bug in the PVR or Kodi to really pay attention. Either way - WOOT! Great job @emveepee!

I am fairly certain the bug report I opened is a real bug, but nobody has looked at it yet. Can you try something for me when you have time? Open a live audio-only stream, remember what is being said/played at the very start, and let it play a bit. Seek back to the beginning. Now try to seek forward -- does the stream restart at the beginning again or does it actually seek to where you expected?

What I found was that it looks to me like audio-only live streams are never setting a variable in Kodi indicating their start time. So when the stream seeks forward, it gets a really small offset instead of the proper one. The PVR does what it's asked to do, but it's not right. Recorded ones should be fine, provided you are using the v1.3.13 PVR. I did have yet another mistake in the stream times implementation, but it only affected Recordings this time. ugh.

This could tie into the weird times as well, if it's a legit problem. I still haven't seen that particular problem, but hacking up the PVR to make a recorded stream seem live isn't quite the same, some behaviors are difficult to fake.

I'm extremely glad we finally have some legit progress here my friend! Also can't thank @emveepee enough - we collectively owe him a pint :) (<-- I said that correctly, yes?)

[gibxxi]

You said it correct Mike.

The only thing I have that is really relevant, that's not PVR-based, is the new "Audio Addict" Add-on, but that's music, not spoken word. I'll see if there's anything else I can set up that will work (Like the BBC IPlayer WWW add-on, for example).

Got a pretty busy weekend ahead of me, so not sure if/when i'll get time to do it, but i'll post back here when I have something for you.

Also, don't know if it's worth mentioning here, but the "Shadertoy" and "Vortex" visualizations are not working for me, just get a black screen. Both also cause same issues as with the HDHomeRun add-on, but not quite so quickly. With those I get at least a minute or two of audio (even though the visualizations aren't working in and of themselves) but the stream will die at some point.

I think the weird time issue might be skin-related. In Arctic Zephyr (and it's MOD), I don't get the weird time representation. Will have to re-check this though.

[djp952]

I have a Kodi change I could share if you have updated to Kodi 18.1. It solves the problem with the stream start times, but I think as-is, it's unlikely to be accepted by Kodi. It's more like a band-aid than a real fix, but if you want to see if it solves any more of your issues, I'm happy to share.

You would have to have Kodi 18.1 already installed, this would be a "rename kodi.exe and replace it with this kodi.exe" scenario. Also let me know if you want Windows 32-bit or Windows 64-bit.

I'll keep looking at it to see if there are any other non-invasive ways to solve the start time problem. If I send them a Pull Request for this, I would document it as a 'workaround' as opposed to a true 'fix'.

Understand you are busy, this is just an offer to share :)

[emveepee]

Michael I connected Jack FM into NextPVR and in a very brief test I can timeshift it . https://youtu.be/Q0SD-3oNKzw I have asked Dan for a DVB sample to try but I suspect it is the same as the DVB UK testers that are looking at NextPVR

Martin

[djp952]

Thanks Martin! What is NextPVR reporting to Kodi for times->startTime when handling GetStreamTimes() there?

I think my issue (and now a failry hackish PR that I submitted) triggers when GetStreamTimes() returns something other than zero as the start time. For Recorded streams, I report zero for startTime, but for Live streams I report the time_t when the stream was opened.

I've had a number of problems with GetStreamTimes(), but think it's nailed down finally. I found that setting startTime to zero makes Kodi think the stream is recorded, so all seek offsets are based from zero, so the lack of a proper start time in the demuxer ends up working fine since it defaults to zero.

I'd love to compare notes on GetStreamTimes() with you, I'm 99% sure I've got it nailed at this point, but this function has been the single most annoying thing about Leia. Very possible it's an implementation-specific dilemma, HDHomeRun DVR has it's own unique set of annoyances :)

[gibxxi]

Let me know how big a sample you require Martin, but yes, I'm on DVB-T (UK) so it probably won't be much different. I assume this is with Milkdrop (2) enabled? Mike, I already have 18.1-RC1 (64bit) installed, and am willing to test whatever you can provide. Dan / Gib.

[emveepee]

Hi Dan, I had PM'd you on the Kodi forum. 10 minutes of Radio 6 would be good if you have it, otherwise any channel.

@michael, I will send you a github link when it is refreshed with the current code. There are actually 3 ways of timeshifting with NextPVR. Two of them use NextPVR's circular buffer, one provides unlimited buffer, but basically it works like you described.

Martin

[gibxxi]

Yeah, I was having a senior moment, when I read your previous reply (I was like, "He's not asked me for anything here?), then just logged into the Kodi forums and saw your PM (after the fact).

Give me an hour, as I've just got home from relatives, and I ought to have something for you.

Dan / Gib.

[gibxxi]

...I'll have to do it without visualizers then, because in the case of MilkDrop / 2, Shadertoy and Vortex, I won't be able to get a 10-minute stream without it falling on it's face.

Dan / Gib.

[emveepee]

Ok I don't know how the pvr works for recording, probably you could just create it with curl/wget.

Martin

[gibxxi]

That's a bit over my experience level Martin. My Linux knowledge is bare-bones-basic at best. I'm a Windows guy.

Actually, thinking about it, i'm talking at cross-purposes here. Recordings are unaffected, as they aren't orchestrated through Kodi, so 10 minutes will be fine (Short-term memory loss again).

EDIT: FYI, Kodi will send timer recordings to the HDHomeRun box, which it then forwards to the cloud (SiliconDust's servers). The recordings are then run independent of Kodi, and only notification information about the status gets relayed between the HDHomeRun box and Kodi. In my case, the recordings are recorded to one of my NASes (and if I have the add-on enabled on both, both of them). But the recordings will occur if Kodi is active or not. But I will get notifications on whichever Kodi system happens to be running (at the time a recording is in progress) via the Kodi UI.

Dan / Gib.

[emveepee]

Sorry I just use NextPVR for recording. Curl comes with windows and you would basically do this on a free tuner

curl -o martin.ts -m 10 http://ip:5004/auto/channel

Martin

[gibxxi]

To be honest, I think I might have used wget on Linux at some point (hence the comment), but never used either on Windows, or knew they existed. My CLI knowledge is from back in the MS-Dos 6.22 days, pretty much.

Anyhow, I have a sample for you: https://1drv.ms/u/s!Am5WO9nIAax8gZUVLZrlsQl1jIERRQ

See if that works for you. If I can be of any further use, either PM me on Kodi forums, contact me on FB (www.facebook.com/gibxxi) or send me a PM on the Kodi forums and I'll forward (either of you) my Skype / MSN Messenger details. FWIW, I'm also running a TS3 server here, if a group chat is the order of the day, but I have some niggling issues on the NAS with regards Dyndns.org to fix before I can offer that up.

Dan / Gib.

[emveepee]

I wasn't sure because this said mpg but it is a ts file. It also contains some junk ts streams notable 2/3 of the file doesn't belong.

However It does have the same problem as the files from NextPVR. It starts out slowly but then jumps to a huge pts

2019-02-23 21:15:25.115 T:45908 DEBUG: VideoPlayer::Sync - Audio - pts: 74913393844.000000,

and because of this the EPG Tag thinks it is hours ahead not second so it displays the last loaded EPG title. The issue is why isn't Kodi using the values for GetStreamTimes() which would avoid this.

I can easily spot the difference from these files when I see a large start value in ffplay

Input #0, mpegts, from 'tfz.mpg':
Duration: 00:20:53.04, start: 74913.105844, bitrate: 1129 kb/s
Program 5760
Stream #0:00x642: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 160 kb/s
Stream #0:1[0x1c2a]: Unknown: none ([11][0][0][0] / 0x000B)
Stream #0:2[0x1c21]: Unknown: none ([11][0][0][0] / 0x000B)
Stream #0:3[0x1c66]: Unknown: none ([5][0][0][0] / 0x0005)
74915.66 M-A: 0.000 fd= 0 aq= 22KB vq= 0KB sq= 0B f=0/0

Martin

[djp952]

Sorry I was off doing family things tonight. Looks like you guys are good, just wanted to fill in a couple blanks:

HDHomeRun provides MPEG-TS (.ts) both via the tuners as well as the DVR engine. The main difference between the two is that the raw ts from the tuners is pretty much what was decoded from the source. The recorded .ts files have a bunch of stuffing packets at the beginning of the stream with HDHomeRun specific metadata (JSON format, IIRC) and the PSI packets are sometimes altered. They are valid, but I've seen and had to work around changes made to the PMT specifically that doesn't occur on a tuner stream.

HDHR does decode/demux to an extent, but I'm not sure 'demux' is accurate. For example, if there are 4 'channels' on a specific tuner frequency you will only get the streams relevant to the channel you tuned. I have no clue if DVB sends a bunch of streams and the tuner filters out the ones it doesn't want, or if you only get one 'channel' on a given frequency. Regardless, seeing odd/weird streams in the .ts may be perfectly normal.

Dan, I put a copy of wget.exe as well as a copy of kodi.exe out here for you:

https://1drv.ms/f/s!AgEGEEVzGNq-i9Yd2-6wFEjToltjVg

The wget is in case you want/need it to pull from a tuner directly for Martin (see below). The kodi.exe is a recompiled 18.1 Windows x64 version with my proposed PR about the start times in it. Note that this came from the master branch, not 18.1-RC1, but it should work. Rename your existing kodi.exe first, and then paste this in there instead.

If the kodi.exe blows up, LMK, I can revert the baseline back to 18.1-RC1 and reapply the change from there.

Pulling an mpeg-ts directly from a tuner with wget

• In a browser, navigate to http://ipv4.my.hdhomerun.com/discover
• Find the "LineupURL" for any of the tuner devices (i.e. "http://192.168.0.161:80/lineup.json")
• Navigate to that link with a browser
• You will see a boatload of text, find any of the "URL" values (i.e. "http://192.168.0.161:5004/auto/v479")
• The URL for a stream will be the same for all channels, just replace the "vXXX" with the virtual channel number
• Open a command prompt and navigate your way to where wget.exe is
• wget.exe -O {outfile} {channelurl}

Example: pull transport stream for virtual channel 511 into D:\test.ts:

wget -O d:\test.ts http://192.168.0.161:5004/auto/v511

Just press CTRL+C to stop it when you've reached your time limit. cURL has a timeout command line option, I don't think wget has one. CTRL+C works.

[gibxxi]

That might be something the HDHomeRun box is introducing during the transcode from OTA to recorded stream (attempt at copy protection?). Generally UK Radio streams come with an encoded fullscreen logo rthat's displayed on the TV while the station is being played (at least on analogue TVs) that's the logo of the station being listened to. My Sony LCD TV doesn't show it, instead it shows it's internal screensaver, when tuning from it's built-in DVB-T digital tuner). Then it could be RDS / Eon (Message Traffic Advisory) data. I don't know exactly how the DAB Radio portion of DVB-T is encapsulated for broadcast OTA here in the UK, but I am aware that the standard is used Europe-wide and differs greatly to what you guys in the US have with ATSC broadcasts.

[gibxxi]

In response to Mike:

My local transmitter (Mendip) has a number of "Mux Channels", in the 600-800Mhz range (8MHz separation). Each "Mux Channel" the transmitter uses will have a bunch of "TV Channels" embedded within. There about 6 Muxes for SDTV, and 2-3 for HDTV. There can be somewhere between 8-16 "TV Channels" in each Mux Channel. They also have names, like "PSB1" or "ArqivaA". PBS1 stands for "Public "Service Broadcast (Mux) 1", which contains most of the BBC channels, including some radio channels.

The details for my local transmitter are here: https://ukfree.tv/transmitters/tv/Mendip

Each mux is a single MHz setting, e.g: 690MHz, but in total takes up 8MHz in bandwidth. Non-visual / audio data is also broadcast alongside these channels, stuff like the BBC Red Button UI, and EPG data may also form part of the transmitted data as well as firmware updates on a constant rotation for commonly used STBs.

Dan / Gib.

[djp952]

That's effectively the same as ATSC/QAM here. It's been a long time since I had a regular tuner card hooked up anywhere, and honestly I don't think I even have a PC that could use one anymore :) I've been using HDHR devices exclusively for like 10/11 years now!

[gibxxi]

I dabbled with AllInWonder ATI cards, then Hauppauge cards, then DVBLink dongles, and within the past two years this, as I wanted TV capability across the house, and my current laptop doesn't have a PC-card slot for my old laptop tuner. I'm not using the HDHR4-Connect to it's full potential as I hardly record anything (Most of my content is "downloaded"). TV sucks major ass here if you don't like reality shows or binge watching multiple episodes of the same show back-to-back. As I don't trust Amazon Prime, Netflix or any online streaming service to have the content I want available, at the time I want it, I took the SABnzbd / Sonarr route. ;)

Anyway, back on topic... Your fix works (In a manner of speaking). At radio station stream start, I see this:

-00:01 / 00:00 (Aeon Madnox Music Vis screen)

Then both values increment on a per second basis - until the stream is stopped.

In Zoltan's add-on, I see this:

00:00 / ∞

My point being, we don't really need to see the "total duration", all we're interested in seeing here is the total (current) playtime. In your add-on the positioning is reversed (e.g: total duration appears on the left, with current playback time on the right. Programme duration is broadcast as part of the OTA stream, but don't know how you'd access / process that. I also don't think the HDHomeRun uses the OTA EPG guide as I have 20 channels or so that get no information, whereas my TV's tuner displays it without issue. I think what I'm seeing in Kodi may be coming from "SchedulesDirect" by way of the fact I'm a DVR subscriber. Martin's users may be able to confirm or deny this as if memory serves (I have used NextPVR in the past, when I DID use a dedicated TV card) that it may get it's EPG guide from the raw transmitted data, unless the user sets up XMLTV explicitly.

Regardless, all that needs to be shown on screen is current playtime, even if paused / timeshifted, as there is no known end time for the current stream / programme available anyhow. If the playback is stopped, the timeshift buffer will be deleted, so it's not useful in that context either. Having two "durations" on screen that are both incrementing is just (IMHO) confusing to the end-user.

Your thoughts on this?

Dan / Gib.

[emveepee]

The sample file only contained data from one mux, and the valid par tof the file is about 27K. It plays fine in Kodi as a file which was my main concerne. It would be pretty stupid if if Silicon Dust was muxing in the OTA EPG data with each recording, but that would be rejected by Kodi anyway and is not the problem.

I am basically not interested in how you are try to skin this, the bottom line IMO when it works for non UK streams is the navigation bar for radio and TV look alike and it is the metadata from the Kodi EPG database on the screen.

[gibxxi]

My previous comment was for Mike, but I don't think it's a skin issue. it's displayed as described above in Arctic Zephyr (BassMasterRS MOD) as well, so either it's down to Kodi or Mike's add-on. This part of the discussion was touched on before you joined the chat Martin. This thread has meta-morphed into a "general issues with pvr.hdhomerundvr"-type discussion, along it's progression, the Kodi "freeze" being the most annoying aspect.

However, thanks to your discovery with regards the NextPVR add-on, and my subsequent testing under the same conditions, we came to the root cause of the freeze which had eluded both me and Mike prior. I wouldn't put the blame at Milkdrop's door at this time (specifically). Neither Shadertoy or Vortex work in Leia either, and both also (for me) cause similar issues as with Milkdrop / 2, albeit not quite so quickly. So I think the blame lies there, not with either PVR add-on or the visualizers themselves.

Don't forget, in Leia, the structure and handling of the Music Library has been changed significantly, so the player has likely been modified to handle these alterations. I think it's there, that the incompatibility lies, not with Milkdrop in and of itself. I wait to be proven wrong.

Dan / Gib.

[emveepee]

Ok I thought Michael wanted to be able to seek in these feels too and he should be able to accomplish that. I will continue to see if I find a fix. Thanks for sharing the file.

[gibxxi]

Possibly. My comment is that, as a user, I don't need to see two durations. Even if seeking / time-shifting. In 17.6 a progress bar appears in the skin if a stream is time-shifted. I haven't seen that in the 18.x version of this skin, so far. The "Total Duration" time is (AFAIK) relating to the total duration of the programme, not the total length of the stream. I may be incorrect here too. That info doesn't seem to be being passed from the HDHomeRun as it stands, regardless.

So essentially, my argument is, if we can't determine programme duration, get rid of the second duration indicator as it's simply mimicking the other value. Or, maybe replace it with the infinity symbol (like in zoltan's add-on) until such times as a stream is paused / time-shifted, then display the total duration of the stream, assuming programme duration info is unattainable. Which may also be safer, since someone may pause / timeshift a stream across programme boundaries anyway, which would certainly result in some funky conditions (potentially).

The whole issue makes my head spin.

:)

Dan / Gib.

[emveepee]

On Estuary there are two durations and they make sense. One is the running time in the show in minutes hours which you you need to know for relative skipping. The other one is the start/end clock time for the show which is informational. There is the other dispaly that shows the timeshift time, which I feel is a little over the top but some people like a lot of info

[djp952]

I can't say that I disagree with your UI concerns, but that stuff is squarely in the realm of the skin(s) to deal with. Estuary also uses EPG data to replace the raw times when available. In my experience here, it's very rare to see the raw stream times in Estuary. Mainly if the EPG isn't done loading yet :)

I'll see about taking care of the -01:00/00:00 start time, I think that's a function of using the time when I "start" the stream as opposed to when it actually started. The demuxer uses small fractions of a second internally and the start time is indicated in whole seconds only, so there will always be some level of dela there. "Close enough for government work" I guess!

I haven't seen any comments on my PR yet, but you should be able to keep using that Kodi.exe without any problems, it's technically newer than 18.1 by a handful of commits, but not by anything that looks like it may cause you a problem.

[gibxxi]

Fair enough Mike, put it down to me being a bit OCD. ;)

In as far as the main issue, going forwards, we have a work-around (don't use visualizers - at this time). We'll have to wait and see what (if anything) Team Kodi do to diagnose why, and where, the conflict lies, and if they'll fix it. I think we're looking at 18.2 at best here.

I do agree with you though, Leia has been a build that's tried to re-invent the wheel somewhat, IMHO. They've brought the music library up to speed, which was long overdue, but there are a raft of new issues / bugs introduced that will undoubtedly take some time to work through and fix. That and it's taken them the best part of two years to get it "out there" makes it even more shocking IMHO. They should be doing more checks on their own code before pushing builds out there to avoid the sheer raft of posts in the forums, again, IMHO.

The attitude of some of the developers (on the forums) and their rank arrogance also irks me somewhat, and as a regular user it would put me off contributing back. However, that's an issue for another time / place.

I guess all that's left, is for me to thank you and Martin for your assistance in getting to the bottom of this. I absolutely hate unsolved mysteries.

Regards,

:)

Dan / Gib.

[emveepee]

Hi Michael I applied you PR and basically it doesn't change anything to help seeking with aac streams for me.

Martin

[djp952]

Dan:

Understood. I believe we still have at least one unanswered request - moving channels from TV over to Radio. Are you still interested in that? I have a generally unobtrusive plan in that regard, I was thinking a simple text file that while end-user created, would be simple and persist outside of the PVR database (in case the database needs to be cleared/deleted).

It wouldn't be difficult to add context menu options like "Move to Radio" or "Move to TV" on the channels to control it, just like "Add to Favorites" and "Remove from Favorites" are there now.

Is this still something you would like me to pursue?

Martin:

Bummer. Can I help? I can try pumping your files through my PVR to see if I can come up with anything. I'm all set up with Leia debug build right now, so it's not a problem. If they aren't MPEG-TS I will just need to know the MIME type you are sending in via GetChannelStreamProperties so I can fake it. LMK, I would like to be able to assist if I can.

[gibxxi]

Since there are channel groups support in Kodi, perhaps it would make sense to make use of that somehow? The worry isn't for me personally, as I know enough about Kodi to get it done. But it needs to be relatively easy for an average (non-pc literate) user to accomplish as well. If that's not possible, I think it's better to leave it as is. The issue exists because of the way SiliconDust have designed the unit, which unlike the TV cards of old, makes no distinction between TV and radio channels.

Given the number of existing "issues" with Leia, it might be better to put this one on the back burner for now and re-visit it at some other time. That's not to say I've lost interest in the idea, far from it. But I'm of a view that as of right now, i'd like to spend some time enjoying my media collection, rather than fighting with it.

If you have an idea you want to put in motion, by all means go ahead, and if you want me to try something, I'll do just that. But I wouldn't place any great urgency on it, at least, not at this time.

Dan / Gib.

[emveepee]

@michael the streams I used for testing were AAC in TS container, now I am testing with whatever the source is so mp2 mp3 aac or he-aac. Dan's sample above is good because it shows the UK DVB problem and skipping problems. I have kind of hacked NextPVR to send internet radio streams instead of wasting a tuner. In the UK they have 320kb audio and I am jealous here in Canada we don't have FTA radio other than FM and capture cards are low quality.

Glad I don't have issues with Leia or Estuary they are fine for my purposes.

Martin

[djp952]

I could swear I posted this already, but it seems not? OK, I'll do it again :)

I ran Dan's file through my PVR, both as recorded and pseudo-live and didn't run into any playback issues. I did check it with an MPEG-TS analyzer and it noted a discrepancy in the file at packet 337277 (continuity count). I see that in the Kodi log, but it's seemingly the only glitch/problem it ran into:

2019-02-25 19:36:32.653 T:5432 DEBUG: ffmpeg[1538]: [mpegts] PES packet size mismatch
2019-02-25 19:36:32.952 T:5432 DEBUG: CVideoPlayer::CheckContinuity - resync forward :1, prev:449217844.444443, curr:458025844.444448, diff:8784000.000005
2019-02-25 19:36:32.952 T:5432 DEBUG: CVideoPlayer::CheckContinuity - update correction: 8784000.000005
2019-02-25 19:36:40.772 T:7820 ERROR: ffmpeg[1E8C]: [mp2] Header missing

I would say that seeking is slower than I would expect it to be for a simple stream, and it's always accompanied with a log from ActiveAE::SyncStream indicating that it has to resync things, but I'm not seeing the same completely wonky "VideoPlayer::Sync - Audio - pts" values you are with that file. They seem quite reasonable to me, actually.

Now, I have to caveat this with I'm tricking my PVR to play it by just replacing the URL for any LiveTV channel stream. So the EPG thinks I'm actually watching a TV program.

One thought -- it looks like NextPVR isn't implementing the GetChannelStreamProperties() function. IIRC I had trouble with some stuff until I implemented that to indicate at least PVR_STREAM_PROPERTY_ISREALTIMESTREAM. Now I actually set both that and the MIME type based on the stream in that function. This also allowed my PVR to stream more than MPEG-TS again under Leia. I couldn't pump MP3 or AAC through it unless I specifically indicated the proper "audio/xxxx" media type here. I had it hard-coded to "video/mp2t" until recently.

DVDInputStream uses the PVR_STREAM_PROPERTY_ISREALTIMESTREAM now, I'm not sure where the old IsRealTimeStream() function result ends up being used, but I know it's still called. I set it in both places.

Example:

 	// PVR_STREAM_PROPERTY_MIMETYPE
	snprintf(props[0].strName, std::extent<decltype(props[0].strName)>::value, PVR_STREAM_PROPERTY_MIMETYPE);
	snprintf(props[0].strValue, std::extent<decltype(props[0].strName)>::value, "%s", g_dvrstream->mediatype());

	// PVR_STREAM_PROPERTY_ISREALTIMESTREAM
	snprintf(props[1].strName, std::extent<decltype(props[1].strName)>::value, PVR_STREAM_PROPERTY_ISREALTIMESTREAM);
	snprintf(props[1].strValue, std::extent<decltype(props[1].strName)>::value, (g_dvrstream->realtime() ? "true" : "false"));

	*numprops = 2;

GetChannelStreamProperties/GetRecordedStreamProperties are called at an inopportune time for me, I had to actually open the stream in that function to get that information accurately and then block the subsequent calls to Close/Open. I had PR that was rejected to not automatically call Close before Open, but c'est la vie.

Anyway, might be worth a try setting the MIMETYPE and ISREALTIMESTREAM properties to see if it makes any difference. I wish I remembered exactly what I ran into, but it was way back when I started porting over to Leia.

LMK if you want to see any logs or if there is anything specific I can do with Dan's file to try and replicate the behaviors you are seeing!

[djp952]

Left out an important tidbit: the MIME type for all HDHomeRun streams, both recorded and from the tuner is "video/mpeg". Doesn't matter if there is no video elementary stream in it.