Forward/backward skips often go to random places or start of recording about pvr.hts HOT 48 CLOSED

I'm also getting this behaviour. I've got the new 15.x adaptive-seeking turned off.

My setup is like this http://kodi.wiki/view/Skip_steps#Instant_skipping with -10s +30s and no delay.

I'm running Ubuntu 15.04 with:
kodi 2:15.1git20150816.1137-final-0vivid
kodi-pvr-hts 2.1.17-1vivid
tvheadend v4.0.5

from pvr.hts.

Could any of you please provide a debug log and highlight at which point the bad skip happens?

from pvr.hts.

Reference (was closed as an addon bug): http://trac.kodi.tv/ticket/16199

from pvr.hts.

Sorry I didn't get a chance last night. I'll grab some logs tonight.

Do you want any component-specific logging enabled? (I don't know if those add or remove information)

(FWIW, as per the trac ticket, this started happening for me on the 14.x -> 15.x update when I got the new pvr plugin)

from pvr.hts.

Nah, a basic debug log should do the trick.

from pvr.hts.

https://gist.github.com/sdt/bfac4401387da853f743

Took a little while to repro it - I was starting to fear it was a heisenbug.

Both logs have some comments preceeded by a blank line and then ###

The first log has the jump-forward-while-seeking-backward behaviour.
The second has the jump-back-while-seeking-forwards.

In both cases I hit the button, see where it has seeked to, work out where it should be next, then hit the button again and so on. Fairly rapid succession, but not hitting the button in the middle of a seek.

from pvr.hts.

Hope that the following is a useful extract of the debug log showing a "jump back to start of recording" example. When it goes wrong, the "seek to" timecode goes negative and hence playback starts again from the beginning of the file.

https://gist.github.com/roswellgrey/28673b359d94c3c17026

from pvr.hts.

@perexg do you think this could be a tvheadend issue or is it definitely something in the addon? The same type of negative seek is what causes playback to jump to the beginning when skipping in the timeshift buffer.

from pvr.hts.

I will just note that there are four different frontends connecting to my TVHeadEnd backend. One is still running XBMC Gotham, one is running Kodi Helix under Ubuntu, one is Kodi Helix on a Mac desktop, and then there is the new one running Kodi Isengard under Ubuntu. ONLY the new one has this problem - the one running XBMC and the two running Kodi Helix have no issues with skips. And the new one has no problems with skips if I access the .ts file directly via the Videos menu (without going through the PVR addon). The only common denominator that I see is the PVR addon that is used if you go to "Live TV" and then try to play the recording from the "Recordings" submenu, but only in Kodi Isengard, and possibly only if you are using Ubuntu as your O.S. The fact that all the other frontends have no issues with skips is what makes me believe that it cannot be a TVHeadEnd issue

from pvr.hts.

To add to the above - likewise, I only experienced this when upgrading to Kodi Isengard (from helix), and similarly have no issues at all with accessing the ts container via "Videos" .... however ... my Kodi clients are Win 7 - in my case, it is not unique to a Ubuntu/Linux client ...

from pvr.hts.

Further bit of context, for Linux and tvheadend 4.0.5:

I experience exactly what's here with OpenElec x86_64 5.95.3 and pvr.hts 2.1.16 and, on Ubuntu 14.04, with Kodi 16.0-ALPHA2 Git:0aa0ee7 and pvr.hts 2.2.5.

from pvr.hts.

I can confirm that this behavior is only appearing after an upgrade of Kodi to version 15 and above. Since the new seeking was implemented I'm able to seek much further (and faster) in the buffer than before, and it is at that point that the seeking becomes erratic. My point is that the bug might have been there before the upgrade, and that I'm just experiencing it by seeking further than I used to.

from pvr.hts.

Another example where previous GENERAL_RESYNC goes negative and causes subsequent erroneous "seek to" time (although in this case the "seek to" time didn't go negative - it just caused a large leap backwards)

https://gist.github.com/roswellgrey/2935147856a605af27d3

As I can (infrequently) reproduce this with my setup, I would be more than willing to, for example, run a custom build with more debugging added if it would help ...

from pvr.hts.

As I implemented timeshift for vnsi I had a similar issue. An old demux packet in the queue messed up timestamps. Now I tag demux packets with a serial that is changed on every seek. Packets with a serial that does not match are discarded. Maybe that helps:
kodi-pvr/pvr.vdr.vnsi@b6dba48

from pvr.hts.

@Jalle19
Maybe we need a 'm_buffer.reset()' and 'm_bHasData = false' before the seek too, so no older packets can sneak in while tvheadend is progressing the seek?
so here: https://github.com/kodi-pvr/pvr.hts/blob/master/src/HTSPVFS.cpp#L181

I bet it goes wrong somewhere here if we indeed have older packets as @FernetMenta suggested:
https://github.com/kodi-pvr/pvr.hts/blob/master/src/HTSPVFS.cpp#L168
After a seek, the buffer is empty, so we are waiting on this condition, but if we are skipping again now, we can get old packets as the buffer is only reset when the complete seek is done? Just an assumption, I've no way to test this now.

from pvr.hts.

I am also having this issue on a fresh Kodibuntu installation and on a macbook. Both with Kodi 15.1. So definitively not an OS specific issue.

from pvr.hts.

I know this is now an official bug, but it's kinda unclear from the history whether it's "dev reproducible".

Is it a replicatable "thing" from a developer perspective now, or is there something us users can still help with to get it to that point?

from pvr.hts.

I'm experiencing this too with Openelec 5.0.8 (which is Helix). My tvheadend client is version 1.9.40.

from pvr.hts.

@BoxFreak are you sure it's the same bug? All others say this is a regression and that it used to work in Helix.

from pvr.hts.

@Glenn-1990 I think you and @FernetMenta are right, that's probably where things go wrong. I haven't had any time to work on Kodi for a while unfortunately.

from pvr.hts.

@Jalle19 Yes I think. Recently I've only encountered it with timeshift -buffer because I haven't used my system for recording because of general unreliability. I can test recordings too if it's necessary and makes any difference.

from pvr.hts.

The timeshift buffer and recordings are two very separate things from a code perspective so it's unlikely that the issues are related.

from pvr.hts.

OK, just tested playing back recording, and it works just fine. So problem is only with timeshiftbuffer. Sorry about this confusion.

from pvr.hts.

@tv21 I get your point, but I just think you should refrase that so it would be a request. As it is, it sounds pushy to me.

from pvr.hts.

@tv21 holy shit, get ahold of your entitlement and back off. Good grief, I can't even.
No excuse to act like an asshole like this. VOLUNTEERS doing this work. Nobody owes you anything.

Ninja edit: @bas-t people who do things like this don't understand soft spoken reproaches. So (at least, IMO) it's better to be blunt. The prick hasn't even produced the asked-for debug log.

from pvr.hts.

@bluenote73 That's what I ment, but I like to keep my voice a bit down.

from pvr.hts.

@tv21 you are extremely annoying to everyone ... you could have picked it and PRd it - but instead you tell here a big story. We owe you nothing, absolutely nothing.

from pvr.hts.

I hope @Jalle19 gets not too disappointed reading this. @tv21 you'd better terminate your github account.

from pvr.hts.

fritsch, you seem to look for reasons to be annoyed (why do you even hang around if user comments annoy you so much?) so I wouldn't even respond if it were only you that were annoyed. To everyone else, though, I apologize if my comment was over the top. This bug is SUPER annoying and all I was trying to say is that I think we would all be very appreciative if one of the developers could find the time to work on it. I did not intend to come across as demanding or entitled, after all I know this is free software and we have no right to demand anything, but sometimes I just wonder if the developers that may not be experiencing this bug (for whatever reason) have any idea just how annoying it is. On a scale of software annoyances, this one's a 10 in my book. So I just really hope someone's looking at it, or will do so in the near future, because I think we will all be VERY appreciative when it's fixed.

Again, I'm very sorry if my original post came across as rude or demanding, it was not intended to be, but I have been told that sometimes when I write things people who read them won't take them the way I intended, so while I won't go as far as to terminate my github account, I won't make any further posts here.

from pvr.hts.

fritsch, you seem to look for reasons to be annoyed (why do you even hang around if user comments annoy you so much?)

Yeah, good question. When I read your comments I don't really know why I waste my free time to write free software for you. And if you did not get it - everybody that is subscribed to this repository gets automatically emailed with every comment - so basically it was not my choice to read your comment ...

from pvr.hts.

I'm confused. It was just a comment???

from pvr.hts.

Annyhoo ;)

As-per my comment earlier: is this considered a known, reproducible, issue now (little hard to tell from the responses) i.e. is there anything we can do, user-side, to help with more information, debug logs etc when we see it happen?

Oddly, I've seen it happen quite a bit less of late, although nothing's changed in terms of my setup...

from pvr.hts.

This bug seem to be existing in all versions of Kodi 15.2
I can confirm that I am experiencing it under FireTV(Android), Mac OS (Yosemite) and Windows 10.

from pvr.hts.

I have Ubuntu 14.04, TVHeadend 4.0.5 and Kodi 15.1 and I also have the same issue reported here. I am about to downgrade to Kodi 14.2 to make my system usable.

from pvr.hts.

@cotman yes I can reproduce it from time to time but I haven't been able to track down the root cause yet.

from pvr.hts.

@Jalle19 Thanks. It is strange - I saw it a lot, then not so much, but very recently a lot more.

from pvr.hts.

I can see that still no one is assigned to this ticket. Is someone going to pick this up, please please please...

from pvr.hts.

Don't whine whine whine...
if that someone is not you.

Op 16-09-15 om 21:07 schreef speedyrazor:

I can see that still no one is assigned to this ticket. Is someone
going to pick this up, please please please...

—
Reply to this email directly or view it on GitHub
#92 (comment).

from pvr.hts.

@Glenn-1990 I tried your approach to fix this issue by resetting the buffer and invalidating it. It took me a while to get the build system up and running. Unfortunately it seems that the issue persists.

from pvr.hts.

@beralt Could you also add this?
So keep the code you already changed.
Glenn-1990@4be5911

I might be totally wrong here, I don't know much about this part of the code, but it's an attempt ;-)

from pvr.hts.

@Glenn-1990 That seems to fix the issue. I've tested this a few minutes ago, and I cannot reproduce it. But I'm a bit worried about the fix itself, since other code paths lead to reset of the buffer too. A more elegant fix would be to invalidate certain packets in the buffer, instead of clearing it out. But I'd rather leave that to the experts.

from pvr.hts.

if this fix is included in the V 15.2 RC 2, then it does not work.
Tested it on FireTV Stick.

from pvr.hts.

No fix id included anywhere yet.

from pvr.hts.

Testing what was merged - have only been using it for a short time, but it does appear that I can confirm it resolves the issue for me. I'll be giving it some more heavy usage later on. Thanks so much for working on this.

from pvr.hts.

Looks good, is this going to be committed to master?

from pvr.hts.

It was already.

from pvr.hts.

Is it in 15.2 or 16?
Im on linux, if I use one of the below will I get that fix uncluded?

ppa:team-xbmc/unstable
ppa:team-xbmc/xbmc-nightly

Kind regards.

from pvr.hts.

Yes.

from pvr.hts.