Android high cpu load in Film directory
#1
Hi, i have a very high CPU load in some directories. I start a specific addon and select Films, when it shows me the List of films the CPU load is so hight that it takes 2seconds to jump from one entry to the next after i pressing the down button on the remote control.
I am using Android Box - Xiaomi Mi Box with Kodi 19.3 and the latest Mimic-LR skin. (on an identical Box with Kodi 17.6 and original Mimic skin by Braz installed the directories are fast, there is no high CPU load)
Reply
#2
Try using the default Estuary skin first, to rule out any Mimic skin-related issues. Restart Kodi after switching skins, and then reproduce the problem(s).
Also providing a debug log (wiki) could be helpful to find out who/what the troublemaker is.
Reply
#3
with Estuary Skin everything is fast in the  film directories too, no high CPU load. I try to figure out how to create a log.
Reply
#4
1.  Which add-on are you referring to?
2.  What view are you using with it?  (or does it provide its own custom view?)
Reply
#5
Note. I have noticed higher cpu loads on views that use either scrolling (text auto-scrolling when there is too much to display in the provided box), or possibly various other animations.  But I've not (thus far) been able to really narrow it down on what objects are causing it.   (I've got an issue on github about it).  I'm not sure where to really begin on figuring out what is actually using CPU in kodi. (other than random trail and error of randomly removing things from the screen in the hopes of seeing a difference)

I did notice when playing with colors that some of the animation effects seem to really slow down the "snappiness" of the display (delay timing values before moving cursors and the like), and ended up setting some of those times to 0 in the "List" view because it is doing some color changes that were happening much much much faster than the cursor moving, which was really disconcerting (you can pull the latest beta from the beta repo if you want to test that), and am in the process of looking into the idea of removing a lot of those animation effects, (or reducing the delays) elsewhere.
Reply
#6
I've done a lot more playing around, and I did narrow down to a problem with what I think is a background switcher in the VideoNav.xml

Code:
 <control type="fadelabel" id="4410">
             <scrollspeed>20</scrollspeed>
             <scrollout>false</scrollout>
             <top>-10000</top>
             <pauseatend>7000</pauseatend>
             <width>1000</width>
             <height>100</height>
             <font>font14</font>
             <textcolor>black</textcolor>
             <label>$INFO[ListItem.Art(extrafanart1)]</label>
             <label>$INFO[ListItem.Art(extrafanart2)]</label>
             <label>$INFO[ListItem.Art(extrafanart3)]</label>
             <label>$INFO[ListItem.Art(extrafanart4)]</label>
         </control>

Not 100% sure what that object is actually trying to do (it shoves itself way off screen), but after commenting that out, the CPU went way down on the video navigation. For the life of me, I've never seen the fanart actually changing to any extrafanarts anywhere while navigating. (only ever seen the main fanart of whatever you've focused on). Unless I hear otherwise, I'll just remove that rotating extra-fanart "feature".

The other thing that eats cpu is whenever it wants to autoscroll a textbox. There's a skin option (under Settings->Skin->General->Enable auto scrolling for plot & review) that can be turned off. There were a lot of places that have autoscrolling that were not checking that setting.

I've pushed -b17 into my beta repo which should help with those.

Note if you want to keep auto scrolling turned on (because with it turned off you can't see everything when it doesn't fit in the box), you can try making sure the "Video plot preference" is set to "views: Plot outline | Info dialog: Full plot", because the outline is generally shorter, so you will be less likely for it to need to scroll on most browsing.

I expect I'll try to make "manual scrollbars" show up in more places to enable an alternative to autoscrolling. Or perhaps make such objects expand or pop a dialog to show "full text" on click. Or something of that nature.
Reply
#7
The latest betas should be much better on CPU usage.

I'm made a lot of updates, replacing various animations that were being used as the focus-hilight mechanism, instead just making the "itemlayout" and "focusedlayout" blocks different, and removing a lot of animations which seemed to just be there just to slow down the UI, and a few animations which did not seem to have any visual effect that I could see.  (removing those animations also has the effect of making the UI a lot more "snappy" since it's removed a lot of the visual delays)

The other CPU hog is the text auto-scroll.  I've done things like only letting the focused item auto-scroll, and trying to ensure that even those obey the "disable auto-scroll" skin setting.  That leaves you unable to see all the text in a lot of situations though.  In the future, I'll probably look into adding manual scrolling to a lot of places that show large blocks of text.

I'll probably push out a merge into the official kodi repo this weekend.
Reply

Logout Mark Read Team Forum Stats Members Help
high cpu load in Film directory0