High cpu usage after August 2017 update

Most likely but as the patch Sam had in mind didn’t solved the problem we are still on the hunt

1 Like

Well, I can confirm that my problem was solved. I’ve got around a 5-10% cpu usage in idle and 60-65°.

Can anyone please tell me if I still need a reinstall or you consider that my system is now safe?

BTW thanks to nvidias,
Fzinken, dillthedog and all of you that help me to diagnose my problem

I would still do so for two reasons:

  1. You never know if one of the brute force attacks was successful
  2. At least one of the repositories (which we will not discuss here) you use was recently being taken over by unknown forces

OK thanks again I will do it as soon as I can because the cpu and Temps are back again. I really don’t understand what is going on.

Then whoever hacked your system did a good job. /s

The only way we’re likely to find the culprit is by bissecting the changes between 17.3 and 17.4.

It would be good if someone could build Kodi v17.3 on their device and confirm that only changing this binary introduces problems.

git clone https://github.com/osmc/osmc
cd osmc
git checkout d3a60196d1f01cae2968a7434528d00c746aecfe
cd package/mediacenter-osmc

Manually pick this to resolve dependencies: [package] [mediacenter-osmc] No longer depend on diskmount-osmc · osmc/osmc@c6f23aa · GitHub. It cannot be cherry-picked due to the version number change.

Now:

sudo make rbp1/rbp2/vero/vero2/vero3

After a wait, you’ll have a mediacenter-osmc.deb which you can install with:

sudo dpkg -i vero3-mediacenter-osmc.deb
sudo systemctl restart mediacenter

Sam

1 Like

Ok, get a coffee when you start the compile, on the Pi2 it took 8 hours.

Result of 17.3 is as expected Home Screen CPU is half of that of 17.4 and even the submenu CPU has dropped compared to 17.4 submenu (all on OSMC skin)

3

1 Like

You have cached build now, so future builds will be quicker.

Now, I’d pick halfway between: Comparing 17.3-Krypton...17.4-Krypton · xbmc/xbmc · GitHub and adjust the commit SHA1 in build.sh and test again.

Ok, have choosen 1 July a261e06, will report back

Up to (and including) 22 July 4e939cb, this is the CPU usage on a Pi 3:

top - 17:51:36 up 1 day, 48 min,  2 users,  load average: 0.33, 0.29, 0.51
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  0.3 us,  0.0 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  : 21.3 us,  1.0 sy,  0.0 ni, 77.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:    765824 total,   738364 used,    27460 free,    52060 buffers
KiB Swap:   393212 total,    14152 used,   379060 free.   555084 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
22713 osmc      20   0  486204  81880  42984 S  23.0 10.7   0:46.13 kodi.bin

I’m away so can’t test any of the TV menus, but it looks like the high CPU was introduced later.

There was one small glitch during the update but I doubt if it would have affected the result:

osmc@osmc:~/osmc/package/mediacenter-osmc$ sudo dpkg -i rbp2-mediacenter-osmc-to22Jul.deb 
dpkg: warning: downgrading rbp2-mediacenter-osmc from 17.4.0-9 to 17.3.0-1
(Reading database ... 61773 files and directories currently installed.)
Preparing to unpack rbp2-mediacenter-osmc-to22Jul.deb ...
Unpacking rbp2-mediacenter-osmc (17.3.0-1) over (17.4.0-9) ...
dpkg: dependency problems prevent configuration of rbp2-mediacenter-osmc:
 rbp2-mediacenter-osmc depends on diskmount-osmc (>= 1.2.9); however:
  Package diskmount-osmc is not installed.

dpkg: error processing package rbp2-mediacenter-osmc (--install):
 dependency problems - leaving unconfigured
Processing triggers for mime-support (3.58) ...
Errors were encountered while processing:
 rbp2-mediacenter-osmc

The fix for that is here:

Copy the COMMON_DEPENDS line exactly from that build.sh, as we changed the diskmount packages to become architecture specific so we can keep them in Stretch

Ok COMMON_DEPENDS changed.

Trying 02 August e0175e9 next.

Let me know how that goes. I just tested 25th July 0b4cdc9 which also still is low.
Will now go to 30th July 900ad00

Unfortunately, I’m accessing my home network remotely and have lost contact for the past 12 hours. It’s probably either a comms failure or a prolonged power outage. I ran the 02 Aug job with nohup so it might have gone to end if it’s just a commis issue, but if it’s a power outage it’ll probably be toast.

No worries, I am going forward to 30th July in the meantime.

1 Like

Contact re-established. It was a 13-hour power outage, so the job never finished. And my freezer contents will probably be trashed. :frowning: The joys of working away from home.

If you’re running 30 Jul, I’ll go for the half-way point between then and the end commit. I make that 18 Aug db5842b.

Ok have done July 30th 900ad00, which looks clean. If you go for 18th Aug let me go fro your original plan of 3rd Aug e0175e9

1 Like

3rd Aug e0175e9 was OK.
Going for 14th Aug 02af98c

14th Aug 02af98c is clean
Trying 19th Aug 0286139

1 Like

Not much left then…

Merge pull request #12688 from xhaggi/krypton-save-skin-settings-on-window-quit

Looks like a viable candidate, if the timer is constantly restarted. Just guessing from taking a look at the rest of the commits. Sadly, have no time to test. But appreciate what you guys are doing by going through the commits.