https://forums.qrecall.com/posts/list/6.page JForum - http://www.jforum.net 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.


]]> https://forums.qrecall.com/posts/preList/96/407.page https://forums.qrecall.com/posts/preList/96/407.page GMT
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).]]> https://forums.qrecall.com/posts/preList/96/409.page https://forums.qrecall.com/posts/preList/96/409.page GMT https://forums.qrecall.com/posts/preList/96/410.page https://forums.qrecall.com/posts/preList/96/410.page GMT
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.


]]> https://forums.qrecall.com/posts/preList/96/411.page https://forums.qrecall.com/posts/preList/96/411.page GMT https://forums.qrecall.com/posts/preList/96/412.page https://forums.qrecall.com/posts/preList/96/412.page GMT
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.]]> https://forums.qrecall.com/posts/preList/96/413.page https://forums.qrecall.com/posts/preList/96/413.page GMT
now testing with 55d


]]> https://forums.qrecall.com/posts/preList/96/415.page https://forums.qrecall.com/posts/preList/96/415.page GMT
Thanks,
Bruce]]> https://forums.qrecall.com/posts/preList/96/526.page https://forums.qrecall.com/posts/preList/96/526.page GMT 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

[b]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.[/b]

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.
]]> https://forums.qrecall.com/posts/preList/96/527.page https://forums.qrecall.com/posts/preList/96/527.page GMT
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]]> https://forums.qrecall.com/posts/preList/96/760.page https://forums.qrecall.com/posts/preList/96/760.page GMT
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 [b]Archive > Delete Item[/b] command.
]]> https://forums.qrecall.com/posts/preList/96/761.page https://forums.qrecall.com/posts/preList/96/761.page GMT
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]]> https://forums.qrecall.com/posts/preList/96/884.page https://forums.qrecall.com/posts/preList/96/884.page GMT
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.
]]> https://forums.qrecall.com/posts/preList/96/885.page https://forums.qrecall.com/posts/preList/96/885.page GMT
I will send the requested info...

GKG]]> https://forums.qrecall.com/posts/preList/96/886.page https://forums.qrecall.com/posts/preList/96/886.page GMT
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 [i]not[/i] 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 [url=mailto:support@qrecall.com]support@qrecall.com[/url].

Thanks,

James]]> https://forums.qrecall.com/posts/preList/96/887.page https://forums.qrecall.com/posts/preList/96/887.page GMT https://forums.qrecall.com/posts/preList/96/888.page https://forums.qrecall.com/posts/preList/96/888.page GMT
Thanks for sending me your files. They didn't include any crash logs, but after reviewing your log files I don't think you have any.

The only instance of a "lost connection" error was recorded on April 4. (If you want to to look further back, send me some older log files). Most notable is this log entry:

[code]2009-04-04 05:16:21.946 -0500 #debug# VerifyCommand listeners probably dead, terminating process[/code]
It appears that the listener process (the Activity Monitor window) was simply running too slowly to keep up with the action's updates. The inter-process equivalent of the spinning beach-ball cursor.

What happens when an action is done is that it sends all of its listeners a message that it has finished. It then waits around for about a minute for those listeners to acknowledge that it's done and close their communications connection. If the listeners don't, the action process assumes that they died and just terminates. That's what is recorded in your log. But, if it turns out, the listeners weren't really dead, they may attempt to communicate with the action process again, which fails because that action no longer exists. This results in a "lost communication with helper" error.

Since I don't see any other errors or problems in your log, I'm confident that this was a harmless, and sporadic, communications failure between processes and not a failure of the verify action that was running at the time.

]]> https://forums.qrecall.com/posts/preList/96/891.page https://forums.qrecall.com/posts/preList/96/891.page GMT