beagled-helper process uses 100% CPU
One fairly common complaint about Beagle is that it seems to use a lot of CPU while running. Indeed, crawling and parsing all of your data is a resource-taxing job, and heavier utilization of the CPU while it's done is to be expected. Beagle tries to schedule crawling and indexing tasks such that impact on overall user performance is minimized, and runs at a high nice level so that indexing in the background doesn't interfere with more performance-critical tasks like watching videos, playing music, or burning CDs and DVDs.
However, there are sometimes bugs which cause Beagle to spin at 100% CPU, possibly without end. We'll go a little in depth on causes here.
Beagle version 0.2.13 and older are buggy
The first thing is to ensure that you're running at least Beagle 0.2.14 or newer. You can get this info usually by looking at the version of the package you have installed on your Linux system, or by running beagle-ping. Bugs in older versions existed that could cause directories to be continuously reindexed. If that directory was created on-demand with a number of files in it (such as untarring a tarball), this can cause 100% CPU utilization.
Beagle is aggressively indexing while the screensaver is on
This is intended behavior, assuming you are not using a laptop on battery power. The idea is that if you're not actively using your computer, Beagle can use those resources to aggressively index your data and finish more quickly.
Issue with download directories for p2p clients
Beagle actively monitors changes to files on the filesystem and indexes them in real time when they are modified. A side effect of this behaviour is that if beagle is indexing the download directory of any torrent client, then beagle will index the file continuously as it is being downloaded. There are ways that the torrent clients can avoid this, but most downloaders (including ktorrent, azureus, amule) behave badly when it comes to writing data to files. It is advisable to add the download directories to the list of excluded directories (via beagle-settings or beagle-config).
Large files might take longer to parse
Most files are filtered (parsed) in a very short amount of time, and don't require full utilization of the CPU. Some larger files might take a few seconds to parse, which would appear on CPU monitors as short spikes of 100% CPU utilization. Some very large files might take several seconds to filter. Generally speaking, however, if the beagled-helper process is using 100% CPU for a few minutes uninterrupted (and with the screensaver off), this is a bug.
beagled-helper chokes on corrupt/partially downloaded media files
If there are corrupt mp3, mpeg or other kind of media files in your home directory, beagle's audio and video filter might take a long time to handle these files. This is due to bugs in 2 of the 3 external video filtering tools we use - totem and taglib-sharp. You should install mplayer which will fix most of the problems. If it still persists, you have to move the files out of beagle's crawling directories.
Filters (file parsers) might have bugs, causing loops
We have seen problems -- usually with proprietary file formats that have to be reverse-engineered, like Microsoft Office -- where certain files can cause infinite loops in filters, which cause Beagle to use all the CPU.
If you suspect this is the case, a debugging system added in Beagle 0.2.14 might help. First, find the process of your runaway beagled-helper process.
$ ps ax | grep beagled-helper 21848 pts/2 Sl+ 0:09 beagled-helper ./IndexHelper.exe
Then, send it the SIGUSR2 signal:
$ kill -USR2 21848
This will cause the helper process to write out the current state of its indexing to its log file. Then, take a look at the ~/.beagle/Log/current-IndexHelper log file, and search for "Filtering status". You'll see something like this:
20070104 13:47:44.7441 21848 IndexH WARN: Filtering status (26s ago): determining filter for file:///home/joe/kernel-source-2.6.11.4-717.inotify.3.i586.rpm
If the time is long (the "26s" above indicates that it's been working on the file for 26 seconds), then you've likely identified the problematic file. You should then try confirming that, by running the beagle-extract-content program on it.
$ beagle-extract-content /home/joe/kernel-source-2.6.11.4-717.inotify.3.i586.rpm
If the program hangs, congratulations! You've found a bug. Please file it in Bugzilla and attach the broken file.
