Dropped frames

[Snippo]

fritsch suggested it might be an issue with TVHeadend, but I think the problem might be in the addon.
The stable version of Kodi works without dropped frames, but using the latest nightly (+addon) there are a lot of dropped frames when watching Live TV.
The relevant logs can be found in this post: http://forum.kodi.tv/showthread.php?tid=231955&pid=2288583#pid2288583

Also, TVHeadend doesn't show any errors or other unexpected behaviour.

[Jalle19]

I've responded to the thread. Doesn't look like an addon issue to me.

[Snippo]

Opening a stream in VLC also works fine so it's an issue of the combination Kodi + addon. As I understand from the thread something has to be changed in the addon?

[Jalle19]

I'm not sure yet, I'd have to test it myself. It's odd that no one else has reported the issue.

[MrMC]

verified, reverting xbmc/xbmc@5cadf11
fixes bad behavior. Most noticeable if tvh pvr server is remote and not on local network as client. Might not show up if tvh pvr server is local to client.

[ksooo]

@FernetMenta ^^^ ?

[FernetMenta]

@ksooo I already mentioned this. Don't call SetSpeed on the backend if speed did not change

[MrMC]

I'd prefer core not hammer on client telling it to SetSpeed over and over when it did not change :)

[ksooo]

@FernetMenta I agree to what @MrMC said. Changing the add-on to not call the backend if nothing has changed is nevertheless a good idea. But I would like if core could be optimized as well.

[FernetMenta]

I would rather kick this hack completely out of core. This is a very specialized behaviour player should not bother with. Only a few network streams require to be paused when you stop reading for a longer period. Ideally this behaviour is handled by demuxer/inputstream itself.
I never understood why you need this here. VNSI is fine without.

[Jalle19]

Another option would be to ignore SetSpeed requests in tvheadend itself if the speed hasn't changed, but for backward compatibility I guess we'll have to do it in the addon. I'll try to whip up a PR.

[FernetMenta]

I already submitted a pr to kodi

[MrMC]

Verified xbmc/xbmc#9555 works on slow tvh pvr servers.

Someone needs to verify that the reason for xbmc/xbmc#3377 is still ok.

[Jalle19]

@FernetMenta thanks a lot!

@Snippo in the future, never trust @fritsch when he says something is tvheadend's fault. He'd blame his cold coffee on it if he got the chance ;-)

[Snippo]

I have the TVHeadend server local to the client so that makes no difference. However, I get problems only after like 30 seconds. Maybe it happens sooner for remote clients.

@Jalle19 Haha ok. I'm glad it got solved. Thanks.

@FernetMenta Is this also fixed in your fork? Because I believe the VAAPI build is based on that?

[MrMC]

what ? no love for me for dogging it down :)

[fritsch]

@Snippo no not fixed - just see the build date that you are running. Will be build automatically in the night after it appears in fernet's master branch.

@MrMC thanks very much - with love :-)

[fritsch]

@Jalle19 my ratio is still arround 90% - meaning: 90% of the bugs are in deed tvh bugs, measuring over the past 4 years. But I am happy that I am wrong this time, cause it means your software gets better and better :-)

[Snippo]

@MrMC Thanks to everyone who helped ;). Without you it would still be a "TVHeadend bug" haha.

@fritsch Any clue when it gets added to fernet's branch? At the moment I'm still using a build of 2 weeks ago but I'll update when this bug fix is added. Also, I compiled it myself from fernet's branch, this makes no difference right? (I'm using Arch linux)

[Jalle19]

@MrMC thanks
@fritsch 90% is perhaps a bit of a stretch, that would imply that since you were wrong this time you must have had been right on nine separate occasions before. But let's not nitpick about that.