Kodi Community Forum

Full Version: High CPU load with radio
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi,

I am using TVH 4.2 with LE 8.1.1 and Kodi 17.4 on RPi-3.

Works well, picking up TV and radio stations.

I have noticed that with radio, but not TV, the processor overheats and the 'thermometer' appears on the screen. When I look at system information, I see that one of the cores is always close to 100%, giving an average CPU load of 25%. For TV, CPU load is very low.

This does not happen for any other audio streams.

It is not specific to LE 8.1.1 and Kodi 17.4, but also occurred with previous versions.

Is it possible that the audio stream is being software decoded, instead of hardware?

Is the problem in the stream that the TVH backend is sending, or its processing in Kodi?

Maybe there is a setting that could lower the CPU load for radio. Any suggestions?

Any help appreciated.

Jon
Hi Jon, hi Kodians,

same effect - 100% load on one CPU out of the four, constantly changing every 10s or so - on a RPi3 installation using
- Current Arch Linux
- Kodi 17.6 (kodi-rbp 17.6-6)
- TVH (kodi-addon-pvr-hts 3.4.28-1)
- German cable signal from Sundtek (sundtek 180627.222039-1)
- MP2 license key available and enabled (radio stream is MP2)

Things, which I tested up to now:
- Recording of radio signal with TVH and replaying shows the same effect.
- MP2 streams within locally stored films decode fine: very low CPU
- Disabling IPv6 does not change anything

htop shows that the load is due to /usr/lib/kodi/kodi.bin. The task has quite some process threads, but the load comes from the main task kodi.bin.

I know that this is not very much for bug hunting, but at the moment I am lacking of good ideas. So, good ideas welcome, and I will assist with logs and so on, however, for the moment I am a bit at a loss.

RoKoInfo
Hi,

Further investigating this effect, I found a strange workaround: I installed and activated a visualization, in my case kodi-rbp-addon-visualization-spectrum. This reduces the "100% on one of four CPU" load of kodi.bin (in total typ. 120%) to an average of 50-60%, equally shared on the four CPUs of the RPi3. Some times, there is some stuttering, when the radio transmission is started, but it runs smoothly over longer times, although the load is still higher than expected (see below). If I stop the visualization during radio playing, the sound stops. The idea of the workaround was based on the observation that the 100% effect disappeared, when I switched the debugging on, having an on screen display. The load average (given by htop) using the visualization is around 0.9, so quite ok. Unfortunately, I am not an expert on GPU stuff, so I am not able to analyze this.

I have the option here to run Kodi on the armv7h (RPi3) and on a desktop x64_64 (also Arch Linux) with TVH in both cases on the RPi3, giving a few numbers for "kodi.bin load" (using htop) for a radio station (mp2, 16bits, 48k) and a TV station having comparable mp2 audio. TV = 30% (RPi3) and 8% (desktop), radio = 120% (RPi3, w/o visualization) and 4% (desktop). So, the load with visualization is still too high (3x?), but there is quite some headroom for stable operation now.

Do not ask me for a why, but Jon, please confirm. As mentioned, I can assist with logs, if someone is interested.

RoKoInfo