OK, I understand. I’m talking of temperatures because I never had the thermometer sign more than a minute or two, now is constantly wich means that the cpu is working hard. I uploaded a screenshot a few hours ago, I don’t know if that is useful for you, please tell me what you need and I will try. Sorry again for my English… 
Just adding myself to the ones who see high cpu utilization. 40% - 100% depending on skin. I have tested a lot of skins and all exept Estuary will produce a high cpu util. while sitting idle in home screen. Some worse than others with ridiculous per core utilization reported in htop. My standard skin is Phenomenal and it average 40-50% idle now.
Cheers
Tim
As you asked: I am using a MySQL installation. But nothing going on there on the SQL side, which is on NAS.
As said it is just Kodi rendering IMHO and stuff just got worse with recent updates. When waiting to flip the buffers it does not really sleep but really actively waits (yes there is a difference), hence consuming a lot of CPU for nothing. At least this is my take on it. And such stuff has always been there in one way or another. Just gotten worse. I never saw anything else than high CPU usage in menus (more CPU/GPU usage than playing movies).
If you enable an RSS Ticker on the Main Menu you will see it using 100% CPU all the time (at least I do on a Vero 4K) The skin does not really matter in the end, and no addons involved. Log shows nothing, as stuff from the rendering loop is not logged.
What would be interesting if there is progress in 18 here on the code side.
Thanks for confirming that. The reason why I was looking in the direction of SQL was that during the August update the sqlite was upgraded and the OSMC Widgets would issue some SQL queries.
But based on your comment this seems not to be the culprit.
Yeah, was a good idea. Widgets seem not to be involved here. Really seems a Kodi issue. At least from the list of patches on GitHub I do not see anything out of the ordinary that would cause high CPU usage when “idle” in a menu from the OSMC side as the rendering loop is not touched at all as far as I can tell from the names of the patches.
Also setting the dirty regions in advancedconfig make no difference at all with any of the skins I tried. That’s a bit odd though.
But sure, usage varies depending on skin and what is on screen. Basically the longer Kodi needs to actually render a frame, the less CPU it seems to use waiting to flip a back buffer - and in my case hogs one core waiting. At least that is my current assumption for the symptoms I am seeing.
As said Kodi’s rendering loop runs like a game loop and not like an application that waits for an event to wake up.
I am still trying to figure out how to detect if the HDMI port on my Vero 4K is actively used or not or how to get an event from a keypress of the RF remove, so I can exit Kodi after X minutes and let the box really idle and restart Kodi when switched back to the HDMI port or a key on the remote is pressed. You know like a fake sleep mode.
While I checked with strace and couldn’t find a difference between main menu and submenu. I will check my Kodi 18 install to check if it is different.
I always use top in a console window from my pc.
After some seconds of idle, there is a very big difference from main menu to sub-menu.
As I’ve told some hours ago, I’ve made a fresh install in a new card and it replicates exactly the same behaviour
(I do not recomend to have logging enabled in kodi as it does increase cpu usage in about 10-15%)
If you use <loglevel>1</loglevel> (means no GUI display) it should be not increasing the CPU usage. But I think the debug logging will not tell us the secret of this issue.
Yeah, that is odd. Maybe some specific code path for the main menu handling? I can confirm that basically any sub menu will work (e.g. going into my list of movies) will reduce the load significantly (goes down to 5% but jumps after a few seconds up to 20% and drops slowly down again). The spikes are also visible on the main menu, but there it is only like 5% difference - but that could be because one core is already fully used all the time.
Hence my working assumption that more work there - because of more text - in handed to the GPU and Kodi is less actively waiting for something.
What also could be:in those sub menus the dirty region stuff can kick in properly as there are more small parts that make up the whole screen, where as it doesn’t work for the Main Menu as it should (would be strange though). But I am just guessing here.
Given that Kodi is able in my case to use way less CPU when idle it should be defect that is fixable on the Kodi side if we are able to identify what’s going on there.
Logs didn’t tell me if something actively is going on in the Main Menu that is not going on somewhere else. And in my case it is nothing (hence again back to the idea of the rendering loop doing something actively it shouldn’t).
Hi, anyone tried to disable ethernet connection? (or the one you’re using). Doing this my cpu goes from 40% with one core at 100% to barely a 5-10%. I Kwon this is vague but you can give it a try
1 Like
I’ve tried that one without any difference in cpu usage.
(of course that when we do any change, we must wait some seconds for the system to became idle again)
Yes, I let almost 30 min without ethernet and instantly the cpu usage drops to 5-10% and the temperatures drops to 63° and still until I reactivate the ethernet and 2 or 3 minutes after the cpu usage raise again alongside the temps. Maybe something in the Lan? I mean, shared content or something like that? I doubt it because turning of my pc doesn’t makes a difference in the behavior of osmc in my rp3.
By the way, a question, it’s normal that the osmc log make a 10mb file in a few seconds?
No, what is in there?
A lot… I don’t know but it’s huge, like 2000 lines in 20 seconds I let it running
But what are they saying? Copy some in here
02:21:07.351 T:1959014400 NOTICE: special://profile/ is mapped to: special://masterprofile/
02:21:07.351 T:1959014400 NOTICE: -----------------------------------------------------------------------
02:21:07.351 T:1959014400 NOTICE: Starting Kodi (17.4). Platform: Linux ARM (Thumb) 32-bit
02:21:07.351 T:1959014400 NOTICE: Using Release Kodi x32 build (version for Raspberry Pi)
02:21:07.351 T:1959014400 NOTICE: Kodi compiled Aug 27 2017 by GCC 4.9.2 for Linux ARM (Thumb) 32-bit version 3.16.39 (200743)
02:21:07.352 T:1959014400 NOTICE: Running on Open Source Media Center 2017.08-1, kernel: Linux ARM 32-bit version 4.9.29-9-osmc
02:21:07.358 T:1959014400 NOTICE: FFmpeg version/source: ffmpeg-3.1-kodi
02:21:07.358 T:1959014400 NOTICE: Host CPU: ARMv7 Processor rev 4 (v7l), 4 cores available
02:21:07.358 T:1959014400 NOTICE: ARM Features: Neon disabled
02:21:07.358 T:1959014400 NOTICE: special://xbmc/ is mapped to: /usr/share/kodi
02:21:07.358 T:1959014400 NOTICE: special://xbmcbin/ is mapped to: /usr/lib/kodi
02:21:07.358 T:1959014400 NOTICE: special://xbmcbinaddons/ is mapped to: /usr/lib/kodi/addons
02:21:07.358 T:1959014400 NOTICE: special://masterprofile/ is mapped to: /home/osmc/.kodi/userdata
02:21:07.358 T:1959014400 NOTICE: special://envhome/ is mapped to: /home/osmc
02:21:07.358 T:1959014400 NOTICE: special://home/ is mapped to: /home/osmc/.kodi
02:21:07.358 T:1959014400 NOTICE: special://temp/ is mapped to: /home/osmc/.kodi/temp
02:21:07.358 T:1959014400 NOTICE: special://logpath/ is mapped to: /home/osmc/.kodi/temp
02:21:07.358 T:1959014400 NOTICE: The executable running is: /usr/lib/kodi/kodi.bin
02:21:07.358 T:1959014400 NOTICE: Local hostname: osmc
02:21:07.358 T:1959014400 NOTICE: Log File is located: /home/osmc/.kodi/temp//kodi.log
02:21:07.358 T:1959014400 NOTICE: -----------------------------------------------------------------------
02:21:07.447 T:1959014400 ERROR: DBus: Error org.freedesktop.DBus.Error.ServiceUnknown - The name org.freedesktop.UPower was not provided by any .service files
02:21:07.477 T:1959014400 NOTICE: load settings…
02:21:07.682 T:1959014400 NOTICE: Found 2 Lists of Devices
02:21:07.682 T:1959014400 NOTICE: Enumerated PI devices:
02:21:07.682 T:1959014400 NOTICE: Device 1
02:21:07.682 T:1959014400 NOTICE: m_deviceName : HDMI
02:21:07.682 T:1959014400 NOTICE: m_displayName : HDMI
02:21:07.682 T:1959014400 NOTICE: m_displayNameExtra:
02:21:07.682 T:1959014400 NOTICE: m_deviceType : AE_DEVTYPE_HDMI
02:21:07.682 T:1959014400 NOTICE: m_channels : FL,FR
02:21:07.682 T:1959014400 NOTICE: m_sampleRates : 8000,11025,16000,22050,24000,32000,44100,48000,88200,96000,176400,192000
02:21:07.682 T:1959014400 NOTICE: m_dataFormats : AE_FMT_FLOAT,AE_FMT_S32NE,AE_FMT_S16NE,AE_FMT_S32LE,AE_FMT_S16LE,AE_FMT_FLOATP,AE_FMT_S32NEP,AE_FMT_S16NEP,AE_FMT_RAW
02:21:07.682 T:1959014400 NOTICE: m_streamTypes : STREAM_TYPE_AC3,STREAM_TYPE_EAC3,STREAM_TYPE_DTSHD_CORE,STREAM_TYPE_DTS_2048,STREAM_TYPE_DTS_1024,STREAM_TYPE_DTS_512
02:21:07.682 T:1959014400 NOTICE: Device 2
02:21:07.682 T:1959014400 NOTICE: m_deviceName : Analogue
02:21:07.682 T:1959014400 NOTICE: m_displayName : Analogue
02:21:07.682 T:1959014400 NOTICE: m_displayNameExtra:
02:21:07.682 T:1959014400 NOTICE: m_deviceType : AE_DEVTYPE_PCM
02:21:07.683 T:1959014400 NOTICE: m_channels : FL,FR
02:21:07.683 T:1959014400 NOTICE: m_sampleRates : 48000
02:21:07.683 T:1959014400 NOTICE: m_dataFormats : AE_FMT_FLOAT,AE_FMT_S32LE,AE_FMT_S16LE,AE_FMT_FLOATP,AE_FMT_S32NEP,AE_FMT_S16NEP
02:21:07.683 T:1959014400 NOTICE: m_streamTypes : No passthrough capabilities
02:21:07.683 T:1959014400 NOTICE: Device 3
02:21:07.683 T:1959014400 NOTICE: m_deviceName : Both
02:21:07.683 T:1959014400 NOTICE: m_displayName : HDMI and Analogue
02:21:07.683 T:1959014400 NOTICE: m_displayNameExtra:
02:21:07.683 T:1959014400 NOTICE: m_deviceType : AE_DEVTYPE_PCM
02:21:07.683 T:1959014400 NOTICE: m_channels : FL,FR
02:21:07.683 T:1959014400 NOTICE: m_sampleRates : 48000
This is the 50 first lines, if you need more tell me how to or where to upload the file
Try grab-logs -X but it might be too big.
If that doesn’t work than share the last 50 lines as the first 50 lines are quite typical.
Your command doesn’t seems to work well, maybe because is big. I did a paste in that web and seems it not accept more than 500 lines (the command line tell me https://paste.osmc.tv/ < html > ) , so I’m going to do two things, one I’m going to put the link to the first 500 lines https://paste.osmc.tv/oharadubiv.vhdl, and two, I saved the log into a file if you need de last lines tell me and I paste it in the same web.
From that part of the log it is one of your addon (the kind of we don’t support) that is spamming your logs that might also be a one of the high temp you see