I'm running a copy of QRecall on my wife's MacBook Pro.
I logged in to my account on the MacBook and, using the Capture Assistant, set up actions to capture the Startup Volume to an archive on an external drive attached to a Mini.
The initial backup was successful, but there have been no subsequent captures or merges.
The QRecall Activity window on the Macbook has four actions that are waiting.
The Actions window has red "!" in front of each action with the note, "Waiting for action to finish."

I'm not sure, because I don't spend much time on that computer, but I think my account on the MacBook was logged out at some point. So I assume the actions could not proceed.

Is there a way to kick QRecall past this waiting state?

Should I set it up again through my wife's account, which is always logged in, and, if so, will I have to start over with the first capture or can QRecall recognize the first one on the Mini?

If the MacBook is not connected to the Mini through the network, will it automatically do this or should I make sure of that before retiring for the night?

Thanks.
Mark

Mark Gerber wrote:I'm running a copy of QRecall on my wife's MacBook Pro.
I logged in to my account on the MacBook and, using the Capture Assistant, set up actions to capture the Startup Volume to an archive on an external drive attached to a Mini.
The initial backup was successful, but there have been no subsequent captures or merges.
The QRecall Activity window on the Macbook has four actions that are waiting.

First, send a diagnostic report from the account showing the waiting actions. I'm curious to know what the reason is.

The Actions window has red "!" in front of each action with the note, "Waiting for action to finish."

Hover the cursor over the (!) to find out why QRecall doesn't think that action can be run. If the reason is "Archive not available" then the network volume isn't mounted, or QRecall can't identify the volume as the one containing the archive.

I'm not sure, because I don't spend much time on that computer, but I think my account on the MacBook was logged out at some point. So I assume the actions could not proceed.

That depends on whether you enabled the "Start and run action while logged out" option in the Authorization tab of the QRecall Preferences. If you did not, then logging out will stop any running actions.

Is there a way to kick QRecall past this waiting state?

It depends on why it's waiting. If the archive is open in another system/account then the archive really is busy and the actions can't proceed until it is closed. If the MacBook or the file sharing on the Mini have gotten out of sync, then restarting the MacBook or turning the Mini's file sharing off and back on again may also solve the problem.

Should I set it up again through my wife's account, which is always logged in, and, if so, will I have to start over with the first capture or can QRecall recognize the first one on the Mini?

If you used the same identity key for both installations it doesn't matter which account captures the item on the MacBook's hard drive. However, the ownership of the archive follows the same rules as any standard OS X document. If your account owns the archive, select the archive and choose Get Info from the finder. You'll need to either change the owner to your wife's account or change the group or everyone access so that both accounts can read and write the archive.

If the MacBook is not connected to the Mini through the network, will it automatically do this or should I make sure of that before retiring for the night?

QRecall will attempt to mount the volume containing the archive. For network volumes, this requires that the account be logged in (OS X will not mount network volumes for logged out users) and the user name and password need to have been saved on the keychain and the keychain must be open.

Thanks.
Mark

It sounds like what I need to do is set things up so the actions are being run from my wife?s account (using one ID key). So a few days ago, I did this:

- Changed the permissions on the archive so anyone can read and write to the file (which is on an external drive attached to a Mini).

- Launched QRecall from Steph?s account on the Macbook and used the Capture Assistant to set up a basic series of actions to write to the already established ?macbookpro-all users-full.quanta? file.

I think QRecall did a relatively successful capture two days ago (there are some minor files we seem to be having problems with). I left the drive mounted, hoping things would settle down to a routine. Upon checking yesterday's log (which I'll be sending to you), I see there are several entries that read, for instance, "Stopped processing folder Images". Something about not being able to read the envelop content length.

- This evening, from my account on the MacBook, I deleted all the actions in QRecall.

However, the QRecall Activity window shows a Capture in progress, stuck for the past 25+ hours at less than 13 MB captured. I tried clicking the little x in the window, but nothing changed.
I went back in to Steph's account and the Activity window was there, too. The Actions window says a Capture is Running. I clicked the x in the Activity window again--still nothing.

How can I stop this process?
Have I hopelessly messed things up and do I need to start over and, if so, will I be able to use the existing archive so we don't have to go through building another 65+ GB file?

Thanks.
Mark

Mark Gerber wrote:How can I stop this process?

If you ever have a run-away QRecall process, it can be stopped using the Activity Monitor (or the Terminal or any similar tool of your choice).

Open the Activity Monitor and find the QRecallHelper process (there will be one instance of QRecallHelper for every running command or action. Select the process and click the Quit Process icon or choose View > Quit Process. Try doing a Quit first (this is equivelent to clicking the stop button in the Activity Window). If that doesn't have any effect, use Force Quit.

Have I hopelessly messed things up and do I need to start over ...

I can't see that you've done anything wrong, but I do see some problems with your external drive in the logs.

Your external drive attempts to disconnect/unmount at regular intervals. While QRecall wasn't doing anything, I found this in your log file:

2009-01-10 03:36:45.600 -0500 #debug# unmounted volume /Volumes/MAXimus
2009-01-10 03:36:46.339 -0500 #debug# mounted volume /Volumes/MAXimus
2009-01-10 03:51:45.598 -0500 #debug# unmounted volume /Volumes/MAXimus
2009-01-10 03:51:45.624 -0500 #debug# mounted volume /Volumes/MAXimus
2009-01-10 04:06:45.601 -0500 #debug# unmounted volume /Volumes/MAXimus
2009-01-10 04:06:45.644 -0500 #debug# mounted volume /Volumes/MAXimus
2009-01-10 04:21:45.599 -0500 #debug# unmounted volume /Volumes/MAXimus
2009-01-10 04:21:45.643 -0500 #debug# mounted volume /Volumes/MAXimus
2009-01-10 04:36:45.600 -0500 #debug# unmounted volume /Volumes/MAXimus
2009-01-10 04:36:45.632 -0500 #debug# mounted volume /Volumes/MAXimus
2009-01-10 04:51:45.598 -0500 #debug# unmounted volume /Volumes/MAXimus
2009-01-10 04:51:45.624 -0500 #debug# mounted volume /Volumes/MAXimus
2009-01-10 05:06:45.601 -0500 #debug# unmounted volume /Volumes/MAXimus
2009-01-10 05:06:45.635 -0500 #debug# mounted volume /Volumes/MAXimus
2009-01-10 05:21:45.599 -0500 #debug# unmounted volume /Volumes/MAXimus
2009-01-10 05:21:45.658 -0500 #debug# mounted volume /Volumes/MAXimus
2009-01-10 05:36:45.599 -0500 #debug# unmounted volume /Volumes/MAXimus
2009-01-10 05:36:45.783 -0500 #debug# mounted volume /Volumes/MAXimus
2009-01-10 05:51:45.599 -0500 #debug# unmounted volume /Volumes/MAXimus
2009-01-10 05:51:46.072 -0500 #debug# mounted volume /Volumes/MAXimus
2009-01-10 06:06:45.599 -0500 #debug# unmounted volume /Volumes/MAXimus
2009-01-10 06:06:45.667 -0500 #debug# mounted volume /Volumes/MAXimus
2009-01-10 06:21:45.600 -0500 #debug# unmounted volume /Volumes/MAXimus
2009-01-10 06:21:45.623 -0500 #debug# mounted volume /Volumes/MAXimus
2009-01-10 06:36:45.599 -0500 #debug# unmounted volume /Volumes/MAXimus
2009-01-10 06:36:45.635 -0500 #debug# mounted volume /Volumes/MAXimus
2009-01-10 06:51:45.598 -0500 #debug# unmounted volume /Volumes/MAXimus
2009-01-10 06:51:45.629 -0500 #debug# mounted volume /Volumes/MAXimus
2009-01-10 07:06:45.599 -0500 #debug# unmounted volume /Volumes/MAXimus
2009-01-10 07:06:45.629 -0500 #debug# mounted volume /Volumes/MAXimus
2009-01-10 07:21:45.599 -0500 #debug# unmounted volume /Volumes/MAXimus
2009-01-10 07:21:45.630 -0500 #debug# mounted volume /Volumes/MAXimus
2009-01-10 07:36:45.599 -0500 #debug# unmounted volume /Volumes/MAXimus
2009-01-10 07:36:45.667 -0500 #debug# mounted volume /Volumes/MAXimus

I don't know if the drive is being unmounted intentionally (unlikely), but it appears to be spontaneously ejecting itself during the day. It then immediately reconnects and mounts again.

In every case where the volume unmounted while a capture was in progress, the capture immediately encountered problems -- which isn't terribly surprising.

I suspect that the volume going off-line is the principle culprit. I would contact the drive manufacturer or look for some event that coincides with the volume being unmounted.

Thanks for digging in to that, James.

I tried using Activity Monitor to stop the runaway process but, while QRecallHelper did disappear from Activity Monitor, the QRecall Activity window showed it was still hanging. Ultimately, I restarted the MacBook, launched QRecall, mounted the drive, and started the capture again. Seems to be going fine for now.

As far as the mount/unmount sequence, I have no idea what might be causing it. I do have a sequence of actions that run from the Mini starting at 4:00 AM, but this problem seems to occur before, during, and after that process.

I have submitted a support ticket to OtherWorld Computing and I'm hoping they might have some clue. Or is it possible something in the network would initiate the connect/reconnect sequence?

Mark Gerber wrote:I tried using Activity Monitor to stop the runaway process but, while QRecallHelper did disappear from Activity Monitor, the QRecall Activity window showed it was still hanging.

That's would be expected. When a process simply "disappears" (which is what happens if you force quit it), it will take awhile for the activity monitor to figure out that the process is never coming back and remove its status from the window.

I have submitted a support ticket to OtherWorld Computing and I'm hoping they might have some clue. Or is it possible something in the network would initiate the connect/reconnect sequence?

Sporadic network communications problems could easily be the culprit. Especially if you are using wireless networking. Interference, noise, sunspots, or gremlins can often cause a wireless client to lose its connection and reconnect. This plays havoc with services that must maintain a continuous connection to a service, like a network volume.