Steve,

No problem -- I'm just glad thinks are working now.

Beta identity keys are permanent. The beta application itself will expire, but your identity key won't.

The only thing that should cause you to lose your identity key is if you lost the preference file/folder where your identity key is stored. The self-uninstall procedure (Command+Option+Shift+Q) should not delete your key, but performing the manual uninstall instructions found in the advanced topic of the help will. If you performed the manual uninstall in an attempt to diagnose your earlier problem, that would definitely erase your key. Identity keys are also user specific, so running QRecall from another user account or from a different boot volume will require that you reenter a key. Note that if you are running QRecall from multiple accounts on the same machine you can enter the same identity key for all of those users, or use a different identity keys to keep the data captured by each user separate.

And I agree that the identity key entry screen is confusing. Apple added "default text" to text entry fields recently and I used that to display a sample identity key. However, Apple's method of displaying the default text (i.e. the value of the field if you don't enter anything) is to draw it dimmed. I've had two individuals think that there was already an identity key entered, and two more now that thought the field was disabled.

I'll probably replace this with a prompt or simply leave the field blank in the next version.

Thanks for the feedback.

Here's a tip:

If you are recapturing large disk images, you'll get much better performance if you turn off (lowest setting) shifted-quanta analysis in the archive's settings. This will greatly improve recapture performance.

Disk images are an array of immovable blocks. Data doesn't "shift" in a disk image the way it can in a file. So searching for shifted data wastes a great deal of resources.

I'm not sure exactly what a VM file is, but if VM files are like large multi-media projects or disk images, then they are exactly the kind of incremental backup problem that QRecall was designed to deal with.

When the file is recaptured, QRecall will read each block (quanta) of data and compare it with those that have already been captured. Only new data blocks are added to the archive.

In the situation of a disk image, take a 600MB disk image file. If you mount that image and add a single 1MB file, only a little over 1MB worth of data has changed. When QRecall recaptures the file, it will discover 599MB of duplicate data and only adds 1MB of new data to the archive.

There's a similar situation with large multimedia files like Photoshop or audio files. Open up a 300MB Photoshop file and add an adjustment layer. The original 300MB of data is still in the file, although it might have shifted to a slightly new location. That's where QRecall's shifted-quanta analysis gets to work. It still finds the 300MB of existing data and only adds the new data to the archive. Ditto for changing the MP3 tags on a large audio file. The audio hasn't changed, only the tiny bit of tag data.

Now this still requires QRecall to re-analyze all of that data, which will be time consuming. So this is definitely something that you'll want to schedule to run at night or when you're not using your system.

(And I'm glad you like the answers.)

john hampson wrote:I rescanned my 15GB archive, and it found/added/changed 588 items from 92,457 in around 3minutes. That was pretty impressive! Also the system was still pretty responsive while it was happening!

Good! That's the way it is supposed to work.

Incremental recaptures are designed to be very fast, as this is the action that will occur the most often. And I have some optimizations to make it even faster in the future.

I can't legally comment on Leopard features because I'm an Apple developer and have signed a non-disclosure agreement.

However, from the information that Apple has made public about Time Machine I can make two comparisons.

First, QRecall is vastly more efficient than Time Machine (and most other backup applications in general). Time Machine simply copies files, while QRecall analyses the data in files and eliminates any duplicate data from the backup archive. So your backup storage is guaranteed to be larger than the original set of files with Time Machine, while with QRecall your backup archive plus incrementals will more than likely be smaller. This means that you can use a significantly smaller backup drive or keep incremental data longer, or both.

QRecall is significantly more configurable than Time Machine.

Personally, I was both delighted and dismayed when Apple announced Time Machine. Delighted, because Apple recognized many of the same problems with existing backup software that QRecall is trying to overcome. I think it will also encourage more people to implement a disk-to-disk backup plans.

At the same time it's disheartening to see Apple integrate many of the features that we've been developing over the past two year then build it into the OS and give it away for free.

But QRecall still has a distinct set of features that I think will provide some competition to Time Machine.

john hampson wrote:I seemed to have 600MB of inactive memory, so the memory wasn't an issue.

This is a common misconception. Inactive memory is not unused memory. It's just memory that hasn't been accessed recently (read "few seconds").

The speed would go up to 400MB/min for smaller files, but seemed to slow considerably for larger files. I would have expected the opposite.

I've been a longtime user of Chronosync - it seems to "play better" with other applications.

This is because of the fundamental difference between QRecall and other backup applications. QRecall analyses every block of data in a file to determine if any of that data has already been captured (in that file or any other file). It also searches for duplicate data that has shifted to a different location in the file.

By contrast, applications like Chronosync, SuperDuper, Retrospect, et. al. merely look for files that have changed and copy those files. The larger the file, the less work they have to do.

For QRecall, the larger the file the more work is has to do.

This is an unfortunate consequence of the amount of work that QRecall is doing. The QRecallHelper is that task that's doing the lion's share of the work. It uses a lot of RAM and can saturate the I/O at the same time.

If you are trying to use other applications at the same time, the problem is probably virtual memory swapping. While QRecall is working it pushes segments of code and data from other applications out of memory and into the swap files. When those applications need that code or data they have to swap it back in. This is made more difficult because the disk drive is already busy copying file data to the archive, so those swap requests have to wait.

You can verify this by watching the page in/out numbers in the Activity monitor. Sluggish behavior will be accompanied by ever rising page in/out numbers.

You can reduce the amount of work that QRecall does by lowering the Shifted Quanta detection setting for the archive. (Setting at it lowest setting essentially turns it off). But this won't reduce the burden on I/O. In fact, it will tend to increase I/O.

I have plans to improve the performance of QRecall in several places. This requires restructuring some of the code to take better advantage of multiple processor systems and reduce the amount of memory it uses. Both of these should improve how QRecall plays with others.

Unfortunately, these changes require significant modifications to the core capture routines -- changes which must be made very carefully. So I don't have plans to make these performance improvements in the immediate future. But if performance becomes a persistent problem for people, I can re-prioritize that work.

I live for pedantic.

john hampson wrote:should say "capture is performed".

Thanks. That correction will show up in the next release.

Oops!

Yes, if version 1.0.0b37 is your first version of QRecall, you are going to have this problem. The logic for creating the support folders changed recently and was never tested on any brand new users.

I've fixed the problem and have released 1.0.0b38. Choose QRecall > Check for Updates... to get the corrected version.

It has been discovered that the new log viewer in QRecall 1.0.0b35 can crash when it tries to read log records written by versions b33 and earlier. The problem involves log records that contain non-ASCII characters or invalid NonLossyASCIIEncoding character sequences.

Users who have been running versions b33 and earlier should upgrade to b36. You can do this by choosing QRecall > Check for updates....

If you are experiencing a log viewer crash now and can't get QRecall to auto-update, download the latest version at http://www.qrecall.com/release/QRecall_1.0.0b36.dmg, drag your existing QRecall application into the Trash, drag the new version to your Applications folder and launch it. You can now empty your Trash.

Fixed.

This will show up in the release.

If anyone finds themselves in this situation, just save all windows that have something worth saving and force quit the application from the dock (Option+Control+Click QRecall dock icon > Force Quit)

Steven M. Alper wrote:Well, it seems to be APE that's the culprit. QRecall runs fine with it disabled. (And it's pretty!)

That's good news — from a debugging standpoint, at least. I'll set up a partition, install APE, and see if I can reproduce the problem here. Hopefully, there's a simple fix.

Thanks for being so patient.

Steven M. Alper wrote:Don't really need to enter any more than QR. Here's the result:

340 QRecallScheduler alper 0.00 1 6.55 MB 27.63 MB
643 QRecall (Not Responding) alper 0.00 7 23.76 MB 242.55 MB
645 QRecallMonitor alper 0.00 4 13.50 MB 215.07 MB

I'm pretty sure I know what the problem is, I just don't know what's causing it. I think the QRecallMonitor is hung and when QRecall goes to talk to it it gets hung up too.

In the Activity Monitor, Quit or Force Quit the QRecall Monitor process. See if this shakes the main QRecall application loose. If that works, hold down the Option+Shift keys and select QRecall > Quit and Uninstall, then relaunch QRecall.

Are you, by any chance, upgrading from an earlier version of QRecall?

Do you have any haxies or other UI goodies installed?

Hello Steven,

A couple of questions:

- Did you first copy the application into your Applications folder or did you launch it from the disk image? (QRecall is designed so that it shouldn't matter, but maybe it does.)

- Are you using FileVault?

- Launch Activity Monitor, set it to show All Processes, then enter "QRecall" into the search field (without the quotes). Are there any processes listed?

- Are there any related messages in the system or console logs?

Whoops! I was a little overzealous on what characters to disallow in e-mail addresses.

It's fixed now. Go ahead and register, or edit the e-mail address of your existing account.