1. I noticed my computer was abnormally warm.

2. My battery was draining faster than normal.

3. A mysterious process called ReportCrash was opening, eating 60-90% of my CPU, and closing. It did this about every 3-5 seconds.

4. Likewise, another process kept opening and closing at the same interval: mdworker (owned by me, not by root)

5. I looked into the system logs (using Console) and saw that a log file was being generated for each crash report (from mdworker, apparently).

6. After some google research, mdworker is one of the apps in charge of indexing the hdd (with spotlight)

7. Looking into the crash logs:

It appears that “mdworker” hits a divide by zero error “EXC_I386_DIV (divide by zero)” running “MPEGAudioFile::ParseAudioFile()” from “/System/Library/Spotlight/Audio.mdimporter/Contents/MacOS/Audio”

8. I found an error in the logs reporting that an audio codec (/Library/Audio/Plug-Ins/HAL/DVCPROHDAudio.plugin) couldn’t be loaded because it was the wrong architecture. I removed the plugin and rebooted. No effect.

9. Just a few days ago, I hit a snag trying to open a movie compressed with the DVCPRO HD codec. Comparing the date of the plugin file (in #8) and version (2004 and 1.1) with the same file on a computer that has Final Cut Pro, I regain hope! The file on the Final Cut Pro computer is dated 2007 and is version 1.3. Replacing the old file w/ the new one, I rebooted. …. No plugin crashes reported in the logs! But no effect on mdworker and Audio.mdimporter is still dividing by zero. If only I could get what file it’s crashing on!

10. Well, after searching more forums, I learned that you can omit certain folders from Spotlight’s grasp through its preference pane. I have a work project that contains over 5,000 audio files. This problem started the same day I updated the project and downloaded all 5k files. Making that folder Private (from Spotlight) seemed to fix it immediately!

I still don’t know what the problem was, but I think it was some bad mp3 file in the project tree. A divide by zero error can be avoided in code with a simple check! Now if only I could convince Apple to fix the bug….

Total time spent: 3 hours.

UPDATE 2009 10 07 After filing a bug with Apple, I got the response that the problem is fixed in OSX 10.6. That’s about it. Upgrade to Snow Leopard if you want the proper fix.

UPDATE 2009 11 2 I figured out that you can manually call the mdimporter application, which will crash on the bad file. Run it with the following:

mdimport -d 2 /path/to/suspect/directory

Don’t just run it from root, it will take FOREVER. Also, when it does crash, note the last file it outputs to the terminal window. That isn’t the file at fault. If you navigate to the directory in Finder and list the files in a single column, it’ll be the following file.

One way to verify if a file is at fault, is to set Finder to Column view, and single click on the suspected file. If, in the details in the next column, you don’t see the mp3’s length, bitrate, etc, then that is a bad file. To fix it, try re-exporting it with moderate setting for the bitrate. My files at fault were about 0.5 seconds long, and had a bitrate of about 57 Mb/sec! Capping them at 1200 kb/s fixed the problem.

UPDATE 2009 11 19 Ok, the results are in! All of my problems were caused by bad mp3 headers. If you reconstruct / replace the headers then that will most likely fix the problem. You don’t have to actually re-encode or re-export the mp3 files.