I've been evaluating QRecall again for the last couple of weeks (now using v55).
After several days of successful capture I get all of a sudden

Lost connection with command

followed by

Unable to connect with helper

followed by

data integrity error in the archive (header file length invalid)


This has occurred several times over the last 4 weeks.

I'm capturing to an external firewire 400 drive - I'm running Leopard.

Hello John,

It sounds very much like the helper application is crashing.

Please forward me your log files (just zip up your ~/Library/Logs/QRecall folder), and any crash reports in /Library/Logs/CrashReporter that start with QRecall.... You can post those here to the forum, or just send them directly to me (james at qrecall.com).

Here's the QRecall Log

John,

Thanks for the QRecall log. The scheduler is definitely losing its connection with the action. Unfortunetly, there's nothing else in the log to tell me why. Do you have any crash report files in /Library/Logs/CrashReporter that start with QRecall? If so, select them all, create an archive, and send those to me. If the helper is crashing, this should tell me why.

Here's the reports

John,

Thank you very much. That was exactly the information I needed to find and eliminate that bug. It was a rather nasty one, so I'm glad you contacted me about it.

The fix is available immediately in QRecall 1.0.0(55d). To try this version:

1) Download the disk image (using the link above)
2) Trash (or set aside) your current version of QRecall
3) Copy 1.0.0(55d) to QRecall's previous location
4) Launch the new version

This fix will also appear in the next public release. If you encounter similar problems with 55d or later, please let me know immediately.

Thats OK,

now testing with 55d

Hey there -- I am evaluating QRecall ... my setup is an airport extreme network at home with a couple of laptops and a terabyte NAS drive with wireless access (the Iomega "storcenter" drive). QRecall shoves data over the net about 3x faster than Time Machine, which rocks, but every time I run it, I get a failed capture ... so I have yet to make a successful backup. Any suggestions? I've attached the logfile Library/Logs/QRecall/QRecall.log ... There are no files in /Library/Logs/CrashReporter.

Thanks,
Bruce

bruce jacob wrote:my setup is an airport extreme network at home with a couple of laptops and a terabyte NAS drive with wireless access (the Iomega "storcenter" drive). QRecall shoves data over the net about 3x faster than Time Machine, which rocks, but every time I run it, I get a failed capture ... so I have yet to make a successful backup.

Bruce,

It looks like you're losing the connection with the NAS drive. This could be either a dropped wireless connection or the drive itself is going off-line. Given my recent experience with wireless, I'd guess the former. The key message in the log file was

2008-05-05 00:16:45.389 -0400 Capture failed
2008-05-05 00:16:45.389 -0400 A storage or disk error occurred while writing to the archive data. This could indicate a hard drive failure, or the drive or volume was disconnected. The archive is probably damaged.

This means that QRecall suddenly couldn't read or write to the archive.

What you might try is this: Perform the first, full, capture with the Iomega connected directly to the laptop then plug it back into the Airport Extreme then see how things go. This isn't a solution as much as just trying to avoid the problem. Once the initial capture is finished, subsequent captures will be much faster and the chance of losing the network during the capture is smaller.

I'm currently working on a version of QRecall that will tolerate the loss of a drive or network connection during a capture much more gracefully than the current version. I know I've been promising this version for a couple of months, but both personal and professional interruptions have delayed getting it into beta. Hopefully, I should have version 1.1 available as a beta by the end of May. So try doing the initial capture directly and look for a beta of QRecall in the near future.

Hey there -- thank you for the advice. I tried that; it worked fine for a week or so (see the attached log). I was out of the country over the last week and a half, and the trial key expired while I was gone. Got home last night, bought a key this morning, and then started a capture by hand (clicked on the Capture event in the Actions window and then hit the "Run" button), rather than waiting until the auto-scheduled time of 3:00 am.

The problem is that the capture seems to be starting from scratch all over again -- it seems to be shoving my entire disk space over the wifi link, instead of doing an incremental backup -- and due to the wireless NASD thing, it is failing. Do I really have to start all over again by hooking the NASD directly to my two laptops (a bit of an inconvenience; I'd rather not have to do it more than once a year), or have I just done something wrong?

Running the latest version of QRecall [Version 1.1.0(37) rc (1.1.0.37)].

Thanks,
Bruce

Got home last night, bought a key this morning, and then started a capture by hand

The problem is that the capture seems to be starting from scratch all over again

Yes, the capture is starting over. The reason is because you're using a new identity key.

QRecall now sees your system as a new owner and (from its perspective) is capturing everything for the first time. As it does this, it notices that every one of your files is remarkably similar to the ones captured by that "other" user who had the trial identity key. So the archive isn't growing substantially, but it will create a new layer belonging to your new identity that contains every item on your volume.

When its done, you'll have two owners in your archive. If you want to recall something from before the identity key change you'll need to switch to the old owner in the Owners & Volumes drawer. Eventually you'll probably just want to delete that owner by selecting the volume belonging to the old owner and choosing the Archive > Delete Item command.

Greetings..

I am running the 1.1.0.42 release of QRecall. I am now experiencing the same issue as the original poster..."Lost Contact with the Helper"...

Is the fix that you posted back in January 55D included in the 1.1.0.42 release?

If so...the problem evidently has not been fixed...

Thanks,

GKG

Gary K. Griffey wrote:I am running the 1.1.0.42 release of QRecall. I am now experiencing the same issue as the original poster..."Lost Contact with the Helper"...

The "lost connection" message is a generic one that just means that the monitoring application(s) lost touch with the process that's actually performing the action. This usually happens because the action process crashed.

A process can crash for lots of reasons, it doesn't mean it has anything to do with the issue fixed in 1.0.0.55. The best thing to do is to send in a diagnostic report (Help > Send Report...). This will include any crash logs for your QRecallHelper process, which might provide some clues as to what the problem is.

Thanks...

I will send the requested info...

GKG

Gary K. Griffey wrote:I will send the requested info...

Gary (and anyone else this might affect),

I haven't received a diagnostic report from you. There's a known bug (fixed in the currently unreleased version) that can cause the report upload to fail if the log files are too big.

If you, or anyone, sends a crash report and you do not immediately receive an automated e-mail acknowledgement from the server, then please report your problem manually.

At a minimum, please include a copy of your latest QRecall.log files (in ~/Library/Logs/QRecall) and any crash report files. These can be found in either /Library/Logs/CrashReporter/ or ~/Library/Logs/CrashReporter/ and will all have names beginning with QRecall.

Post a description of your problem and those files, or e-mail them to support@qrecall.com.

Thanks,

James