B12 went through the grueling early Sat. morning schedule (moved to this morning as usual) for the first time here and survived. It's still working fine, and doesn't give me spinning rainbow wheels. Found some peculiar entries in the Log Window, however.

1. Five consecutive "could not communicate with helper" entries at address 8:46am, right about when I touched my computer for the first time in the morning. There were 6 of them yesterday morning (I forgot to add Tuesday morning to the group of "Sat. morning actions", so I didn't report back yesterday morning), also at about the time I touched my computer for the first time.

Note that the system sleep timer is set to "never", while HDs and the displays are allowed to sleep.

2. There are 2 errors associated with the actions that took place overnight. The first at 4:49:55am, "Helper did not start" after a successful "merge" action. Then "helped did not start" again at 5:34:55am, which stopped a "verify" action. Both errors gave the same description (with different timestamps, of course):

Distributed objects message send timed out (timeout: 462228595.910597 at time: 462228595.922145) 1

A diag report has been sent.

Ming-Li Wang wrote:B12 went through the grueling early Sat. morning schedule (moved to this morning as usual) for the first time here and survived. It's still working fine, and doesn't give me spinning rainbow wheels.

Finally, some progress!

From the diagnostic report you sent, I can confirm that all of the actions ran successfully.

Found some peculiar entries in the Log Window, however.

1. Five consecutive "could not communicate with helper" entries at address 8:46am, right about when I touched my computer for the first time in the morning. There were 6 of them yesterday morning (I forgot to add Tuesday morning to the group of "Sat. morning actions", so I didn't report back yesterday morning), also at about the time I touched my computer for the first time.

I was able to determine the cause of these messages, and it goes a long way to unraveling a slew of odd issues other have encountered.

Recent versions of OS X have gotten extremely aggressive about suspending apps that it doesn't think are relevant. In the past, the QRecall Monitor process could reasonably expect to get distributed notifications and timer messages when the system was idle, but apparently that's no longer true. Based on the log entries, it appears that OS X is electing to completely suspend the QRecall Monitor application when your display is asleep. Here's the sequence of events that I found:

At 3:20 AM a capture action ran.
20 seconds later, the capture action finished and terminated.
At 8:46 AM the monitor app receives a notification from the capture action that it would like be monitored.
The monitor app tries to connect with the capture action (the one that terminated 5 hours ago) and fails (no surprise).

This explains the spat of "Could not communicate with helper" errors that you're seeing when you wake up your display. Even though the capture action sent a notification to the monitor app at 3:20, OS X hung on to that message and didn't deliver it until 8:46.

2. There are 2 errors associated with the actions that took place overnight. The first at 4:49:55am, "Helper did not start" after a successful "merge" action. Then "helped did not start" again at 5:34:55am, which stopped a "verify" action. Both errors gave the same description (with different timestamps, of course):

These message are both erroneous and have the same root cause as the "Could not communicate..." errors.

Both the merge and verify actions also tried to establish a connection with the monitor app (this time using a direct Mach port connection, rather than using distributed notifications?for complicated reasons having to do with bootstrap namespaces). Again, instead of delivering those messages, OS X left the QRecall Monitor app suspended so it never processed or responded to those messages. The messages eventually timed out, and threw an exception which cause the "Helper did not start" error to be logged.

The "Helper did not start" error is actually a mistake in this context. It's supposed to report that helper's main run loop never got started, but it can also get logged if the run loop starts but then throws an uncaught exception, which is what happened here. I've fixed that bug. Now the "Helper did not start" error only gets logged if the helper encountered a fatal error before its main run loop is started, and not afterwards.

I've addressed the two communications problems—the monitor waking up with a request to monitor an action that's already finished and terminated, and the situation of an action trying to send status messages to a monitor app that's suspended and unresponsive.

All of these remedies will appear in (lucky) 2.0.0b13, which should get released before the end of the week.

Thanks again for all of the great feedback and diagnostic reports. I probably would have never found this on my own!

Thanks! Can't wait to test the lucky 13.