[arokh]

About 4000 attempts at Addons15.db-journal and Addons15.db-wal in 5 seconds. reFocus BIG sitting idle @ top menu, videos highlighted. No active widgets or plugins on screen.

[lulaz]

I have exactly same problem. Using fresh installed Frodo + Aeon MQ 4 on Zotac ION 330 (Ubuntu 12.04 LTS).
I have 70-80% CPU usage from xbmc.bin on XBMC Main Menu. No RSS, no clock, no weather, no watched/unwatched stats. Only Background + menu containing only "Movies" and "TV-Shows" items.
Strace is showing a HUGE amount of entries with:

Code:

- access("/home/gib/.xbmc/userdata/Database/Addons15.db-wal", F_OK) = -1 ENOENT (No such file or directory)
- access("/home/gib/.xbmc/userdata/Database/Addons15.db-journal", F_OK) = -1 ENOENT (No such file or directory)
- clock_gettime(CLOCK_MONOTONIC, {173195, 755320820}) = 0

If any other info is needed please just ask.
Im begging for a fix

[arokh]

Sounds a bit high but the Xtreamer Ultra 2 has like 40-50% CPU usage idle as well with detailed skins like MQ. It's a 2.13GHz atom while yours is 1.6GHz? Guess something is fundamentally wrong with the way XBMC works. The GUI badly needs a rewrite you shouldn't need an i5 to display a simple GUI...

[lulaz]

Sounds a bit high but the Xtreamer Ultra 2 has like 40-50% CPU usage idle as well with detailed skins like MQ. It's a 2.13GHz atom while yours is 1.6GHz? Guess something is fundamentally wrong with the way XBMC works. The GUI badly needs a rewrite you shouldn't need an i5 to display a simple GUI...

I dont think its a "fundamental" bug. Dirty regions pretty much solved this "fundamental" weakness, I think.

@arokh could you check your "strace"? Maybe your CPU is at 40-50% usage while idle becouse of the same problem?
Just do "strace -p PID" where PID is a PID of xbmc process. (CTRL+C to terminate)

[arokh]

Something tells me you didn't read the OP. Anyways, dirty regions 1 does take CPU down to about 15% but it's been buggy with some skins. The GUI is still far from being 100% smooth on a Xtreamer Ultra 2 with heavy skin. I guess that can be attributed to the rather weak GT520M though. As far as I understand, dirty regions is a hack to not render all of the screen at once, right?

[jmarshall]

<sarcasm> Yeah, it's a hack. It has the name dirty after all. </sarcasm>

Dirty regions is not a hack, and is integral to ensuring that we don't spend too much time rendering bits we don't have to. Whether it makes a difference on a particular system depends on the hardware of that system. On a GT520M unless the skin has massive overdraw it really shouldn't make any different at all. What will make a difference is not rendering the screen at all in the case we don't need to, which probably is only enabled if DR is on as well.

The issue with addons database access is something that needs to be addressed, but we have to store the status of addons _somewhere_. The inefficiency comes from two sources:

1. The information lookups are done every frame (i.e. it's a pull system, not a push system).

2. Sqlite doesn't have the database in memory, so is hitting the disk (we don't actually open+close the db every time - the same database instance is used throughout).

Once the first is fixed (it's on my list, but I have little time lately) the second won't be an issue.

Cheers,
Jonathan

[Milhouse]

With an 8 April build of OpenELEC on R-Pi I'm seeing a huge reduction (virtually to zero) of GETATTR requests over NFS (which is how I've mounted .xbmc/userdata), these GETATTR requests being caused by the hammering on Addons15.db*, so can anyone else confirm if I'm just imagining this (or point to where the PR for the fix is)?

[sPOiDar]

With an 8 April build of OpenELEC on R-Pi I'm seeing a huge reduction (virtually to zero) of GETATTR requests over NFS (which is how I've mounted .xbmc/userdata), these GETATTR requests being caused by the hammering on Addons15.db*, so can anyone else confirm if I'm just imagining this (or point to where the PR for the fix is)?

Probably this is caused by a change in the skin - the XBMC code doesn't appear changed.

The issue with addons database access is something that needs to be addressed, but we have to store the status of addons _somewhere_. The inefficiency comes from two sources:

1. The information lookups are done every frame (i.e. it's a pull system, not a push system).

This simple way to handle this would seem to be just to create an in-memory cache of the lookups when they're requested. Individual cache items could be invalidated when that addon is updated. Or, perhaps even easier - simply caching the results in memory, and expiring them after some time (even a few seconds would do the job).

I'm seeing ~80% usage of a core on an IVB i5 with some skins due to this.

[S7eele]

The issue with addons database access is something that needs to be addressed, but we have to store the status of addons _somewhere_. The inefficiency comes from two sources:

1. The information lookups are done every frame (i.e. it's a pull system, not a push system).

This simple way to handle this would seem to be just to create an in-memory cache of the lookups when they're requested. Individual cache items could be invalidated when that addon is updated. Or, perhaps even easier - simply caching the results in memory, and expiring them after some time (even a few seconds would do the job).

I'm seeing ~80% usage of a core on an IVB i5 with some skins due to this.

No activity on this in a while but I'll hope someone runs across this. I just noticed the behavior discussed in the above message(s) was happening on my machine for both 'db-journal' and 'db-wal' and am wondering if it should still be happening and why it is happening SO often. I will be doing more research on this and other sites as it is happening WAY too often. Just FYI I am running current versions of everything, unless you maybe count OS and hardware and it is working fairly well despite the behavior. I am running Vista x64 on an old 9950BE AMD quad core. Perhaps a new thread if nobody responds here. Apologies in advance if I missed the answer somewhere else on the forum but everything seemed to steer this threads direction.

Peace!

[arokh]

I'm guessing you're using Frodo, because it's fixed in Gotham.

[S7eele]

I'm guessing you're using Frodo, because it's fixed in Gotham.

Thanks!

Good, I made it back in time to edit this, maybe I can keep from looking like a complete idiot. I was concerned about your reply at first glance but I think I was misinterpreting it. I just read through the Gotham string and based on my current understanding of the situation I would worry about loading the beta software and messing something else up. I have become too dependent on XBMC to tinker with it for hours at a time . If I misunderstand your reply and you are suggesting that I should already be running Gotham please let me know. If I can get some motivation going I may try Gotham just to see if it makes a performance difference as my current config is slow and sporadic when I am in XBMC. Most of the time I access the add-ons without actually executing the XBMC client.

Peace!

[arokh]

Personally I think it works a lot better than Frodo, even when it was in alpha. If that's true for you I have no idea. Just backup your .xbmc and give it a shot?

[S7eele]

Personally I think it works a lot better than Frodo, even when it was in alpha. If that's true for you I have no idea. Just backup your .xbmc and give it a shot?

Appreciate the assistance and the information.

Peace!

[S7eele]

Personally I think it works a lot better than Frodo, even when it was in alpha. If that's true for you I have no idea. Just backup your .xbmc and give it a shot?

Just FYI, i did as suggested and started running the nightlies immediately after your post above. Very smooth and I did indeed benefit from the improvements already implemented in the Gotham Betas. Thank you for steering me in that direction. Of course since RC1 was released that is what I have been using.

Thanks again for all your work developing and supporting!