[arokh]

I'm running XBMC "Frodo" and just noticed this while doing an strace:

Code:

access("/storage/.xbmc/userdata/Database/Addons15.db-journal", F_OK) = -1 ENOENT (No such file or directory)
fstat(13, {st_mode=S_IFREG|0644, st_size=413696, ...}) = 0
lseek(13, 24, SEEK_SET)                 = 24
read(13, "\0\0\17\305\0\0\0e\0\0\0B\0\0\0\2", 16) = 16
fstat(13, {st_mode=S_IFREG|0644, st_size=413696, ...}) = 0
access("/storage/.xbmc/userdata/Database/Addons15.db-wal", F_OK) = -1 ENOENT (No such file or directory)

This is repeating infinitely. Could someone enlighten me whether this is a bug in XBMC or not? Any way to remedy it?

[spiff]

no bug. it's sqlite looking for a journal when we open the database...

[arokh]

514 times in 5 seconds, while XBMC is idling in the top menu. Why is it necessary to check more than once when it's failing? Also, which database is that, why is it accessed when XBMC is doing nothing?

[spiff]

"doing nothing"? it's running its the app loop, fetching, updating and generating all the info you see on the screen. not to mention the 15-20 service threads. xbmc is never idle.

it's likely some skin using some info label that needs to query the addons db for existence.

[jmarshall]

Not sure if it's from the skin - current nightlies have altered to not hit the addons db for disabled status at all anymore.

Would be nice to know what it is, particularly if it really is continuous (one presumes whilst sitting on home or some such, where add-ons are on screen?)

Cheers,
Jonathan

[mkortstiege]

I think spiff is right. The skin is requesting information from an addon. On confluence (and therefore others) the search addon is a candidate that's hit all the time when on home screen. At least i can recall something like this.

[jmarshall]

Yes, but the db query (that checks for disabled status) has been removed in from the infomanager lookups in current master, right?

[mkortstiege]

Yes and no 5c104987deae67c9196a881b4e9723931e8352b7 only prevents us from querying SYSTEM_ADDON_TITLE/SYSTEM_ADDON_ICON all the time.

[Milhouse]

Could this be the same reason why the Raspberry Pi with Confluence is accessing Addons15.db 50 times a second over NFS (although NFS isn't likely the problem, as there would probably be the same access pattern when booting from SMB, USB or SD card).

[ronie]

Could this be the same reason why the Raspberry Pi with Confluence is accessing Addons15.db 50 times a second over NFS (although NFS isn't likely the problem, as there would probably be the same access pattern when booting from SMB, USB or SD card).

it's caused by the System.HasAddon() visible conditions used in Confluence.
removing those will reduce file access from 100 times a second (tested with vblank sync disabled) to 1 time per second.

[Milhouse]

Could this be the same reason why the Raspberry Pi with Confluence is accessing Addons15.db 50 times a second over NFS (although NFS isn't likely the problem, as there would probably be the same access pattern when booting from SMB, USB or SD card).

it's caused by the System.HasAddon() visible conditions used in Confluence.
removing those will reduce file access from 100 times a second (tested with vblank sync disabled) to 1 time per second.

That sounds like a very sensible improvement... can we make this happen? 100 times per second is pretty nuts...

With vblank sync changed from "always enabled" to "disabled", I'm now seeing network utilisation quadruple to about 40KB/s and CPU load go from 30% to 75%, and the GUI is now noticeably more sluggish, so this would be a definite improvement on resource constrained devices (and/or those connecting over WiFi).

[arokh]

I never use Confluence, this is not specific to that skin. Currently I'm using reFocus BIG, sitting at the home menu without any addons visible. There is no System.HasAddon in the source, yet it hits Addons15.db-journal TONS of times every second, difficult to measure how many.

I guess the devs feel this is efficient use of resources. To me it explains why you need a powerhouse of a machine for XBMC to run smooth even if the GUI is simple as hell.

[Milhouse]

The NFS file handle I observed in my network traces was for Addons15.db (not .db-journal or .db-wal, neither of which exist), so I'm not entirely sure if this is the exact same problem you found originally, but something is hammering on Addons15.db* as fast and as often as it can while the user is sat at the main menu, for no visible benefit, which results in just horrific overhead (which might not be an issue on x86 with local storage, but on a Raspberry Pi booted over a network it most definitely is!)

Hopefully someone can look at this and get to the bottom of it - the current implementation of whatever it is doesn't seem at all sane.

[ronie]

The NFS file handle I observed in my network traces was for Addons15.db (not .db-journal or .db-wal, neither of which exist), so I'm not entirely sure if this is the exact same problem you found originally, but something is hammering on Addons15.db* as fast and as often as it can while the user is sat at the main menu, for no visible benefit, which results in just horrific overhead (which might not be an issue on x86 with local storage, but on a Raspberry Pi booted over a network it most definitely is!)

Hopefully someone can look at this and get to the bottom of it - the current implementation of whatever it is doesn't seem at all sane.

i'm not sure whether it's intended behaviour or not, one of the devs will have to make that call.

could you create a ticket on trac and cc me?

[Milhouse]

i'm not sure whether it's intended behaviour or not, one of the devs will have to make that call.

could you create a ticket on trac and cc me?

Done, ticket #14122, and many thanks. I couldn't find a suitable component that applied to Addons so please change to something more appropriate if required.