Here's a new one...

I hate to sound like the guy with all the issues, but have you seen Qrecall just stall at the same point each time?
I was doing TM and full duplicates on my Mac Pro in the studio but switched that over to Qrecall (so all three machines use it). This one is also connected to the same HD on an Airport Extreme.
Every time the file gets to iPhoto at 1.59GB it stops. Nothing crashes, the timer keeps going, and there is nothing in the log. The only way out is to restart the machine. This definitely is a network issue as doing the backing to a second internal drive worked fine.
I did use the Terminal code to skip pre-allocation.
Thanks
Chris

Chris Caouette wrote:Every time the file gets to iPhoto at 1.59GB it stops.

My first question is "does it really stop?" My second questions is "how long did you wait?"

Some directories contain hundreds, even thousands, of items. This is especially true of folders containing music, pictures, and mail, were the application keeps lots of individual files in one massive folder. This requires QRecall to read and compare hundreds, if not thousands, of file records which in turn require tens of thousands of little reads from the archive.

On a local drive, this can be accomplished pretty quickly. But on some networked file systems this can take orders of magnitude more time. It may seem like the capture is "stuck," when in reality it's simply grinding its way through a bazillion file records.

The way to test this theory is to run an application like Activity Monitor. If the QRecall capture is still working, you should see a steady flurry of small network reads and sends. If you see that, and the CPU usage of QRecall Helper indicates activity, then it's probably still working. BTW, you can use the Activity Monitor to force quit the QRecall Helper process if you need to force an action to stop.

Hi James,
Activity monitor was at 0 and I left it overnight. It definitely stops at iPhoto and 1.59GB. I checked the drive for errors this morning and it was fine, plugged back into network and retried with the same result.
Tonight I'll boot from a CD and check the drive I'm trying to back up in case it is what's causing the hangup.

Chris

Chris Caouette wrote:Activity monitor was at 0 and I left it overnight. It definitely stops at iPhoto and 1.59GB.

That's definitely "stuck."

A good test would be to perform the same capture, to the same archive, on the same volume, but when it's connected directly to the Mac Pro. If that works, then it seems likely that this is a network/Airport issue.

If you want to help track down the problem, do this:

Let the capture run until it gets stuck.

Open the Activity Monitor.

Find and select the QRecallHelper process (I usually type "QRe" into the search field).

Get the PID number of the process.

Open a window in Terminal.

Issue the following command, replacing PID with the number from Activity Monitor:

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

Enter your account password

When it's done, e-mail me the QRecallHelper.sample.txt that's now on your desktop, followed by a diagnostic report (Help > Send Report...).

Sent. It did work when attached directly but still gets stuck on the airport.
Thanks,
Chris

UPDATE: Problem Solved. I didn't have 1.13a6 installed on the Mac Pro. What it wasn't telling me was the FSR path error so I didn't realize it.
Once I updated it began to work fine.
Thanks again!
Chris

Chris Caouette wrote:UPDATE: Problem Solved.

The sample was inconclusive, but the log file you uploaded was full of -36 errors. I'm satisfied that this is the same Airport bug that 1.1.3a6 works around.

I'm glad you were able to resolve the problem, and please post anything else odd that you encounter.