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

[gibxxi]

Within the native HDHomeRun setup tool, the extended (real) proper-case channel names for scanned channels are displayed. Within Kodi (18.0 "Leia" - RC3) Only the truncated "Shortcut - All CAPS" channel names (abbreviations) are displayed.

My setup uses OTA guide data provision that's broadcast along with the channel data, and I'm based in the UK, using the Mendip Transmitter. I experience no such issues using any of the other HDHomeRun PVR add-ons available from the default Kodi Repo add-ons, but they don't provide recording functionality.

[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.