[sej7278]

here's an album of top screenshots from 17a1, notice the last one is the smaller "recently added" list which uses about 50% cpu instead of 150%+ of the main movies list (other 3 images)

https://imgur.com/a/hSMlC

edit: my new beta5 build doesn't show the issue, so its not my environment, it is something in the code. skipping a day and rebuilding from d4b994823e now

edit 2: d4b9948 works fine, building a9e0f5e from jan 8th now

edit 3: a9e0f5e works fine, building 68a37d2da1873b6 from jan 9th now

edit 4: 68a37d2 works fine, building 9d9a153feaf459a61 from jan 10th next. getting a bit boring now, but only about 3 days worth of commits left

[fritsch]

I can't help with screenshots ... provide the output requested.

Edit: Ah thanks ... did not see it.

Also provide a Debug Log and make 100% sure you have vsync enabled

[sej7278]

9d9a153feaf459a61 has the slow down problem.

so the bug is somewhere between 68a37d2 and 9d9a153 so actually before rc1 on january 10th

edit: 6a18391 is fine.

edit 2: 252acea has the bug.

so the culprit is https://github.com/xbmc/xbmc/commit/252a...c8599fd203

[sej7278]

so i've found the evil commit is the texturepacker/gif one, now what do we do?

[Ace]

At first sight I have no idea how this should be related. Is the texturepacker and especially the skin rebuild at all in your test?

[sej7278]

what's weird is that i compile with --disable-texturepacker so it should make no difference, i don't know what a skin rebuild is, and my test consists of scrolling down the movie list using a remote control, its not a unit test lol

[wsnipex]

which might exactly be the issue. Texturepacker converts images into an optimized format for use in kodi skins.
Without it, you probably load plain jpeg/pngs.

Please reproduce with texturepacker enabled.

[sej7278]

yeah giving it a go now, as i came to the same conclusion, think i was being lazy about dependencies

[sej7278]

ok with texturepacker enabled in an rc2 build the scrolling is definitely more fluid, although its not updating the backgrounds as you scroll, only when you stop scrolling, and cpu usage is still around 200%

going back to my old beta5 build, when i scroll, the background art changes almost in realtime as you hold the button down.

is there a way to force a re-cache of the fanart or something i need to do?

[Razze]

Just to be clear, your testing this with confluence?

[sej7278]

yes, default confluence skin

[Drag0nFly]

i can't even seem to compile 17a1 due to "VAAPI.h:166:3: error: ‘VABufferInfo’ does not name a type" errors.

i'm on ubuntu 12.04 on a revo 3610 (64-bit, quad core atom, 4gb, nvidia ion1) which has run xbmc/kodi just fine for years since eden/11 at least.

I'm also running into the same compilation issue with recent builds. Appears to have started within the last two months, as I did do a clean git checkout+test of mainline early this year.
Would be interested to know if there is an easy workaround for this?

And before you ask; yes, I am also on an older Ubuntu release (13.04) due to Intel GFX driver bugs on recent distros preventing 23.976Hz modes from working on secondary displays, so upgrading isn't an option at the moment.

[sej7278]

I'm also running into the same compilation issue with recent builds. Appears to have started within the last two months, as I did do a clean git checkout+test of mainline early this year.
Would be interested to know if there is an easy workaround for this?

--enable-vaapi=no

[Drag0nFly]

Thanks @sej7278, I did consider disabling VAAPI but it is somewhat useful to have H264 acceleration. I was hoping that a minor change to the source or header file would fix it for those versed in this.

Then again I could add the libva 1.6.0 packages I built and re-test with those..

[fritsch]

13.04 has no support.

We need in deed libva 1.6.0