Several users have reported an issue where actions won't start following an upgrade to 1.0.0(53). The problem seems to be that Leopard doesn't like the upgrade process replacing the scheduler on-the-fly.

It appears that the problem can be fixed by uninstalling and reinstalling the scheduler. Open the QRecall > Preferences... and switch to the Authorization panel. Uncheck the "Start and run actions while logged out" option. Count to 10. Check it again.

This should uninstall, then reinstall, the scheduler. If that doesn't immediately solve the problem, try restarting. Please report any problems you encounter after following this procedure.

Please be aware that there are still problems with QRecall and Leopard. The issue centers around the Leopard security model; it prevent the scheduler from communicating with the actions that have been started. This results in "Action could not be started/cannot establish a connection with helper" errors in the log and essentially prevents QRecall from running any actions.

The problem is oddly inconsistent. Some users are running Leopard without incident, for others the problem appears after a restart, while others can't get QRecall to work at all.

I've made a lot of progress towards solving this problem and have a conference call with the Apple engineers today to resolve the remaining issues.

An update should be available by the end of the week.

I was just about to report this very problem. It's happening with our new Intel Xserve, running 10.5.1. (We're still setting up the server, so no data is at risk yet.)

At first, actions worked, and then later they didn't. I was able to fix it once by deleting all vestiges of QRecall off the hard drive (including prefs, application support files, etc.) but that didn't work the next time. I did notice that each attempt to run an action resulted in another instance of QRecallHelper being launched. At one point, Activity Monitor showed about a dozen instances running. I used Activity Monitor to quit the extra ones.

I'll send you my log file via e-mail, in case there's anything in there that'll help.

By the way, you'll notice in the log file a bunch of instances of QRecall failing to finish a backup because of disk corruption. This was NOT QRecall's fault! We have a bad external drive enclosure, and the errors were also happening with Time Machine, and even Finder copies.

What was particularly interesting about that was that QRecall would identify the problem DURING the backup, stop, and report the problem immediately. This is exactly what it should do, in my opinion. On the other hand, Time Machine never said a thing. With Time Machine, it was only after I dismounted the drive, and remounted it later, that the Leopard OS would tell me the drive was hosed. It would then send me to Disk Utility, but DU was unable to repair it.

If I had been depending on Time Machine, I might have gone for days without realizing the drive was bad and the Time Machine backups were worthless.

-- Bruce

QRecall version 1.0.0(54) should address these issues, and a number of other ones.

Choose QRecall > Check for Updates... to upgrade to the latest version.

James Bucanek wrote:QRecall version 1.0.0(54) should address these issues, and a number of other ones.

I confirm that the new version fixed the problem for me, both on my Xserve and my iMac at home.

-- Bruce