QRecall

Bob Tyson

I have upgraded to v2.0 and am easily dealing with archives that are online and reachable at this moment. But I have other archives NOT presently online or reachable. What will I need to do in order to access them with v2.0 when I am able to reach them at a future date?

(They are on media stored in California; I am presently in Italy.)

James Bucanek

Bob Tyson wrote:(They are on media stored in California; I am presently in Italy.)

That is about as unreachable as it gets.

There should be very little to do, beyond just making sure you launch the QRecall application again once you and your California-bound archives are reunited.

The upgrade process is primarily concerned with updating your actions and archive settings. The items to exclude have been moved from the capture action to the archive's settings in 2.0. When you launch QRecall, it will transfer the settings you had in your capture action to the archive's settings, which is why it needs your archive to be reachable. Also, QRecall will update the alias in each action (the structure that tells the action where the archive is located) to a modern URL Bookmark.

Changes added in QRecall 2.0.0b20 improve how these updates are performed, and makes them incremental. Now, QRecall can detect which actions have had their settings and bookmarks updated. If your archive is reachable when you launch QRecall 2.0, it will update those actions and your archive's settings. If the archive isn't available, it does nothing to those actions and tries again the next time you launch QRecall.

When you return to California, connect your archives and run QRecall again. The actions it couldn't update before will be updated then. Once all of your actions have been updated, it will mark the upgrade process complete and stop trying. To confirm the update was successful, review the excluded items settings for your archive.

The archives themselves don't require any kind of upgrade; archives created with 1.x are can still be used with 2.0 as is. If you modify an archive with 2.0, however, it will be unreadable by QRecall 1.x because 2.0 writes new record formats the 1.x doesn't understand.

Bob Tyson

Thank you James. Straightforward enough.

But now a problem, and I saw this mentioned elsewhere here. After making a new archive of 800-odd GB fore one external disk, Then capturing to update another, QR "quit enexpectedly - do you wantto reopen" when I manually quit it. I cannot keep QR open now. It quits when I click "OPEN" to capture again to that newly-capured archive for the first external disk.

James Bucanek

Bob,

Yikes! I thought most of those issues had been dealt with in b11.

Send a diagnostic report and I'll take a look. In the report, let me know if it's just the one archive or all archives the cause the crash.

Bob Tyson

James, here are notes I added to the report. And **sigh** it appears to be just that one new archive. At least the other, which I had captured successfully afterwards, is now being captured again. (Sorry -- I get befuddled with terminology here: 'Capture' meaning in this case, capturing to a pre-existing archive, from an HD previously backed up to that archive; distinct from 'Recapture'?? Or what am I missing, still after 'x' years?

At any rate it does appear the large, new archive is the culprit.

EDIT - I attempted 'REPAIR' from the QR FILE menu. After confirming the volume OK I chose REPAIR without checking any other box. As soon as the repair began it failed - here are the log entries:

Action 2015-11-26 09:02:30 ------- Repair 1TB_FOTO_ARCHIVIO_PORTABLE_HD
Action 2015-11-26 09:02:30 archive: /Volumes/TO BACK 03 3T/1TB_FOTO_ARCHIVIO_PORTABLE_HD.quanta
Action 2015-11-26 09:02:30 Failure Failed
Action 2015-11-26 09:02:30 problem setting EOF
Action 2015-11-26 09:02:30 Failure Repair failed
Action 2015-11-26 09:02:30 A network or disk error was encountered.
Action 2015-11-26 09:02:30 ------- Repair incomplete (00:00)

But it got worse. As a double-check I tried to repair the second archive, the one I successfully updated and that seems ok. The repair started ok, and after a couple of minutes I clicked 'STOP'. After perhaps another minute a message came forth saying the archive index was damaged needed to be reindexed. This seems odd to me, but I am presently reindexing that archive, following the prompts.

Going back to the original issue of the QR quitting on trying to recapture the larger HD, here is more, my notes I included with the report I sent:

During the backup from the external HD to the new archive I trashed several large files from that HD. QR completed the capture, then went into a verify and reported problems with both the backup and the verify.

I opened the archive and eliminated the items I had trashed from the HD.

I then made a capture from a different external HD, previously archived with QR to it?s separate previous archive. That went off no problem.

After that I tried to capture the first HD again and at that point QR quits the moment I click on OPEN to start the new capture to update the archive.

James Bucanek

Bob Tyson wrote:James, here are notes I added to the report. And **sigh** it appears to be just that one new archive. At least the other, which I had captured successfully afterwards, is now being captured again. (Sorry -- I get befuddled with terminology here: 'Capture' meaning in this case, capturing to a pre-existing archive, from an HD previously backed up to that archive; distinct from 'Recapture'?? Or what am I missing, still after 'x' years?

It doesn't matter what you call it—capture, recapture, backup, vacuuming, ...—under the hood it's all the same thing.

At any rate it does appear the large, new archive is the culprit.

Yes and no, at least from the information I have. Most of your QRecall app crashes appear to be related to a race condition in the browser code. One thread is trying to load a large folder in the background at the same moment that you're closing the window/archive. That's what's causing the crash. So it's related to the new archive only in the fact that the browser was open to a particularly large folder when you closed the window. These are all very similar to crashes other users have reported, and all are under investigation.

EDIT - I attempted 'REPAIR' from the QR FILE menu. After confirming the volume OK I chose REPAIR without checking any other box. As soon as the repair began it failed - here are the log entries:

Action 2015-11-26 09:02:30 ------- Repair 1TB_FOTO_ARCHIVIO_PORTABLE_HD
Action 2015-11-26 09:02:30 archive: /Volumes/TO BACK 03 3T/1TB_FOTO_ARCHIVIO_PORTABLE_HD.quanta
Action 2015-11-26 09:02:30 Failure Failed
Action 2015-11-26 09:02:30 problem setting EOF
Action 2015-11-26 09:02:30 Failure Repair failed
Action 2015-11-26 09:02:30 A network or disk error was encountered.
Action 2015-11-26 09:02:30 ------- Repair incomplete (00:00)

Now that sounds serious.

But it got worse. As a double-check I tried to repair the second archive, the one I successfully updated and that seems ok. The repair started ok, and after a couple of minutes I clicked 'STOP'. After perhaps another minute a message came forth saying the archive index was damaged needed to be reindexed. This seems odd to me, but I am presently reindexing that archive, following the prompts.

It's not surprising to me at all.

When you start a repair (or reindex), QRecall blows away the existing index files and starts rebuilding them from scratch. The archive will be unusable until the repair has finished. Canceling it pretty much guarantees that your archive will remain "damaged".

During the backup from the external HD to the new archive I trashed several large files from that HD. QR completed the capture, then went into a verify and reported problems with both the backup and the verify.

I see from the log included in the diagnostic report where the new archive was created, you captured new files to it, deleted a few, and then performed a capture on another, existing, archive.

From the logs, all of that went very well. There were some warnings in the first capture about missing items because (I suspect) you were either moving or trashing some OS installer apps while the capture was in progress. It's a non-issue unless you were planning on recalling those, partially captured, items.

But that's all I've got. I assume the repair and some of the other issues you mention occurred after you sent the report. Please send another so I can review what is/was going on with the repair actions.

Bob Tyson

I assume the repair and some of the other issues you mention occurred after you sent the report. Please send another so I can review what is/was going on with the repair actions.

Okay -- here's part of the log to show successful reindexing of the second archive.

Action 2015-11-26 09:04:39 ------- Repair PHOTO-ARCH-500 Backup
Action 2015-11-26 09:04:39 archive: /Volumes/TO BACK 02 2T/PHOTO-ARCH-500 Backup.quanta
Action 2015-11-26 09:05:42 Caution Interrupted
Action 2015-11-26 09:05:42 Action canceled
Action 2015-11-26 09:05:42 Repair stopped by user
Action 2015-11-26 09:05:42 Warning Repair Stopped
Action 2015-11-26 09:05:42 The archive was not repaired. If the contents were being copied to a new archive, that archive is incomplete.
Action 2015-11-26 09:05:42 ------- Repair incomplete (01:02)
Action 2015-11-26 09:06:06 ------- Reindex PHOTO-ARCH-500 Backup
Action 2015-11-26 09:06:06 archive: /Volumes/TO BACK 02 2T/PHOTO-ARCH-500 Backup.quanta
Action 2015-11-26 09:06:06 Warning Problem prevented auto-repair
Action 2015-11-26 11:40:00 ------- Reindex finished (2:33:53)
Action 2015-11-26 12:00:07 ------- Verify PHOTO-ARCH-500 Backup
Action 2015-11-26 12:00:07 archive: /Volumes/TO BACK 02 2T/PHOTO-ARCH-500 Backup.quanta
Action 2015-11-26 14:29:08 ------- Verify finished (2:28:59)
Action 2015-11-26 15:00:08 ------- Repair 1TB_FOTO_ARCHIVIO_PORTABLE_HD
Action 2015-11-26 15:00:08 archive: /Volumes/TO BACK 03 3T/1TB_FOTO_ARCHIVIO_PORTABLE_HD.quanta
Action 2015-11-26 15:00:08 Failure Failed
Action 2015-11-26 15:00:08 problem setting EOF
Action 2015-11-26 15:00:08 Failure Repair failed
Action 2015-11-26 15:00:08 A network or disk error was encountered.
Action 2015-11-26 15:00:08 ------- Repair incomplete (00:00)

I also tried compacting the 1tb large new archive, but it looked to require at least 20 hours to do that. I decided to trash that new archive and start over again, which I am doing now.

James Bucanek

Bob,

I'd still appreciate a diagnostic report. I'm interested in all of the details that don't appear in the log window.

Bob Tyson

James, the capture of a new archive from the 1tb external HD is complete and I have sent the report.

Here is an oddity. I just now tried to copy a folder from my Mac to that 1tb external disk and could not do so without entering my admin password for the Mac's system. I did so, made the copy to the external HD, and then checked the latter's permissions. They were read-only for 'everyone' and read-write for 'system'. I changed the 'everyone' permission to read-write. But I am noticing various disks and folders seem to have had their permissions changed (?) to 'read-only ' for 'everyone'.

Am I missing something?

. . .

Few minutes later -- started to recapture the 1tb HD; process started with no apparent glitches.

James Bucanek

Bob Tyson wrote:James, the capture of a new archive from the 1tb external HD is complete and I have sent the report.

Thanks!

Here is an oddity. I just now tried to copy a folder from my Mac to that 1tb external disk and could not do so without entering my admin password for the Mac's system. I did so, made the copy to the external HD, and then checked the latter's permissions. They were read-only for 'everyone' and read-write for 'system'. I changed the 'everyone' permission to read-write. But I am noticing various disks and folders seem to have had their permissions changed (?) to 'read-only ' for 'everyone'.

A Finder copy should not (normally) change the ownership of items, unless you're copying to/from a volume that has the "Ignore ownership and permissions" property set. But even then, the ownership of items on those volumes will always be "you" (the logged in user).

Another thing to be aware of is that creating, moving, renaming, or deleting an item also involves the ownership of the folder that contains (or will contain) that item. In other words, creating a file is considered a "change" to the folder that contains the new file, and you must have write permission for that folder to accomplish that.

And in the "really obscure" department, there are special attributes (call Access Control Lists, or ACLs) that can be set on a folder that to do things like automatically set the ownership of items added to that folder and such, but it's unlikely that's the problem here.

Bob Tyson

James, and onward. I have sent you a report earlier today. Now as I look at the log I find the message in bold below. I have copied in more of the log to show the flow of things today.

Monitor 2015-11-28 02:12:46 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Action 2015-11-28 03:00:01 ------- Verify MILLIE VeN di Lia BACKUP
Action 2015-11-28 03:00:01 archive: /Volumes/TO BACK 03 3T/MILLIE VeN di Lia BACKUP.quanta
Action 2015-11-28 07:12:48 ------- Verify finished (4:10:55)
Monitor 2015-11-28 03:15:41 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Monitor 2015-11-28 03:21:37 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Monitor 2015-11-28 04:23:43 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Monitor 2015-11-28 04:29:19 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Monitor 2015-11-28 05:31:16 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Monitor 2015-11-28 05:36:47 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Monitor 2015-11-28 06:38:23 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Monitor 2015-11-28 06:43:45 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Monitor 2015-11-28 07:44:52 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Monitor 2015-11-28 07:50:12 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Monitor 2015-11-28 07:53:41 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Monitor 2015-11-28 08:51:11 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Monitor 2015-11-28 08:56:50 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
QRecall 2015-11-28 09:12:40 Warning Report generator exited with status 15; please report this to the developer
QRecall 2015-11-28 09:16:15 Sent diagnostics report
Action 2015-11-28 09:28:04 ------- Verify 1tb_ARCHIVIO_portattileFW
Action 2015-11-28 09:28:04 archive: /Volumes/TO BACK 03 3T/1tb_ARCHIVIO_portattileFW.quanta
Action 2015-11-28 15:58:27 ------- Verify finished (6:30:22)
Monitor 2015-11-28 09:58:42 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Monitor 2015-11-28 10:03:26 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Monitor 2015-11-28 11:05:25 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted

As I in part noted with the report, here are things that now don't quite look right:

1. Yes I clicked in the Status Window to have QR 'forget' the 1TB_FOTO_ARCH - xx history since that archive no longer exists and I have created a new archive for that external HD. But having the log show the message repeatedly like this?

2. Archive 1Tb-xx shows in the status window as amber but I can't see why. No pending actions; a Verify went to completion today. Still amber.

3. Archive MILLIE-xx is in the green on the Status Window but opening the archive shows that layer 0 is damaged:
Layer 0 -- Date UNKNOWN -- Size UNKNOWN -- Items DAMAGED.
---->> How should I regard this? What should I do to recover the data in this layer?

Thank you - Bob

James Bucanek

Bob Tyson wrote:Monitor 2015-11-28 03:15:41 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Monitor 2015-11-28 03:21:37 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Monitor 2015-11-28 04:23:43 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
...

That's a bug. In this case, QRecall discovered a status file for a version of 1TB_FOTO_ARCHIVIO_PORTABLE_HD that had at some point been deleted, or overwritten. It's supposed to log this message once and delete the (orphaned) status file. The delete step was broken.

QRecall 2015-11-28 09:12:40 Warning Report generator exited with status 15; please report this to the developer

Odd, and I'll look into it, but I'm not overly concerned about it. Apparently an problem occurred trying to sample some of QRecall's background processes in preparation of uploading a diagnostic report. But the report came through, and was intact, so I'm guessing this was a transient problem.

As I in part noted with the report, here are things that now don't quite look right:

1. Yes I clicked in the Status Window to have QR 'forget' the 1TB_FOTO_ARCH - xx history since that archive no longer exists and I have created a new archive for that external HD. But having the log show the message repeatedly like this?

Unfortunate coincidence, and unrelated to the real problem.

2. Archive 1Tb-xx shows in the status window as amber but I can't see why. No pending actions; a Verify went to completion today. Still amber.

Expand the status for 1Tb-xx and see which status is amber?capture, verify, or size?and what the status message is. The status indicators change for a variety of reasons, many unrelated to the health of the archive.

3. Archive MILLIE-xx is in the green on the Status Window but opening the archive shows that layer 0 is damaged:
Layer 0 -- Date UNKNOWN -- Size UNKNOWN -- Items DAMAGED.
---->> How should I regard this? What should I do to recover the data in this layer?

A damaged layer indicates that one or more items in that layer was, at some point in time, lost during a repair. It's a concern only if you recall items from that layer, as some items may be missing or incomplete. Eventually, the missing data will be replaced when that layer is merged with subsequent layers, and the "damaged" indicator will go away.

Your other issue, regarding not being able to repair your other archive, has also been fixed in 2.0.0b25, which should appear on the server shortly. Update to the latest version and try that repair again.

Bob Tyson

James, first I paste in here my notes to you with the Report sent a few minutes ago:

James, here a new report. I read your latest reply in the Forum. The Status Window now shows red for the 1TB-xx archive, on the first line with the note ?Captured 2 days ago?.

This item had been yellow yesterday when I previously wrote to you.

The other lines are green for Verified and for the space utilization item.

As you will note I have installed the update to 2.0.0b25 that you just made available. For the first report I sent today I hit ?send? and then cancelled because I?d forgotten to add my note. I have posted that same note here in the Forum.

To your next replies--

A damaged layer indicates that one or more items in that layer was, at some point in time, lost during a repair. It's a concern only if you recall items from that layer, as some items may be missing or incomplete. Eventually, the missing data will be replaced when that layer is merged with subsequent layers, and the "damaged" indicator will go away.

Your other issue, regarding not being able to repair your other archive, has also been fixed in 2.0.0b25, which should appear on the server shortly. Update to the latest version and try that repair again.

For a damaged layer, if I perform a merge, does this mean that only latest versions of files will be retained? Our concern is that files from earlier layers be retained (so long as not damaged) in order to maintain the integrity of the archive and not lose older 'original' photographic images.

If we understand correctly that we are maintaining successive versions in successive layers (so long as we do not merge layers) that is a little bonus but not an essential feature, because we maintain original files as inviolate like original physical negatives -- and do understand the consequences if we stray from that policy.

Finally, as to the 'other archive' -- that one was the earlier incarnation of the 1TB-xx HD -- and that archive has been eliminated so I won't have the opportunity to see if this new update to the beta will repair it. But I am content in affairs as they now stand. Thank you --

__________________________

Somewhat later -- note third Report sent at about 2:35 PST. Log showing most recent activity:

Monitor 2015-11-28 15:36:19 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Action 2015-11-29 08:12:40 Minutia Install
Action 2015-11-29 08:12:41 Minutia Uninstalled com.qrecall.hoist service
Action 2015-11-29 08:12:41 ------- Install finished (00:00)
Action 2015-11-29 08:12:47 Minutia Install
QRecall 2015-11-29 08:12:50 Minutia Removed resource link QRecallScheduler
QRecall 2015-11-29 08:12:50 Updating system components
Monitor 2015-11-29 08:12:51 Minutia Cannot connect to scheduler
Monitor 2015-11-29 08:13:48 Minutia Capture history for archive 1TB_FOTO_ARCHIVIO_PORTABLE_HD.alias appears to have been deleted
Monitor 2015-11-29 08:13:48 Minutia Capture history for archive PHOTO-ARCH-500 Backup.alias appears to have been deleted
QRecall 2015-11-29 08:31:43 Sent diagnostics report
Action 2015-11-29 09:05:00 ------- Capture to 1tb_ARCHIVIO_portattileFW
Action 2015-11-29 09:05:00 archive: /Volumes/TO BACK 03 3T/1tb_ARCHIVIO_portattileFW.quanta
Action 2015-11-29 09:05:00 Minutia Waiting for permission to open archive
Action 2015-11-29 09:06:22 Minutia Received cancel request
Action 2015-11-29 09:06:22 Caution Interrupted
Action 2015-11-29 09:06:22 Nothing Captured
Action 2015-11-29 09:06:22 ------- Capture finished (00:00)
Action 2015-11-29 09:09:08 ------- Capture to 1tb_ARCHIVIO_portattileFW
Action 2015-11-29 09:09:08 archive: /Volumes/TO BACK 03 3T/1tb_ARCHIVIO_portattileFW.quanta
Action 2015-11-29 09:09:08 Minutia Waiting for permission to open archive
Action 2015-11-29 09:18:08 Minutia Broke stale lock file
Action 2015-11-29 09:18:08 died: 2015-11-29 08:09:08 +0000
Action 2015-11-29 09:18:10 Minutia Acquired permission to open archive
Action 2015-11-29 09:18:10 Capture ARCHIVE 1T PHOTO
Action 2015-11-29 09:18:10 ARCHIVE 1T PHOTO:/
Action 2015-11-29 09:18:10 Minutia Locating changes since venerdì 27 novembre 2015 07:12
Action 2015-11-29 09:18:10 Collected 13 folder changes
Action 2015-11-29 09:27:35 Captured 1 item, 47 KB
Action 2015-11-29 09:27:35 captured: 47 KB (47.342 bytes)
Action 2015-11-29 09:27:35 written: 49 KB (48.648 bytes)
Action 2015-11-29 09:27:35 duplicate: 1 KB (234 bytes) 0.49%
Action 2015-11-29 09:27:35 rate: 5 KB/min
Action 2015-11-29 09:27:35 files: 2
Action 2015-11-29 09:27:35 folders: 3
Action 2015-11-29 09:27:35 icons: 0
Action 2015-11-29 09:27:35 ------- Capture finished (09:25)

Everything in the Status Window is now GREEN.

One last remark, I truly appreciate your patience and support. Perhaps it helps that I'm posting at hours when you may be sleeping or at least not at your screen, and vice versa. Kind of moderates the pace?

BT

James Bucanek

Bob Tyson wrote:James, here a new report. I read your latest reply in the Forum. The Status Window now shows red for the 1TB-xx archive, on the first line with the note ?Captured 2 days ago?.

That indicates that this archive hasn't performed a capture in 2 days. QRecall monitors the frequency at which you normally capture items to an archive, and raises a warning (in the status window) if that frequency suddenly drops off. In this case, I suspect that you regularly capture to this archive more than once a day. The status window is saying that nothing has been captured in over 2 days now, which might indicate a problem.

For a damaged layer, if I perform a merge, does this mean that only latest versions of files will be retained?

That's correct. Each layer embodies the changes that occurred since the previous layer was captured. When you merge two or more layers, only the latest version of those items is retained in the resulting layer.

Our concern is that files from earlier layers be retained (so long as not damaged) in order to maintain the integrity of the archive and not lose older 'original' photographic images.

Since you didn't use any of the special repair options, none of the items in the layer are damaged. Said another way, following a repair (with default options) all the items remaining in a layer will be intact and complete. The issue is items that might have been lost due to corrupted data.

In the browser, you can narrow the focus to a single layer using the layer shades and review just the items in that layer. (Tip: select the layer and choose "Shade Unselected Layers".) The items you now see in the browser are just the items captured in that layer. They are all fine, but there may be items that are missing because they were lost during the repair—and we have no idea what those are, because that data was corrupted.

The rest of your log looks good. I see nothing alarming.

One last remark, I truly appreciate your patience and support. Perhaps it helps that I'm posting at hours when you may be sleeping or at least not at your screen, and vice versa. Kind of moderates the pace?

It does, but maybe that's a good thing.

Bob Tyson

QRecall monitors the frequency at which you normally capture items to an archive, and raises a warning (in the status window) if that frequency suddenly drops off. In this case, I suspect that you regularly capture to this archive more than once a day. The status window is saying that nothing has been captured in over 2 days now, which might indicate a problem.

Oh. I have no action to schedule these captures; but in all this arm-waving last week I had recaptured a couple of times right after creating the new archive so I guess QR expected me to keep up the pace. Sorry, QR

Perhaps it helps that I'm posting at hours when you may be sleeping or at least not at your screen, and vice versa. Kind of moderates the pace?

It does, but maybe that's a good thing.

At least for me yes that is definitely a good thing. Thank you again. I'm putting the archive disks to bed here and will be picking up with the beta and so on when we get back to California in another week or so. Maybe I'll remember some of these lessons too!