CPU usage constantly at 100%
Submitted by an unknown user
Link to original bug (#716761)
Description
---- Reported by shotwell-maint@gnome.bugs 2010-10-09 22:48:00 -0700 ----
Original Redmine bug id: 2657
Original URL: http://redmine.yorba.org/issues/2657
Searchable id: yorba-bug-2657
Original author: Sat Garcia
Original description:
I recently bought a new camera that produces RAW files (Olympus PEN E-PL1). After my first big shoot with the camera (approximately 200 shots), I tried importing the photos. My computer died halfway through import but I restarted and finished the import. However, now whenever open shotwell, my CPU usage spikes to 100% and stays there until I exit.
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:46:00 -0700 ----
History
Comment 1
Updated by Sat Garcia about 3 years ago
I did a little more investigating and found that the problem happens as soon as I import a RAW file (.%(=caps)ORF% format) into shotwell. I backed up my database and started fresh with shotwell. I imported some jpeg images and everything was fine. As soon as I imported one of the RAW files, the CPU spiking to 100% came back.
Comment 2
Updated by Sat Garcia about 3 years ago
FYI, I am using version 0.7.2.
Comment 3
Updated by Donald Esinoza about 3 years ago
I want to confirm this behavior.
AMD Phenomâ„¢ II X4 940 Processor processors (4 cpu cores)
Linux 2.6.32-25-generic-pae #44 (closed)-Ubuntu SMP Fri Sep 17 21:57:48 UTC 2010 i686 GNU/Linux
Shotwell 0.7.2
I have thousands of Canon RAW files (.CR2), and it displays them properly, but the CPU usage remains maxed out.
Comment 4
Updated by Jim Nelson about 3 years ago
I suspect that this is due to generating what we call mimics. Because processing RAW files for display and interactive editing is so expensive, Shotwell generates in the background JPEG images to use for these operations. This can spike the CPU, but it shouldn't seriously affect the operation of Shotwell while it's occurring.
If you allow Shotwell to run for a while, it should eventually finish and the CPU will subside. If it doesn't, then there is a bug.
Comment 5
Updated by Donald Esinoza about 3 years ago
I cd'd into ~/.shotwell/mimics and I do see that the file count is growing. Thanks. :)
Comment 6
Updated by Jim Nelson about 3 years ago
elsaturnino, could you verify as well? If so, I can mark this as won't fix.
Comment 7
Updated by Sat Garcia about 3 years ago
I'll check this out when I get home tonight and report back. Hopefully it doesn't take too long on my ancient AMD Athlon 2200+ ;)
Comment 8
Updated by Sat Garcia about 3 years ago
Oddly enough, when I loaded up Shotwell when I got home, the CPU usage was back to normal.
Unfortunately, the mimic thing is really ruining my Shotwell experience. I just did an import of 50-100 photos and the important was going on for nearly 10 minutes before shotwell just crashed. Surely there must be a better way to handle importing RAW files :-/
Comment 9
Updated by Jim Nelson about 3 years ago
- Status changed from Open to 5
- Resolution set to wontfix
- % Done set to 0
If the CPU usage is back to normal, that tells me Shotwell completed generating the mimics. It only needs to generate them once. Because of this, I'm marking this ticket won't fix (per design).
The import crash is probably related to this ticket: #2566 (closed). I'm currently testing a patch for this problem and hope to have it in trunk later today. It should be fixed for 0.8.0. If you can consistently reproduce this problem, it would be helpful if you could do the following:
$ SHOTWELL_LOG=1 gdb shotwell 2>&1 tee shotwell.gdb
At the gdb prompt type “runâ€:
(gdb) run
Then reproduce the problem. After Shotwell crashes type this at the gdb prompt:
(gdb) backtrace full
Then exit gdb and attach to ticket #2566 (closed) the files shotwell.gdb and ~/.cache/shotwell/shotwell.log
This will give me a lot of information to figure out why it's happening.
Surely there must be a better way to handle importing RAW files :-/
RAW files are tricky -- beyond the fact that each manufacturer has devised their own proprietary format, they're large files and take a lot of CPU and time to decode. Interactive viewing and editing is not trivial with RAW files. Trust me, we're doing a lot under the covers to make managing RAW files as seamless and zippy as JPEGs. We can always to more, but we're trying!
Comment 10
Updated by Simon Spannagel about 3 years ago
It might be an option to look for jpegs with the same name as the RAW file since many cameras allow you to shoot both, jpeg and raw at once. So one could use this jpeg instead of creating a new one.
Comment 11
Updated by Adam Dingle about 3 years ago
@smn: Right. That idea is#1772, more or less.
Comment 12
Updated by Charles Lindsay 7 months ago
- Status changed from 5 to Invalid
--- Bug imported by chaz@yorba.org 2013-11-25 21:47 UTC ---
This bug was previously known as bug 2657 at http://redmine.yorba.org/show_bug.cgi?id=2657
Unknown Component Using default product and component set in Parameters Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
Resolution: RESOLVED INVALID