[goodton]

I have an annoying issue in Krypton PVR. Every time a TV-channel is started or changed, there is stuttering on video, until it suddenly syncs perfectly. This phase can last from couple of seconds to even 10 seconds. When the channel is "locked", it will stay synced. Not a showstopper but as I said, surprisingly annoying. And this happens in every channel.
EDIT: During this syncing phase also audio has some very short dropouts.

This issue is not present in Kodi 16.1, also WMC handles these situations perfectly. I have toggled pretty much every button in settings and interlacing options, no cure.

Debug log attached:

http://pastebin.com/rA7WkZVf

For example in this debug log the channel sync after starting, is gained in this time stamp:
1450.18:27:52.967 T:3948 DEBUG: CDVDClock::SetSpeedAdjust - adjusted:0.000000

Additionally in this debug log I also switched to a channel, which happens to use teletext subtitles. I´m aware of that there is not much development on that side to get them handled better in Kodi. But there is clear bug, which to my knowledge can be seen only in Windows. When a subtitle page is selected the black background behind subtitles is staying in whole screen as it should be shrinked to the size of the text. In practice the actual video cannot be seen. This functionality has worked on some previous Kodi-versions but I think that Jarvis introduced this first.

Only way, which I have found, to get it shrinked is to toggle the PlayerDebug-screen first on the screen and then toggle teletext on.

[FernetMenta]

Please elaborate on "stuttering". Could you create a short video that I can see what you are observing.

[goodton]

Please elaborate on "stuttering". Could you create a short video that I can see what you are observing.

According to PlayerDebugInfo there is no skipped or dropped frames, the picture is just not fluid on start. To me it seems like Kodi is taking quite long time for identifying the FPS of live-tv -stream = easily over 5 seconds, observed from the PlayerInfo-overlay. Could that be somehow related to this? Just for the curiosity I took a look also into couple of other PCs in our household equipped with Kodi and this is what I observed:

Win10 x64 Intel CPU + Nvidia GTX 970 -> Same audio issue with short dropouts until the problem disappears. Challenge with this setup is that the monitor does not support 50 Hz refreshrate, so Kodi is not able to switch to that display mode -> "stutter"-effect is difficult to spot, if there is any.
Win10 x64 Intel CPU + Radeon R9 270X -> Here the video seem to be in sync immediately on Sony TV but same audio dropouts are also present here. But here the video problems are related to interlacing. When this final FPS-identification happens, the interlacing is dropped out. Need to be toggled from the Video OSD -menu to get it working again.

Quite probably intentional but when this FPS-identification phase in ongoing, the PlayerInfo-overlay is informing 50 Hz refreshrate initially for all of the channels (correct as broadcast is in Finland) but when this final FPS-detection is done, for interlaced content, it is dropped to 25 Hz. Immediately after that the interlacing is lost.

[FernetMenta]

Would it change anything if you switched to from DirectSound to wasapi?

[goodton]

Would it change anything if you switched to from DirectSound to wasapi?

Good idea, worth of testing. Yesterday I tested also a recording from Live-TV, the FPS-identification phase is similarly long but the video is synced immediately. So I suppose this is not related to FPS-detection, something else is happening on live-stream and yes, could be also audio-related as this seem to be common for all these 3 PCs tested. I was also planning to test a scenario, when I immediately after channel change pause the live stream with time shifting, how the video playing will continue after that.

Interlacing issues of R9 270X probably related at least partially to driver issues, which are known for AMD Radeon.

[goodton]

This issue does not seem to be audio related, wasapi behaves the same. But it looks like this probably is a problem between DVBLink and Kodi. Just to rule out things I quickly setup ServerWMC side by side the DVBLink on same server and toggled PVR-addons on Kodi-client. ServerWMC does not have this issue but on the other hand it is little bit slower on channel switching and it does not support any kind of subtitles (or should it?)

Also, if channel is immediately paused (timeshifting enabled) after channel change and then played, also DVBLink plays in sync. This paused moment does not need to be long = one second is enough. Not exactly knowing how VideoPlayer handles these situations, is the player immediately in different playing mode (not real time), when the time shifting buffer is in use?

Is it so that all the cache-related advanced-settings for PVR in Kodi are removed in Kodi 17? Just thinking, that could there still some additional buffering possibilities left to try out.

As the DVBLink did not had this same issue in Jarvis, any possibility to track down what has changed in the Krypton-compatible DVBLink-addon.Or is this actually something which DVBLogic should solve?

[FernetMenta]

I am still not sure what exactly you mean with "stuttering" and "not in sync". Could you please make a short video that I can see what you observe.

[goodton]

I am still not sure what exactly you mean with "stuttering" and "not in sync". Could you please make a short video that I can see what you observe.

Ok, I'll try to capture a video.

[goodton]

I am still not sure what exactly you mean with "stuttering" and "not in sync". Could you please make a short video that I can see what you observe.

Ok, I'll try to capture a video.

Finally got something captured, hopefully the problem is easy to spot:

https://youtu.be/5gro-xS7x5U

The video is "synced" after channel change at 00:18 timestamp. As this is a broadcast in Finland, this should be played in 50Hz on screen, so that no other juddering is introduced. At least on my screen the moment, when stuttering stops is very easy to see, especially if TV is using smooth motion algorithms. Also the audio here has those dropouts during this syncing phase, should be easy to hear.

Regarding the audio, when timeshifting in DVBLink-addon is enabled, channels with Dolby Digital surround audio most of time is triggered on AVR. As Krypton does not anymore allow bitstreaming of live-tv -audio, I have to assume that when timeshifting is enabled in DVBLink, Kodi does not see the stream anymore as a real-time stream. The and of the video is just showing the AVR decoding the Dolby Digital-audio, bitstreamed by Kodi PVR.

[FernetMenta]

A real-time stream is defined as such because data comes in in realtime. That means that once playback has started player can't fill its buffers. (in particular the large cache of most audio drivers)

First issue of DVDBLink:
Even if it has timeshift enabled it has to signal to player that the stream is realtime. At least at the beginning and always if the buffer has less data than 10 secs to give.

The old advanced settings for pvr caching are not needed anymore. Player does it automatically now. If level of demux buffer drops below 5%, player reduces playspeed by 5% until level id above 10%. If this happens you may observe some micro judder because refresh rate does not exactly match speed of a/v. This behaviour is fat better then having audio stalled.

You see why passthrough is not allowed for this type of streams. You can't slow down passthrough audio. If it is enabled and playspeed is reduced, we are in an unsupported scenario where audio sync for passthrough fights against slowed down clock speed.

[goodton]

Thanks for the explanation related to real-time streams. So every PVR-addon is responsible of informing Kodi, when a stream is real-time stream, which is the case pretty much always. But not with DVBLink, when timeshifting is enabled, so it is not obeying this rule.

Nevertheless, this "stuttering"-issue is probably not related to usage of timeshifting, as this happens also without timeshifting enabled and DVBLink-stream seem to be correctly identified as real-time. Did you happen to got any additional clues from that video capture? Or is this the micro stutter-effect which might happen if demux buffer is not having enough data, especially when stream is started. PlayerDebugInfo has this forward-value, is that informing the status of demux buffer?

[FernetMenta]

The forward-value on PlayerDebug is not related.

As I explained, if demux queue is about to run dry, below 5%, playspeed is reduced by 5% until buffer level is above 10%. Demux queue has a size of 8 seconds. So with reduced speed by 5% it takes 8 seconds to fill 5% of the queue.

Actually this mechanism shown not engage on channel switch because player calculates the starting point that buffers a slights over 5%. In you first post you write "up tp 10 sec". Something between 8 secs and 10 secs means that buffers slightly dropped below 5 %. Something below 8 seconds should not happen. Maybe the addon buffers internally and drains our queue.

[goodton]

OK. In Jarvis DVBLink worked without issues but it starts to look like the the Krypton-version of DVBLink-addon is not up to task at the moment, especially with this new demux queue -mechanism. I assume, that there are no more tools on Kodi-side to tackle this problem? I have understood, that this PVR-addon development work and especially the responsibilities are somewhat "unclear" to backend-providers at the moment, quite probably I'm going to be thrown back here, when I start to discuss about this in DVBLogic-forum

One question related to FPS-detection in Kodi for PVR-streams? As I described previously, this "detection"-phase can last quite a long time, just measured this to take about 10 seconds actually. And when this happens there might be also a quick "flick" on screen. How this detection works and is it by design, that it can/will take this long for real-time stream as for video files this is instant? Probably nothing to do with this stuttering issue, just interested

[FernetMenta]

OK. In Jarvis DVBLink worked without issues but it starts to look like the the Krypton-version of DVBLink-addon is not up to task at the moment, especially with this new demux queue -mechanism. I assume, that there are no more tools on Kodi-side to tackle this problem? I have understood, that this PVR-addon development work and especially the responsibilities are somewhat "unclear" to backend-providers at the moment, quite probably I'm going to be thrown back here, when I start to discuss about this in DVBLogic-forum

I agree and I suggested again to the team that the github org kodi-pvr, that currently own the master repo, should be discontinued. Ownership pretends that team kodi cares about the addons. Trust me, this is not the case. Nobody in team kodi cares about 95% of the addons. The maintainers are fully in change of their addons. If they don't care, the addons will decay.

One question related to FPS-detection in Kodi for PVR-streams? As I described previously, this "detection"-phase can last quite a long time, just measured this to take about 10 seconds actually. And when this happens there might be also a quick "flick" on screen. How this detection works and is it by design, that it can/will take this long for real-time stream as for video files this is instant? Probably nothing to do with this stuttering issue, just interested

FPS detection looks at the pts vales of the frames. This is mainly used to change refresh rate. If timestamps are clean, it takes about 3 seconds. If it takes 10, timestamps must be rather messy or frames are missing.

The short "flick" is a Windows issue. On Windows deinterlacing is done by renderer so player detects 25fps instead of 50. Could easily be fixed.

[goodton]

Thanks @FernetMenta