Kodi Community Forum

I've been having some GUI issues since v14 or so but as they are intermittent, I've really struggled to report this, I see other people who seem like they may have similar issues also seem to struggle too, so I hope this attempt is successful.

In short with vertical blank sync enabled I see the following issues (intermittently):

Flickering in the main GUI/menus - Looks like it is alternating the drawing of the layers of the GUI - I can set VBS to be enabled only during playback to avoid this so not a major issue

The main issue is that during video playback any 'overlays' will tend to 'stick' and then further actions are ignored whilst these element stick on screen for 10+ seconds or so.

Most commonly this will be that I pause a video, upon resuming (with the Confluence skin) the overlay showing the elapsed time will switch from paused to playing and start counting up but will remain on screen (I normally use Aeon MQ 5/6 in this case it's much worse as you have 'PAUSED' in huge text remain over your resumed video). Whilst these elements remain on screen then other actions that would result in something being displayed seem to be ignored. For example I hit info and would normally get an overlay with additional move info but at this stage it will no nothing, I need to wait it out and hope the previous elements will clear of their own accord, this seems to take about 30 seconds normally. On occasion I've left it for minutes for it to do nothing, sometimes I've tried hitting a load of buttons and it then won't respond at all and I have to power the device off using the hardware button, normally though I can hit stop and resume without issue. With the 'Pause during display rate change' option enabled, the short pause at the beginning will often trigger this issue as soon as I start playback.

To be clear, disabling Vertical Blank Sync consistently makes all of those issues go away. However I'd like to have this VBS enabled if possible as without it, I seem to get issues at the top of the display where it seems like top half inch of the display doesn't quite have the rows of pixels arranged properly so the content 'leans' to one side slightly.

Pastebin with debug
See resume at 20:47:05 and the following 'info' keypresses that are ignored.

Kodibuntu x86_64 on Intel NUC DC3217BY - Core i3 3217U - Intel HD 4000 . Have had this issue for a while, since v14 I think, log shows 15.0 but have just upgraded to 15.2-RC1 and have the same issues.

Hope that covers it all, please let me know if I can provide any more info, would also appreciate it if anyone else could confirm if they see issues like this.

For intel the default is: Let Driver decide - which has a very good reason, one you currently see.

OK thanks. I had that set originally, I changed it based on recommendations here for it to prevent the flickering on the main GUI. I certainly see the flickering issue when it's set to 'let driver decide'. I don't recall for sure if the other issues are present. Is there another fix for the flickering?

enable during video playback

No - don't enable during video playback. Set it to let driver decide, then restart, then enable debugging, then restart kodi and provide a Debug Log.

@fritsch, I have the same issue on my sandy bridge celeron nuc. VBS is set to let driver decide. Issue present in VAAPI EGL OE Jarvis as well, is a debug log helpfull. Or do you need a debug log of an official Isengard build?

(2015-09-23, 21:46)lexi81 Wrote: [ -> ]@fritsch, I have the same issue on my sandy bridge celeron nuc. VBS is set to let driver decide. Issue present in VAAPI EGL OE Jarvis as well, is a debug log helpfull. Or do you need a debug log of an official Isengard build?

Turn on debugging ,yes. Restart kodi and post the log. If you run Unity or something or gnome 3 behind its back ... then yeah not much we can do ...

Interesting, I'm also experiencing this issue. I'm having this issue using nVidia and Radeon cards it doesn't matter if I'm using OpenElec or Kodibuntu.
Disabling vert blank sync indeed resolves the issue, but playback is a bit choppy when watching live TV.

Will try to pull a debug log tonight.

(2015-09-16, 22:43)womatron Wrote: [ -> ]OK thanks. I had that set originally, I changed it based on recommendations here for it to prevent the flickering on the main GUI. I certainly see the flickering issue when it's set to 'let driver decide'. I don't recall for sure if the other issues are present. Is there another fix for the flickering?

I think the flickering was due to some non-standard dirty region settings that had been set in the past and forgotten about, putting that back to defaults seems to have sorted things for now. However I still have a couple of questions:

Is it possible to enable debug logging to the log file without the additional debug info on the screen? If this was an option this would help debugging of intermittent issues so it could be left on without interfering with whatever you are watching. Anecdotally, having debug logging on seemed to make this issue harder to reproduce, I'm guessing that in this case having extra changes on the screen would have impacted the number of dirty regions that needed redrawing and hence made this harder to reproduce - the flickering mostly used to happen on static screens.

In simple terms, what does the 'let driver decide' option really do? I'd assumed it would mean that the driver would just make a one off decision as to enable VBS or not. Hence I assumed the results would be the same as (one of) either manually disabling it or enabling it.
But it feels like it's doing something different, i.e I don't see the minor distortion at the top of the screen as I do with it off, and nor the delays when it's on, so I assume it's more of a dynamic decision than that?

Thanks.

<loglevel hide="false">1</loglevel> in advancedsettings.xml

Same problem here using the latest OE on a Asus Chromebox.

Remote becomes unresponsive (Solved by reboot), seems worse when coming out of the screen saver (Black or Dim)

I just switched over to "Let driver Decide" rebooted and will see how that goes.

It got so bad last night, I came out of the screen saver and pressed a few buttons on the remote and everything got jammed up and had to pull the plug.

If you need a log or anything let me know.


Thanks!

(2015-09-16, 22:36)womatron Wrote: [ -> ]The main issue is that during video playback any 'overlays' will tend to 'stick' and then further actions are ignored whilst these element stick on screen for 10+ seconds or so.

Most commonly this will be that I pause a video, upon resuming (with the Confluence skin) the overlay showing the elapsed time will switch from paused to playing and start counting up but will remain on screen (I normally use Aeon MQ 5/6 in this case it's much worse as you have 'PAUSED' in huge text remain over your resumed video). Whilst these elements remain on screen then other actions that would result in something being displayed seem to be ignored. For example I hit info and would normally get an overlay with additional move info but at this stage it will no nothing, I need to wait it out and hope the previous elements will clear of their own accord, this seems to take about 30 seconds normally. On occasion I've left it for minutes for it to do nothing, sometimes I've tried hitting a load of buttons and it then won't respond at all and I have to power the device off using the hardware button, normally though I can hit stop and resume without issue. With the 'Pause during display rate change' option enabled, the short pause at the beginning will often trigger this issue as soon as I start playback.

I'm actually getting this issue occasionally in the EGL OE build, usually after the system (Chromebox) has been suspended at least once.

Specifically, after a pause the little time counter overlay at the top sometimes comes on, and then won't go away. Or, it takes an abnormally long time. Hitting INFO does nothing - it stays up. Hitting OK brings up the main lower overlay, and that one will go away fine, but the upper one remains. Fast forward / rewind doesn't affect this, but I've noticed two things that will: hitting a skip button (ie shortskipback) will get rid of the overlay. As will the function that toggles the main user interface (ie. file list or Kodi menu overtop of the playing video). I can hit that once to bring up the menu, again to get rid of it, and the upper overlay will finally be gone.

After this, the INFO button will work as it should, at least until I pause again.

Note that I am not experiencing any flickering or video quality issues, nor issues with the system locking up in the manner described. Just the sticky upper overlay. And I haven't touched the VBS setting.

I completely solved by problem by changing VBS to let driver decide, reboot and then start with a fresh guisettings.xml.

I had a hard time getting a fresh guisettings.xml until I stopped the kodi service with SSH.

I had the exactly same problem as Sunflux and Womatron. I've tested for 24 hours now with Aeon Nox 5 and Confluence and it's working perfect.

I have not tested the coming in and out of suspend yet.

I'm running latest OE on a Asus Chromebox.

What totally mucked me up was the Chrome Wiki that said change that setting to "enable during video playback"

(2015-09-16, 22:40)fritsch Wrote: [ -> ]For intel the default is: Let Driver decide - which has a very good reason, one you currently see.

Hmm. Okay, so it turns out that "VBS Enabled during playback" was actually set on this system. I don't remember ever changing that, so maybe "let driver decide" wasn't always the default?

We'll see if it makes any difference. Working fine after a reboot, at any rate, but the system practically locked up when I changed the setting. Became unresponsive for a long while and then the GUI stopped updating, although I managed to blindly navigate the shutdown menu to reboot.

I'm having a similar issues running Kodi 16.1 on Windows 10 with Intel HD graphics.
WITHOUT VBS enabled, I have tearing.
WITH VBS enabled, I have issues with the OSD as explained above.
I don't see any "Let Driver decide" option. was this removed in 16.1?

In any case, is there a solution to this?

Thanks for any feedback!