Posts: 106
Joined: Jun 2012
Reputation:
0
2016-01-22, 22:34
(This post was last modified: 2016-01-22, 22:36 by sej7278.)
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.
Posts: 106
Joined: Jun 2012
Reputation:
0
wow 65 views and not a single reply? where do we report bugs - i'd prefer github but it says to do it here.
Posts: 17,859
Joined: Jul 2011
Reputation:
371
That usually means no one knows or no one experiences the same. I haven't noticed any difference
Posts: 106
Joined: Jun 2012
Reputation:
0
2016-01-23, 18:04
(This post was last modified: 2016-01-23, 18:08 by sej7278.)
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.
Posts: 106
Joined: Jun 2012
Reputation:
0
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.
Posts: 4,498
Joined: Jan 2011
Reputation:
150
DaVu
Team-Kodi Member
Posts: 4,498
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.
Posts: 106
Joined: Jun 2012
Reputation:
0
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.
Posts: 2,127
Joined: Jan 2015
Reputation:
60
Razze
Team-Kodi Member
Posts: 2,127
I think the best way to find this is a setting up a test case and bisecting it
Posts: 23,302
Joined: Aug 2011
Reputation:
1,077
fritsch
Team-Kodi Developer
Posts: 23,302
2016-01-30, 10:49
(This post was last modified: 2016-01-30, 10:50 by fritsch.)
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
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Posts: 106
Joined: Jun 2012
Reputation:
0
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.