Login at Kodi Home

gizmotoy · 2013-01-10, 06:34

I recently updated to Frodo RC3 and am noticing some unusual behavior. It appears that the amount of CPU XBMC is using varies significantly, even when sitting idle on a menu screen. I'll be sitting at 5-6%, then it'll spike up to 40%, and then it'll drop back down to 5%. The cycle repeats every 10-15 seconds.

I saw that Next Aired way throwing errors in my log, so I disabled that, but the issue persists.

Any idea what's going on?

Attached are a couple logs as I was fiddling with things. First is with Next Aired enabled, second is with it disabled (but still installed):
http://xbmclogs.com/show.php?id=27253
http://xbmclogs.com/show.php?id=27254

lysin · 2013-01-10, 19:43

Are you using any library auto update plugin?

My frodo RC3 was cycling like a human heart beat (similarities were really freaky) from 2-3% to 30-40% every 10 sec. I figured it was the auto update plugin that was causing this.

I really didn't noticed this before so I don't know if it is just RC3 or its just normal behaviour.

Anyhow, I disabled the plugin and all went back to normal.

gizmotoy · 2013-01-10, 20:59

I am indeed running a library auto update plugin. It's set at the default 4hr update interval. I think I tried disabling it already, but now my memory is foggy. I'll check it out tonight for sure to see if I notice the same thing. Did you actually have to uninstall the plugin, or was simply disabling it enough?

lysin · 2013-01-10, 21:01

Disabling was enough for me, no need to uninstall.

You can do a quick test!

Wink

gizmotoy · 2013-01-10, 21:20

(2013-01-10, 21:01)lysin Wrote: Disabling was enough for me, no need to uninstall.

You can do a quick test!

I'll check it out and report back. Did you report it to robweber (the Auto Update dev)? He's pretty responsive about this stuff.

lysin · (This post was last modified: 2013-01-10, 21:41 by lysin.)

No, I didn't. I was still trying to figure out if it was a problem with my setup or if someone else was having the same issue.

I only found out this yesterday so didn't have that much time to go deeper on the subject.

gizmotoy · 2013-01-11, 17:10

Exact same behavior here. Disabled Library Auto Update and the problem went away. Time to talk to Rob.

robweber · 2013-01-11, 21:57

Hey everyone - I was just made aware of this (thanks gizmotoy!) and have some suggestions.

I was unable to exactly recreate your issue, but using Frodo RC3 and the latest auto update addon I did see a noticeable increase in my CPU usage on Windows 7 with this addon running. Since Frodo RC1 (roughly) the addon has been using the Common Plugin Cache to keep track of the last run variable rather than a .txt file in the addon directory as was previously done. I've already seen on complaint on an ATV2 that this has made the system "less stable".

I've created a branch on github labeled no-storageserver that has reverted these changes. If you are having this problem please uninstall the addon from xbmc, and then download a copy from github of this new branch. If this solves your issues I will merge this branch and push a fix right away. If not we'll have to dig a bit deeper.

https://github.com/robweber/xbmclibrarya...rageserver

gizmotoy · 2013-01-11, 22:08

Thanks for the quick response Rob, as always. I'll check this out soon (hopefully tonight, maybe tomorrow) and let you know!

gizmotoy · 2013-01-12, 02:52

That definitely resolved the issue. It looks like uninstalling and installing the Git branch version didn't even wipe out my settings, so I know even the settings were identical.

Beyond that, with the repo version, my CPU usage in the time between the spikes hovered between 5-8%. With the Git branch version my CPU utilization hovers between 2 and 5%. This is minor on my 2.5GHz i5, but may be much more serious on something like the Apple TVs you mentioned.

I'm not sure what the new method's advantages were, but the your old file method seemingly has a much lower impact on resource utilization.

**Martijn** · 2013-01-12, 03:00

Why don't you just store the last run in settings.xml where the settings are stored?

just use xbmc.setsetting('lastrun', time)
(or something like that)
And retrieve it just like any other setting.
This was the value is stored without the time being visible in the settings dialog

gizmotoy · (This post was last modified: 2013-01-12, 23:31 by gizmotoy.)

Possibly-interesting footnote: The behavior doesn't seem to start until after exiting XBMC and restarting it.

Ex:
Uninstall Repository version, install Git version: CPU spikes
Uninstall Repository version, install Git version, restart XBMC: Works fine
Uninstall Git version, install Repository version: Works fine
Uninstall Git version, install Repository version, restart XBMC: spikes

Whatever is causing the problem doesn't actually take effect until XBMC is restarted for the first time.

lysin · 2013-01-12, 20:14

I can confirm that it is indeed back to normal behaviour.

Thanks for the quick support robweber!

robweber · 2013-01-13, 18:30

(2013-01-12, 03:00)Martijn Wrote: Why don't you just store the last run in settings.xml where the settings are stored?

just use xbmc.setsetting('lastrun', time)
(or something like that)
And retrieve it just like any other setting.
This was the value is stored without the time being visible in the settings dialog

I feel like I tried this a while back when first moving this from an autoexec script to an addon; but can't remember why I had issues getting it working correctly. Since then I haven't thought about storing the value this way. I'll give it a try in testing but this seems like a great solution.

(2013-01-12, 20:14)lysin Wrote: I can confirm that it is indeed back to normal behaviour.

Thanks for the quick support robweber!

Thanks for testing it out. I'll get this pushed to the main branch so everyone can take advantage of it.