pvr.nextpvr timeshift seek bar reproducibly breaks at specific buffer length Android

[mmortal03]

This is why I need your Kodi debug logs.

Martin

Almost there. I was hoping to use the Windows 10 32-bit install to get the logs, but the bug *isn't* present there, I can confirm.
Also, Android-x86 64-bit will only accept a 32-bit Kodi install, but I *was* able to reproduce the bug there, so that's three for three on 32-bit Android Kodi.
Give me 35 minutes and 47 seconds and I'll have a debug log for you from the Fire TV Stick 4K.

[mmortal03]

Ok, here's a debug log from the Fire TV Stick 4K. I actually left it playing this time, but I was also noticing picture artifacts. I don't know if it's a storm interfering with the signal in the area or just the debug log impacting performance. I noticed in the log a lot of packet corruption errors. Anyway, I believe the timestamp for the beginning of playback was about 00:28:29.

https://www.dropbox.com/s/prhmdisc46yufe...9.log?dl=0

I'm going to continue working on this to produce another log from a different channel that may have a better signal, and just keep it paused most of the time to see if that cuts back on any packet corruption errors.

[mmortal03]

Okay, here's another log, where I kept it paused for almost the entire time (did not let it play through the bug). This cuts down on the corrupt packet errors.

https://www.dropbox.com/s/dw3yx4ytx2aoz3...9.log?dl=0

01:33:19 This was the displayed start of the timeshift playback.
02:09:08 This was when I stopped it, *immediately* after the seek bar disappeared, as in, only a second or so after.

I'm no expert on these logs, but I honestly don't see any weirdness in the entries just before I stopped it. I'm guessing this bug may be behavior that's not getting output to the log?

[mvallevand]

I do see something and sorry I wasn't clearer I will need the NextPVR logs to go with the Kodi Debug log.

Martin

[mmortal03]

I do see something and sorry I wasn't clearer I will need the NextPVR logs to go with the Kodi Debug log.

Martin

This isn't verbose, but, based on the timestamps, it looks like it contains all the instances of my testing from yesterday and early this morning: https://www.dropbox.com/s/6x4n3xo53d34bv...9.zip?dl=0

[mvallevand]

Thanks I rarely need verbose logging. It does look like an issue going over max 32 bit int but it seems everything is defined int_64. However there was one issue that I think it is just logging but and a possible issue parsing the long values from the xml. I updated the build could you sideload the appropriate zip https://jenkins.kodi.tv/blue/organizatio.../artifacts and see if makes any difference.

Also when you say you have no EPG that isn't quite right since you haven't defined it as None in NextPVR. As a result Kodi will keep polling for missing EPG data. You can change that poll in advanced setting if you want or just auto map the EPG to None

Martin

[mmortal03]

Thanks I rarely need verbose logging.  It does look like an issue going over max 32 bit int but it seems everything is defined int_64.  However there was one issue that I think it is just logging but and a possible issue parsing the long values from the xml.  I updated the build could you sideload the appropriate zip https://jenkins.kodi.tv/blue/organizatio.../artifacts and see if makes any difference. 

Just tried it, bug still present!

Also when you say you have no EPG that isn't quite right since you haven't defined it as None in NextPVR.  As a result Kodi will keep polling for missing EPG data.  You can change that poll in advanced setting if you want or just auto map the EPG to None

Yeah, I do still have NextPVR configured to pull the EIT guide data, as you know I'm just running into that other bug that sub is going to have to investigate, where I'm only getting three-hour chunks of guide data, even though you were able to provide evidence that more was there in the transport stream.

But back to the current topic, I recall a probably related bug in pvr.wmc and Kodi where various problems would occur on the seek bar and live recording if guide data wasn't present. Since krustyreturns was uninterested in coming up with a fix, it was suggested on another forum to try injecting dummy/placeholder guide data using EPG123. It seems more appropriate, if possible, to first try to come up with a direct fix in the code, but I thought you might appreciate the basic concept of having NextPVR pull dummy EPG data to work around it:

https://www.thegreenbutton.tv/forums/vie...32#p136932

and then: https://www.thegreenbutton.tv/forums/vie...38#p136938

[mvallevand]

I don't see any bugs in the code, other then that display bug. The seek bar handling is all done in core and like krustyreturns I am not interested in looking into a core fix. What you probably need to do is duplicate it in pvr.wmc and pvr.nextpvr and create a Kodi issue which possibly someone is interested in fixing.

Note there is a use reason for the seek bar disappearing when you are using NextPVR. If the tuners is needed for another reason timeshifting won't stop. The bars will disappear and allow you to play out the buffer. I can't let users seek in the buffer because I don't know if the will seek to the end or not, so it is play or end only.

As for dummy entries I wanted to do it and had them coded and ready for NextPVR but I was stopped before I could get started https://forum.kodi.tv/showthread.php?tid=350204 PVR developers cannot do anything without the support of ksooo.

Martin

[mmortal03]

I don't see any bugs in the code, other then that display bug.  The seek bar handling is all done in core and like krustyreturns I am not interested in looking into a core fix.    What you probably need to do is duplicate it in pvr.wmc and pvr.nextpvr and create a Kodi issue which possibly someone is interested in fixing.

Ok. Any idea why the bug would only affect Android? I guess that's a question for the core Kodi devs. I'll see what I can do.

Note there is a use reason for the seek bar disappearing when you are using NextPVR. If the tuners is needed for another reason timeshifting won't stop. The bars will disappear and allow you to play out the buffer. I can't let users seek in the buffer because I don't know if the will seek to the end or not, so it is play or end only.

Good to know. Speaking of issues with the seek bar, I decided to test importing some EPG data from an XMLTV file into NextPVR (more on this later) just to see how that would affect seeking, and I've gotten at least twice now frozen playback of the video and audio where I've had to stop the stream because it just stays frozen. Who knows what's going on there. I hadn't had that happen without guide data. To be sure, I went back to the official version of pvr.nextpvr in the repo, and got the same exact freezing, so it's nothing that you've just done. Anyway, I'll have to start another thread on this new issue once I've got more evidence of this.

As for dummy entries I wanted to do it and had them coded and ready for NextPVR but I was stopped before I could get started https://forum.kodi.tv/showthread.php?tid=350204 PVR developers cannot do anything without the support of ksooo.

Thank you for all your efforts. Tangential to this, I was just able to pull 12+ hours of EPG data using EPG Creator from the ATSC signal, and import that XMLTV into NextPVR, so I'll have to follow-up with sub in that other thread.

[mmortal03]

Well, dang, after testing *with* guide data on Android 32-bit, unfortunately, the bug still occurs, after exactly 35 minutes and 47 seconds. If you have the channel paused when it happens and you have the seek bar selected, it will at least let you frame advance, but as soon as you move off of the seek bar it won't allow you to move up to select the seek bar again, and *all* seek functionality breaks. You can't even skip ahead to the next program -- it tries, but doesn't actually do it. So, now that I'm seeing this occur even *with* guide data, it seems very weird to me, because I can't imagine that I'm the only person using a pvr add-on with or without guide data, doing timeshifting on Android 32-bit. Whether it's, in fact, a core Kodi bug or not, how is it the case that no one else has noticed this? We know it's not a regression in Matrix, so it's just really weird to me that I'm the first person to report it.