In OS X applications, preferences are typically stored in preference list (or simply 'plist') files. Helix Maintenance Manager (aka HMM) follows this convention. HMM's scheduler preferences are stored in the file
~/Library/Preferences/Helix/MaintenanceManager/schedule.plist

In addition, files can also be stored in the Application Support folder...
~/Library/Application Support/Helix/MaintenanceManager/
Helix Maintenance Manager uses this location to store your plans. Each plan is stored in its own file, in Apple's standard plist format. Looking in this folder, you should see one file for each plan you have created.

These files can be examined and edited using any application capable of editing plist files. Apple's Property List Editor, installed when you install the Xcode (or developer) tools, is what we recommend.

When you examine a plist file, you find a list of items, each with a name (the Key), a class (the type of data it contains), and the value for that key. Changing a setting is simply a matter of changing the value for the key you want to adjust. However, it is important to make sure that the value is the correct type and is a reasonable or recognizable value for the program. Setting a key to an improper value can result in the setting being ignored, or the program may crash or behave unexpectedly. If, after editing a plist, you find the program not working as expected, you should delete the plist (you made a backup before making changes, right?) and start again.

Sometimes setting are not available through the normal user interface that can be changed by editing the properly list. Perhaps these settings were added very late in the development cycle and there wasn't time to create a proper user interface for them, or they are rarely needed and would just clutter up the regular interface and potentially add confusion for 99.9% of the product's users.

When Helix Maintenance Manager 1.0 was released, one user encountered a problem where HMM would generate an error because the Helix utilities (Helix Utility and Update Collection) would take a long time to run. This caused HMM to think the program was hung and a timeout error was returned. We could have increased the timeout period, but that would cause cases where there was a genuine timeout error to take longer to detect the problem. The solution was to add a preference for the time HMM should wait before returning a timeout error.

Combining the fact that this setting would rarely need to be adjusted with the need to release this fix quickly, we decided to make it adjustable only by direct editing each plan's plist file.

Additional preference settings control the amount of time to wait before returning a timeout error. There are two settings for Helix Utility, one for Update Collection, and one for the Finder itself.

The value for these keys is an integer, defining the number of seconds to wait for a timeout. The default value for each of these is 2400 seconds*, or 40 minutes, which should be enough to allow most collections to be checked, but not so long as to cause unwarranted concern.

A bug in HMM 1.0.1 & 1.0.2 results in the default for new plans being set to a random number (1,853,189,228 seconds, or just under 59 years, in our tests). This effectively disables the timeouts altogether. HMM 1.0.3 corrects this bug. Plans that were created in HMM 1.0 and later opened with HMM 1.0.1 or 1.0.2 are properly set to 2400.

When a previously created plan is first opened in HMM 1.0.3, the values for these parameters are reset to 2400 seconds.