[DragonFly]

I am a long time XBMC user and I'm aware of the high CPU quirks XBMC has been having over the years.

I've always used a relatively simple dedicated HTPC hooked on a CRT (Celeron 1300/Geforce 5200) running 9.11 and a 4:3 skin and really NOT using fanart but just the file mode for viewing content.

Recently I've bought a LG 55LX9500 and hooked up my Scaleo-E (P4 3ghz, Geforce 210, Dharma beta 4, vanilla gui settings) finally to really enjoy my extensive Media content from a 4tb network server on the large screen.

It scared the hell out of me........

While browsing through my video library my fans are going ape ****!!! It's like a plane taking off.
When bringing up the debug overlay, it shows CPU's usages up to a staggering 155% (CPU-XBMC), 100% core 1, 55% core 2 .

What can possibly justify a CPU usage that kind? Of all the programs I've ever used over the years, I've never had ANY program reaching those numbers, apart from programs hanging the system.

So what's causing this?

• the relatively old nvidia driver shipped with dharma
  
• network activity (reading fanart from a share)
  
• inconsistencies in the underlying OS
  
• or.........God forbid, some bad code
  

Furthermore, what can be done until this is resolved?

• update the nvidia driver
  
• use dds fanart
  
• wait for the final dharma
  
• some other solution
  

Normally I would send a debug, but I'd really like some pointers where to look in the debug file first.

[spiff]

this is definitely an issue with your system. xbmc runs just fine on single core atoms...

it's hard to say up front what you should look for in a debug log - just pastebin the lot.

[DragonFly]

It seems the high CPU spikes ONLY occur when XBMC is caching fanart/posters from content for the first time. After reading a folder -in filemode- once (thumbnails created), everything appears normal.

I have my content on a server and have pre-created metadata en fanart/posters (medium size) using programs like Ember Media Manager.

I've not yet tested what happens if XBMC is adding content to the library from a folder which has no metadata/fanart by using one of it's scrapers. This seems the way most average users still do.

So now I've narrowed down when high CPU occers, I still don't understand WHY this process is eating so much CPU cycles

Here's the log: http://pastebin.com/dF69g7zZ

[jmarshall]

Creating DXT1 files is a massive CPU intensive task. It's essentially searching a 3D colorspace for optimal colours. Read any paper on generating DXT1 images for more details.

It only has to do it once though. So flick through your movies one by one (ensuring the fanart image shows for each one before moving on) then go grab a beer and chill out for half an hour or so while it does it's thing.

Later on we'll likely be moving to DXT5YCoCg which can be compressed much faster as we don't need as high a quality as it takes up twice as much space on disk (and RAM).

Now: Why was this posted in development?

Cheers,
Jonathan

[DragonFly]

Because from a development point of view the code for caching thumbnails could be optimized. From reading various topics I gathered as much that the process is CPU intensive. But if it's reaching CPU values no other program has reached before, something might be off. That's why

[darkscout]

Is there anyway to kick this off automatically? I have a TON of movies/tv shows. going through them one by one seems tedious at best.

[jmarshall]

It's done on demand. Simply run through your movies - you can do this quite quickly (eg pausing 1 second per film is more than enough) and it'll have them all queued up.

I'm sure folk could write a script/plugin that could do it outside of XBMC as well - no need for XBMC to have such a thing in it's core.

Moving out of development.