I seem to recall that QRecall should alert the user to errors through a QRecall Activity Monitor message which is displayed until dismissed by the user. This does not seem to be so on my machine and I wonder if it's a problem with my installation or something more general.

I have QRecall set up to back-up at night when I'm logged out. Before a recent vacation, I 'suspended' all its operations. On return I 'reactivated' them all. As QRecall did not display any error messages, I assumed that all was well. Yesaterday I launched it to check. I was disturbed to find that it had not made any back-ups since its 'reactivation' - a period of nearly two weeks. The reason was that the archive indexing was wrong and the archive did not therefore open. QRecall repaired the index and all is now well again.

Is there a way to ensure that QRecall advises errors automatically? If not, might I add it to the wish list?

-- Charles

Charles Watts-Jones wrote:I seem to recall that QRecall should alert the user to errors through a QRecall Activity Monitor message which is displayed until dismissed by the user. This does not seem to be so on my machine and I wonder if it's a problem with my installation or something more general.

In general, QRecall tries to be as annoying as possible when an error occurs.

However, there are some limitations which might be affecting you.

The warning indicator appears in the QRecall Activity window when an action fails to finish properly. If the activity monitor process isn't running, most likely because you're logged out at the time, then there's nothing to catch and display the warning. Also, if you use spaces the warning may be appearing in another space.

Is there a way to ensure that QRecall advises errors automatically? If not, might I add it to the wish list?

QRecall also works with Growl, which has many notification options—but again only while you're logged in.

I'll add a wish list item to be notified of problems that occur while you are logged out.

James Bucanek wrote:The warning indicator appears in the QRecall Activity window when an action fails to finish properly. If the activity monitor process isn't running, most likely because you're logged out at the time, then there's nothing to catch and display the warning. Also, if you use spaces the warning may be appearing in another space.

I understand now. I don't use Spaces but I do run my back-ups when I'm logged out.

I'll add a wish list item to be notified of problems that occur while you are logged out.

Sounds good. Perhaps it could email the affected user as soon as someone logs in to the machine?

My puzzlement is because of the opposite to this situation. The monitor or status "eye" in the menu bar (MBP - 10.8.4) is red, but so far as I can tell the archives that are active are ok and incremental backups proceed with no problem.

When I look at the status window, by clicking on the "eye" to open it, there is a long list of items with red "X"s next to them and notes of archive needs repair et cetera. Some show a "repair" button but that does nothing, even with the archive volume and the capture item volume mounted, and QRecall active.

I'm convinced the archives are ok. One reason is that after formatting an archive volume and making a new backup that failed, and produced warning messages, I trashed that faulty QR archive file and re-created a new one in QR, then made an action that completed the new complete archive and subsequently an incremental backup. The whole process proceeded quickly and the status window reports this most recent archive and backup cycle as healthy.

In spite of this the earlier red flag items remain, and the "eye" stays red. I quit QR, restarted the mac, and trashed the library/logs/qr files. The "eye" stays red.

How can I dismiss the "red flag" items and let the "eye" in the menu bar go to white, so it will not cry wolf but only be red if there really IS a problem?

Bob,

You probably have stale status information. QRecall caches a copy of the archive's status (so it can be displayed when the archive is off-line). If the path/alias to the archive has changed, the copy of the status gets disconnected from the actual archive and you end up with two statuses—one active and one stale.

Bob Tyson wrote:One reason is that after formatting an archive volume and making a new backup that failed, and produced warning messages, I trashed that faulty QR archive file and re-created a new one in QR, then made an action that completed the new complete archive and subsequently an incremental backup. The whole process proceeded quickly and the status window reports this most recent archive and backup cycle as healthy.

Now I know this is what's happened. Reformatting a volume is almost guaranteed to break the alias records that QRecall uses to locate archives.

Open the archive status window. Find the stale ones (they will report that they haven't been captured or verified in days or weeks), right/control+click on one, and choose Forget.

Forgetting a status is always harmless. It simply discards the cached copy of the archive's status. If you forget an active archive, there's no harm; it will reappear in the list the next time it's captured or verified.

Tip: Right/control+click on an archive's status. If the "Reveal in Finder" command is disabled, then QRecall can't locate the archive this status belongs to. Either it's off-line or the connection between the status and the archive is broken.

You can find a little more about the status window in Help > QRecall Help > Guide > The Basics > Status Window.

James, thank you for that explanation, it all adds up. And for the hint, which of course resolves the nag bit. May I respond to your 'hint' also with this, a slight 'gripe' which is that searching the help on 'status window' produces nothing useful in this regard.

Of course, reading carefully through the 'The Basics' makes all the sense in the world, and I probably did that long long ago when I first set up QR. But this harried user....well....you know the story.

Thanks again.

Bob Tyson wrote:May I respond to your 'hint' also with this, a slight 'gripe' which is that searching the help on 'status window' produces nothing useful in this regard.

This might be your Spotlight system. A search in my QRecall help window results in two QRecall hits: Monitor Preferences and Status Window, which is exactly what I would expect.

Help indexing is performed by Spotlight, so your spotlight database might not be updating or it's just taking its time.