Somewhere after git 20160105.efbb55d 16beta5 scrolling through the movies list has gotten quite a bit slower.
i've compiled a few rc1 builds: 20160113.fe2fa28, 20160117.9d50c19, 20160117.41d5fee etc. and the only way to get back to decent scrolling speed is to go to beta5.
is this perhaps something to do with vaapi - does it break vdpau?
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.
wow 65 views and not a single reply? where do we report bugs - i'd prefer github but it says to do it here.
That usually means no one knows or no one experiences the same. I haven't noticed any difference
what setup do you have martijn?
its made my revo3610 feel like a raspberry pi the scrolling is so slow!
previously i could hold the down button and it would zoom through the list several per second, now its like it takes a second per movie to load the art, like pressing the button repeatedly rather than holding it down.
are there any rc1 test builds for ubuntu precise, maybe its my compiler options.
Perhaps I could tell you if you would upload your
Debug Log.
Btw. Ubuntu 12.04 is not supported anymore.
(2016-01-23, 18:22)fritsch Wrote: [ -> ]Perhaps I could tell you if you would upload your Debug Log.
Btw. Ubuntu 12.04 is not supported anymore.
i've actually got debugging disabled, but i'll make a new build.
and yes, i'll be moving to ubuntu 16.04 when its out, seems pointless jumping to 14.04 now when 12.04 works for the moment (as long as you install gcc 4.9)
tried a new build with debugging on and found that kodi was using 200% cpu (2/4 cores) just displaying a single movie info, not even scrolling! oddly enough going back to the homescreen the cpu usage went back down to about 13%, and back up to 175% when back in the movies list.
i then turned debugging back off so i could save the file, and restarted kodi and it seems to be fine now. was it regenerating all of the thumbnails or something weird i wonder?
i'll post the logs in the morning but nothing obvious in there anyway.
You don't need to compile a new build for that...
Just go to system settings->system->logging->enable debug logging.
Then reboot (or restart kodi at least)
reproduce your issue
grab the log from: ~/.kodi/temp/kodi.log
and paste it on a paste service like pastebin.com
Always paste full logs and not the part _you_ think which might be important.
here's some logs:
RC1 -
https://gist.github.com/sej7278/f144eecc328646226eac
RC2 -
https://gist.github.com/sej7278/ee2e609d9c4316b83a74
beta5 -
https://gist.github.com/sej7278/b6ce14df5b4e29b6183d
beta5 is still much faster than either of the others, displays the background and cover art more fluidly too, and the smp seems better - beta5 spreads the load over 4 cores at about 50% each whereas the rc's seem to peg 2 at 100% and 2 at 10%
i can't get RC1 to go faster now either, i'm sure it did for a moment before.
i can't see much in the logs - loading thumbnails seems to take about the same on each version, only possibility i can see is beta5 is ignoring repeated keypresses:
11:41:11 T:139801480943552 DEBUG: OnKey: 167 (0xa7) pressed, action is Down
11:41:11 T:139800354998016 DEBUG: Previous line repeats
7 times.
but the rc's are trying to handle holding of the button as a bunch of single clicks:
11:30:57 T:140493748176832 DEBUG: OnKey: 167 (0xa7) pressed, action is Down
11:30:57 T:140493409195776 DEBUG: Previous line repeats
1 times.
(2016-01-23, 18:22)fritsch Wrote: [ -> ]Perhaps I could tell you if you would upload your Debug Log.
logs are posted to github, any ideas?
Quote:11:41:11 T:139801480943552 DEBUG: OnKey: 167 (0xa7) pressed, action is Down
11:41:11 T:139800354998016 DEBUG: Previous line repeats 7 times.
but the rc's are trying to handle holding of the button as a bunch of single clicks:
11:30:57 T:140493748176832 DEBUG: OnKey: 167 (0xa7) pressed, action is Down
11:30:57 T:140493409195776 DEBUG: Previous line repeats 1 times.
That's only the logger ... if you press it 7 times very fast you also won't see it in the newer log.
No idea to the other problem, VSYNC disabled perhaps?
i've reproduced the problem in 17a1 also.
it seems to only happen in large lists, e.g. 1000+ movies, as the "recently added", or "sets" lists which are much smaller e.g. 20-200 have no problem at all.
the main movies list with ~1500 items uses almost 200% cpu even when its not scrolling.
so i guess its there's a routine that loops through the movie array and its performance drops off drastically at over 1000 items, but was not in beta5.
I think the best way to find this is a setting up a test case and bisecting it
Retry with nightly first.
Then run top while kodi is running and press "H" then make a screenshot, that way we see which thread needs high load
i had assumed your CI setup already would have a 1000+ movie test case?
i'm currently making another beta5 build to ensure that it is in the code and not some update on my build machine or kodi box, then i guess its a case of keeping making builds one commit at a time, although at ~45mins each for a clean build its going to be slow as its a week's worth of commits.