Kodi.bin 95% CPU usage on one Pi

Help and Support Raspberry Pi
1

Hi there

I’ve noticed the kodi.bin process is using 95-96% CPU when playing a music stream on the SHOUTcast2 plugin:

Playing stream:

10244 osmc 20 0 691636 221452 38852 R **95.3** 61.2 49:34.58 kodi.bin

Idle:

10244 osmc 20 0 634708 207492 40060 R **33.2** 57.3 62:44.44 kodi.bin

This is on a Pi B+, using the Estuary skin and connected to a 5.1 USB sound card (I tried the same without said card connected). Logs: https://paste.osmc.tv/holeqecequ

What’s strange is, on a Pi 1 with the same Kodi version, same plugins installed, same skin and the same stream playing, the CPU usage is much lower:

Playing stream:

17446 osmc 20 0 680528 176068 73928 S **55.9** 48.6 388:09.25 kodi.bin

Idle:

17446 osmc 20 0 616080 172424 73928 R **33.3** 47.6 392:13.14 kodi.bin

On the Pi 2, (same setup again) it’s higher (but then there are more cores)?

Playing stream:

28962 osmc 20 0 713380 162352 46976 R **108.9** 21.6 172:34.16 kodi.bin

Idle:

28962 osmc 20 0 658848 161756 47512 S 26.8 **21.5** 182:16.00 kodi.bin

This Pi is using the Eminence 2 skin however, with the ShaderToy visualisations.

Normally I wouldn’t care, but I have a homebridge service running on the Pi B+ and occasionally the audio stutters (also happens when moving around the GUI). For now, I’ve overclocked at HIGH to solve this - but I don’t like to do that really.

I tried renaming the .kodi directory and starting afresh with only the SHOUTcast2 plugin, with the Estuary skin active and connection to central MySQL library.

Not sure what other variables there are in play here. Possibly the SD card? dd is showing I’m getting ~12MB/s write speed on it in situ.

2

The 95-96% CPU figure seems to be very high for an internet radio streaming add-on, given the generally low bit rate it needs to deal with. TBH, this is probably more of a Kodi issue than being something specific to OSMC, though I notice in your log that the Pi B+ is running out of memory, causing Kodi to be shut down. You really are pushing the B+ to its limits (and beyond) with 2 cameras (and it looks like 4 streams) plus all the homebridge stuff, plus Kodi. The Eminence 2 skin might be more CPU intensive, though I’ve never used it myself. It might be time to consider moving to a Pi with more RAM.

I assume the (other) Pi 1 isn’t being fed by two cameras and running homebridge, so we’re probably not comparing like with like, though please correct me if that’s incorrect. Is it also feeding a 5.1 USB sound card?

As for the Pi 2, that 108.9 % CPU figure is very high but 26.8% at idle also seems rather high for a Pi 2. It might be worth checking what add-ons you have installed and disabling them one by one to see if that makes a difference.

Just a thought. If you run top, are you seeing a high percentage of si (software interrupts)? If so, this might be as a result of a peripheral device, eg the USB sound card.

3

Hi there

kodi.bin uses 95% CPU when playing the stream even when the homebridge service is stopped, so I think we can rule that out as the cause of the high CPU usage for the kodi process?

Agree that the Pi is under stress with homebridge running AND kodi wanting to use 95% CPU (for some reason). When homebridge is fighting for some CPU time every so often both homebridge and kodi will use 45% until homebridge has finished, then kodi will resume at 95%. This is usually when the stuttering of audio and slow UI happens.

The Pi isn’t attached to any cameras or any hardware other than a USB 5.1 soundcard and even with this unplugged, kodi is still using 95% CPU playing music streams.

Not sure where the out of memory you speak of is. Kodi system status shows the system running at about 65% RAM.

The Pi 1 only has a USB Wifi dongle attached, no homebridge service.

The Pi 2 is running the same addons as the others, plus Eminence 2, Library Updater, ShaderToy and Hyperion service.

Edit: The out of memory I think you spotted in the log seems to coincide with when I managed to crash Kodi in the Weather app:

17:42:37.144 T:2423497712 ERROR: CUPnPDirectory::GetResource - unable to find object folder.jpg (kodi.old.log)

Cheers
Jamie

4

Hi, the out-of memory error can be found by seaching for oom-killer in the log file you posted. Since Kodi is by far the biggest memory hog on the system, it usually gets zapped when such a condition occurs.

Your set-up is clearly quite complex and it’s going to be nigh-on impossible for me to debug it at a distance with little or no information to go on. Your best best (other than updating the Pi B+) is to be methodical and disable add-ons and services until it no longer has problems (or disable everything and then re-enable them one by one).

The log shows two Foscam cameras apparently streaming to Homebridge over the network.

5

Hi

Sorry if it wasn’t clear from my previous posts but I did test with a clean .kodi setup with no homebridge running and no soundcard plugged in with just SHOUTcast2 and the CPU usage was still at 95% during streaming.

Thanks for your time.

Cheers
Jamie

6

Then everything points to the SHOUTcast2 add-on being the culprit. Probably best to talk with the developers to see if they can be of assistance. Good luck.

7

Observed that the default OSMC Skin uses quite a bit more CPU than the Esturary skin, too:

  • Removed .kodi folder
  • Stopped and disabled homebridge service
  • Started kodi service

367 osmc 20 0 479532 89508 49616 S **43.6** 24.7 9:09.82 kodi.bin

44% CPU usage having started the service and left it running for 10 minutes without touching it.

  • Stopped and restarted the service
  • Rebooted the Pi
  • Still at 44% CPU usage
  • Switched to Estuary skin:

365 osmc 20 0 531816 93292 49548 S **14.6** 25.8 1:30.15 kodi.bin

Apparent massive reduction in CPU usage having switched from OSMC skin to Estuary

  • Switched back to OSMC skin:

365 osmc 20 0 548688 96388 49124 R **46.5** 26.6 2:39.21 kodi.bin

Back to high CPU usage

  • Switched to Estuary skin:

365 osmc 20 0 523840 94772 49492 S **15.7** 26.2 3:15.94 kodi.bin

Low CPU usage

  • Install SHOUTcast2 addon
  • Open music stream

365 osmc 20 0 630212 125088 51596 R **94.9** 34.6 6:52.81 kodi.bin

Ridiculously high CPU usage. And only on this Pi :smiley:

8

I can also confirm that the OSMC skin causes higher CPU usage for kodi.bin. Estuary bounces around between 5% and 15% on my Vero 4K, averaging around 10%, whereas the OSMC skin varies between 15% and over 30%, with an average around 20%.

But back on topic, SHOUTcast2 is clearly a CPU hog. You can also see that the memory usage of kodi.bin has increased from 26.2% to 34.6%, which is a hefty increase for one add-on.

9

It is indeed. I don’t understand why it doesn’t use the same resources on the Pi 1 though.

17446 osmc 20 0 681260 176992 73944 S **52.3** 48.9 777:36.70 kodi.bin

To check I wasn’t going insane I just rebuilt the Pi B+ from scratch with just the SHOUTcast2 addon and stock configs (no homebridge, no USB soundcard, no O/C) - same high CPU.

The only thing I can therefore think is that the addon just behaves differently depending on the architecture/resources available.

One of life’s little annoyances.

10

AFAIK, the B+ is a Pi 1, it’s similar to a B version but with different GPIO pins and better ports, but with the same SoC and 512MB of memory. I’d therefore expect the add-on to behave pretty much the same way on the Pi 1 (B?) and B+.

Looking back at your first post, the Pi 1’s kodi.bin memory use went from 47.6% idle to 48.6% when playing, and the Pi 2’s memory use went from 21.5% idle to 21.6% when playing, ie they both changed very little.

After rebuilding the B+, what’s the memory usage looking like?

11

kodi.bin is hovering around 30% CPU, 54.8% RAM “idle”. 96% CPU, 60.9% RAM playing a stream with SHOUTcast2.

12

Would be interesting to see top while this is happening on both machines. I suspect as @dillthedog said earlier this usage may not just be in processing but it could be interrupts caused by a peripheral such as your sound card or even io waiting which could be due to a slow SD card being used to cache the stream. It is also possible (because the pi uses the usb bus for ethernet) that because you are receiving the stream and outputting it again through the same USB bus that there are processor cycles waiting for the bus.

13

Swap the Pi 1 cards around and see if the issue follows the card or stays with the machine.

14

This happens without the USB soundcard in the equation

15

Will try swapping them around

16

Gah. More trouble than it’s worth. The original Pi is Wifi and by swapping the card over I have no way of setting it up easily (no CEC on this TV) and ofc the SD cards are different sizes. I’m fedup with it now.

17

Yep, the 1B+ uses the micro SD card and clearly your 1B isn’t using a micro SD with adapter.

Oh well, it would have been a good experiment!

18

I bit the bullet, used an SD card adapter, dusted off a Bluetooth keyboard (replaced the discharged batteries inside it, cleaned it up, replaced the batteries) then fought to enter my Wifi code which failed several times (I’m thinking a locale isn’t correct somewhere and the @ key was in the wrong place, but since you can’t see the input on the display I have no idea) connected to the network, played the stream… 92.7% CPU, 27.8% RAM.

So, possibly the SD card then (a Sandisk Ultra microSD 8GB class 10).

The original Pi has a 4GB Lexar class 4.

19

(Just to be clear, this is the micro SD card moved over from the Pi 1B+ to the 1B, right?)

Those numbers are versus 96% CPU, 60.9%. (and 95.3% CPU, 61.2% memory from your first post) when run on the B+.

If I’ve interpreted the facts correctly, the CPU has fallen slightly but the memory use has dropped significantly when the SanDisk has moved to the 1B. But the original 1B figures with the Lexar card were 55.9% CPU, 48.6% memory. I’ll have to mull this one over, but it looks like it might be down to the characteristics of the cards, with the SanDisk Ultra not necessarily being faulty. Perhaps the SD card’s data buses differ between the B and B+.

But, whatever the ins and outs of the card performances, things still point to the SHOUTcast2 add-on being a CPU hog.

20

Yep.