This is a just a technical note about the photo processing program Aperture, version 3.2.4, which at the time of this posting is the latest update.
I have been importing two large collections of photos into Aperture over the past few days. The first one took a while, but eventually, everything was imported and all the background processing took place.
Then the update to version 3.2.4 happened, and my nature is to always keep software up to date, so I installed it. Then I imported the second library. The imports happened smoothly and all 102,000 masters imported. Then the background tasks began, which were making preview files. I had the faces recognition turned off.
After a few thousand images were processed, my Mac filled up. The swap files were growing out of control and consuming all available space (over 60GB). I had to reboot the computer. It happened several times before I tracked the problem down to Aperture and its background processing. Doing my research, I saw that the same thing had happened before back when Aperture 3.0 came out. A later update fixed the problem, but now it’s back. Using advice from 2010, I turned on the “Open in 32-bit mode” option and ran it that way. Now, all the background processing is happening smoothly, with hardly any swap space used. It runs a little slower, but it runs.
Surely there will be another update which will fix the problem, but for now, there’s this work-around.
UPDATE 20,000 photos later.
A different type of error occurred after processing about 20,000 photos in 32-bit mode. This time Aperture crashed, with a crashlog that indicated various malloc errors. Starting it up again caused another crash, the instant it started processing again. The fix? Switch back to 64-bit mode. Now it’s working fine, chugging away through the process queue.
I suspect there are two bugs, triggered by two different kinds of source files. I’ll just switch back and forth until the all the preview files are generated.
UPDATE 2: 10,000 photos later, a photoshop file crashed Aperture in 32-bit mode AND caused the swap-space inflation in 64-bit mode. Restarting in 64-bit mode after a forced quit, I was able to watch the progress and learn the name of the file when the swap-space started growing rapidly. Quitting Aperture and investigation with finder, I found that this particular file (200+ MB) didn’t have a thumbnail and quicklook wouldn’t show its content either. Since the RAW file, another version of the photoshop file and a couple of JPG’s were all there and appeared perfect, I moved the bad file and restarted Aperture. Everything is working fine now. I trashed the Aperture version. It’s pretty obvious some damaged or just odd image files can crash Aperture.
Though not to the extreme of gnawing 6GB, I had Aperture eating up resources (CPU, RAM, Swap) on a regular basis. What fixed most of it for me was starting Aperture in first aid mode and repair permissions by keeping [alt] + [cmd] pressed when starting the application. Maybe that fixes your problems, too?
Not for me, anti. I've repaired database too many times to count — mainly for the feel-good idea that I'm doing something positive. No, I think it's rogue picture files that are just so far out of Apple's test cases that it blows the software's mind, so to speak. My picture collections are hardly a professional's working set. I've got gifs, and pdfs and a few mvis and who knows what in there. Some are known bad files. I just wish I could isolate which files were the bad guys and deal with them.