Ralph Strauch wrote:The Activity Monitor shows the backup as waiting for the archive, but then when the archive is mounted the backup starts and then immediately stops, with nothing captured. The log shows a cancel request at the time the archive was mounted. If I then manually trigger the backup, it runs normally.

Well, that's certainly strange. Start by sending a diagnostic report, as there are additional details about who sent the cancel request and why which don't show up in the regular log window.

Also, the activity monitor doesn't accurately reflect what's going on. Right now mine shows that it's waiting for the next scheduled backup, while I'm in the middle of compacting layers. The log correctly show the compaction as in progress.

This is a known problem. In Lion, the activity monitor process sometimes fails to see when an action starts and thus doesn't monitor it. I've narrow this down to a specific notification message that isn't being delivered, but I don't know yet whether this is a bug in Lion or QRecall.

Matthew,

Thanks for the sample output and the diagnostic report.

Your QRecallHelper process is indeed stuck and I vaguely remember this problem.

It would appear that QRecall is encountering an I/O error from the volume containing the archive:

2011-10-26 10:13:23.675 +0100 Details archive I/O error

2011-10-26 10:13:23.675 +0100 Details Cause: <IO> cannot read hash entry { API=FSReadFork, Pos=620910680, OSErr=-36, Length=12, File='/Volumes/My Book 1/Current Work Backup.quanta/hash.index', Class=CarbonFile }

There's a bug in 1.1.4 that when this kind of error happens, an internal dead-lock occurs and the process gets stuck.

So I suspect that you're having random problems reading/writing to your external drive.

First, make sure there's nothing wrong with external drive's volume format. Use Disk Utility to repair the volume.

Then make sure the QRecall archive is in good shape by running a Repair on the archive. I would also highly recommend that you schedule verify, merge, and compact actions to run on a regular basis. At that very least, schedule a verify to run once a week. This will alert you to any possible data integrity problems that might have crept into your archive.

This could, ultimately, be a hardware problem with the external drive. Once you've done these repair steps, we can revisit the problem in more detail should it reoccur.

Matthew,

Without doing some additional research, it's hard to tell what might be going on. From experience, I can tell you that actions can sometimes get stuck when network communications breaks down, but it's not clear that this is the case here.

If you want to diagnose the problem, here's what I'd suggest:

- You didn't mention what version of QRecall you're running. If you have Help > Send Report... command in your QRecall menu, then start by doing that.

- Open the Activity Monitor application, filter on QRecall, and find the QRecallHelper process. This is the process that actually performs whatever action you're running (and is why it doesn't stop when you quit QRecall). Find the process ID number (PID).

- Open a Terminal window. Enter the following command

sudo sample PID -file ~/Desktop/QRecallHelper.sample.txt

... where PID is the number you found in the previous step.

Enter your account's password and wait for the command to finish. When it has, e-mail the QRecallHelper.sample.txt on your desktop to james@qrecall.com.

Now while you're still in the Activity Monitor, you can kill the QRecallHelper process: select the QRecallHelper process and use the Quit/Force Quit command. This is faster than restarting, and accomplishes the same thing (when you restart, Mac OS X force quits all stuck processes).

Open the QRecall application.

Holding down the Shift and Option keys, choose QRecall > Quit and Uninstall from the menu.

Complete uninstall instructions, including a manual procedure, is in the help. See Help > QRecall Help > Advanced > Uninstall QRecall.

Johannes wrote:... can we get "run Action" with a submenu of all actions as well?

That would be considerably more difficult … but it does sound terribly handy, and I'll look into it.

Johannes wrote:Would it be possible to get a "Suspend all Schedules"/"Resume Schedule" item there?

That would be very easy to add to the menu, just as soon as there is a "Suspend all Schedules"/"Resume Schedule" command.

Seriously, I've had the "Suspend all Schedules" feature on the to-do list for a very long time. I might just take a break from inspector windows and take a swing at it.

Thanks for the feedback.

Nice catch!

The activity monitor was using the wrong preference value to determine if it should open the window at application startup.

It's all straightened out now, and the fix will show up in the next beta release—which, if everything is working correctly, will appear in the activity window.

It looks like we finally nailed this bad boy!

Anyone who wants to test this fix can download QRecall 1.2.0a52.

The bug would randomly manifest itself when recapturing large files (like disk images) that happened to be an even multiple of 3,145,728 bytes (3MB) long, with shifted quanta detection cranked up.

Gary K. Griffey wrote:This appears to be the crash that we have discussed before...where it is tripping over the icon cache...

In this case, it's not the same problem. QRecall is crashing trying to handle a fatal exception encountered while reading a file. It tries to read the file, fails, tries again, gives up, and then begins the process of aborting the capture of the file and reporting the problem—that's when it crashes.

What I don't know is if it had a chance to log the root cause of the problem before the crash. Please send a diagnostic report (Help > Send Report...) to answer that question.

Anyone who's experiencing this problem can download this alpha release: QRecall 1.2.0a50.

Good or bad, pleases post your experiences with a50 here, by uploading a diagnostic report (Help > Send Report...), or both.

Gary,

I just checked up on Growl development, and it looks like I can upgrade QRecall from the Growl 1.2 framework to the 1.2.2 framework. Most comments seem to indicate that 1.2.2 works reliably with Growl 1.3 on Lion.

The Growl 1.3 SDK isn't available yet, and doesn't support Leopard, so that isn't an option right now. I'll upgrade the embedded framework this week and it should roll out with the next release of QRecall. Please me know if the behavior changes.

Gary K. Griffey wrote:I purchased the new Growl 1.3 available via the App store for my 10.7.2 machine.

Gary,

I saw the announcement by the Growl Team a few weeks ago that they had produced an App Store version of Growl along with a new SDK for developers. I made a note to update the Growl framework imbedded in QRecall, but haven't gotten around to it just yet.

The latest App Store Growl, however, should work with older Growl compatible software. And for some people, such as Steve, that's clearly the case.

A few Growl developers, however, have commented that sometimes it works and sometimes it doesn't, and there's no clear consensus right now as to why. One thing you might try is to log out and back in again (if you haven't already). The Growl source in QRecall is the monitor process, which starts when you log in and stops when you log out. Note: if you're running the Beta version of QRecall, choose the Windows > Restart Monitor command—you'll get the same effect.

I will note that the old version of Growl uses distributed notifications to communicate. Several users of QRecall have noted that the monitor window sometimes doesn't appear when an action starts. QRecall also uses distributed notifications to announce when actions start and stop. Personally, I think there's something wrong with distributed notifications in Lion.

Gary K. Griffey wrote:Sorry...

No need to appologize. It is a bug in the UI, which I've hopefully fixed for everyone, and will appear in the next version.

If anyone is having similar problems and can't work around it, drop me a message and I'll provide an alpha release to try.

Steve,

There were a couple of subtle Lion-related bugs in the browser interface. I've plugged a couple of them. I don't know if I've gotten them all, but I can no longer reproduce what you reported (both here and in the diagnostic reports you sent).

One thing I did discover is that Lion has broken a number of QRecall features:

The Reveal in QRecall Archive service

The Capture to QRecall Archive service

Searching for an item by opening an archive from a Spotlight search

All of these features depend on information being passed to the application via AppleEvents (the technology on which AppleScripts is built on). In Lion, none of this information is getting passed to the application.

I'm looking into this situation now.

Bruce Giles wrote:Does QRecall (either the current release or the beta) require Spotlight on the backup volume?

No.

QRecall does not have any features that depend on Spotlight indexing its archives—except, obviously, the ability to find items in archives using Spotlight.

Whether you choose to have Spotlight index your archives or not is up to you, but it won't change how QRecall operates.