Gary,

Please send a diagnostic report and let me know the approximate date/time that this happened. It would also be helpful if you could go into the Console application and see if there are any console message from QRecall around that same time (just enter "QRecall" in the search field, select some relevant messages, copy, and paste it into an e-mail).

Thanks!

Ralph Strauch wrote:I'm trying to search my archive and the search function just isn't responding.

I apologize for the inconvenience. The search feature in the current beta is not working.

See the Known Issues section of the QRecall 1.2.0(35) beta release notes.

Gary K. Griffey wrote:I was just wondering if you were interested in receiving any bug reports for the current QRecall beta running on 10.7 Lion.

Absolutely. The more problem reports I get, the better.

I've been testing QRecall on Lion and have been addressing compatibility issues as I encounter them. Most of these fixes will appear in the next beta. Later this month I'll start regression tests to make sure that QRecall can successfully capture and restore a bootable Lion system, and so on.

If you're really curious, and have nothing better to do, you can open a terminal window and use the iosnoop tool to see what QRecall is up to:

sudo iosnoop

My guess is that when it's stuck, it's writing to the hash_scribble.index file. A bunch of tiny writes to this file indicate that RAM has filled up with newly created (or previously cached) record entries that now must to be written to the disk before any new records can be added. This is probably the most time consuming, and I/O intensive, periodic chore that QRecall has to do. If the archive is on a network volume, this could be even worse (performance wise).

If you're running a virtual machine at the same time, there could also be some good old VM thrashing going on. QRecall bases its table and cache sizes on the physical RAM installed in the machine. There's no rational way to determine what the RAM demands of other processes are, so two or more RAM hungry tasks (which would definately include QRecall) could be fighting for resources.

Bruce Giles wrote:When this happens, is it because QRecall is doing some kind of time-consuming housekeeping in the middle of an archive?

More than likely, this is the case. QRecall maintains an entire menagerie of caches, indexes, and lookup tables. Almost all of which require periodic maintenance. They need to be occasionally collated, sorted, written to disk, and so on. And, as you guessed, quite often this needs to be done at unpredictable times, usually in the middle of capturing some item.

Your system's ratio of RAM to archive size will impact the frequency of this kind of thing a lot. If you have a lot of physical RAM, QRecall will allocate really big caches for many of these tables and indexes. That reduces the frequency that they need to be flushed, sorted, or read again from disk.

If not, do you have any idea what *is* happening?

Sometimes QRecall is just looking for the next thing to capture. QRecall displays the item that it's capturing, but once it's done it goes looking for the next thing to capture. Until it finds the next item, the status line continues to display the previous item. In the future I might change this so that a prolonged scan for the next item is a little more transparent.

Prion wrote:I noticed there was an incomplete layer which I merge with the one that followed. The result was that I now have a more inclusive, larger layer which still is incomplete. I repeated with the next layer, same result. I am not totally sure that it has not been there before the error occurred, it possibly has been without me taking notice.

Diagnosis of this situation is complicated because the layer is an old one. Recent changes in QRecall change why layers are marked as incomplete, and how subsequent captures treat them. I'll explain what's going on, and a couple of scenarios in which this can occur.

A layer can be incomplete for a number of reasons. Typically, it's just because the capture was interrupted and didn't finish. When this happens, the layer is marked as "incomplete." Items lost because of data corruption can also cause a layer to be marked as "incomplete" during the repair process. But the repair is more likely to mark the layer as "damaged," which means the good portions of that layer was reconstructed by the repair, but some items were likely lost.

Since the layer is marked as "incomplete" and not "damaged," let's assume that's exactly what it is. When a layer is incomplete, it just means that QRecall didn't finish the capture, so there are likely items that didn't get captured. The next capture will start over and will recapture any changed items, which will include any of those missed by the incomplete layer.

The first wrinkle is that this is the situation today. Older versions of QRecall were not as good about forcing missed items to be recaptured. They would be recaptured eventually, but it might be weeks before QRecall got back around to them. The newer versions of QRecall are very aggressive and force every item to be scanned (and recaptured, if needed) whenever it's capturing on top of an incomplete layer.

So, today, if you capture an incomplete layer, followed by capturing a complete layer, and then merge those two layers the merged layer will be complete. That's because anything missing from the incomplete layer will have been captured in the subsequent layer. However, if these layers are old that might not be the case.

The second wrinkle is that there may be a bug in QRecall that incorrectly marks a merged layer as incomplete or damaged. Earlier versions of QRecall were too lax about merging incomplete and damaged layers. The resulting merged layer could still be incomplete (or even damaged), yet the layer was marked as whole. Newer versions of QRecall are much more conservative about making sure that merged layer that have inherited any inconsistencies are marked as such. However, I suspect that it's a little too conservative. I've now had two user report where a damaged layer was merged with complete layer which should result in a merged layer without any missing data, yet the merged layer was still marked as "damaged." I'm currently investigating this. The problem doesn't cause any actual data loss, and I prefer QRecall to err on the side of caution, but it still appears to be a bug.

Any ideas what to try next? Ultimately, I am not too worried because the layer is quite old, but I would like to make sure that I have at least one copy of each item inside the incomplete layer that resides in apparently intact layers.

My suggestion is to ignore it. If you have any captures that follow that layer, particularly using a newer version of QRecall, then any items that weren't captured in that layer have most certainly been recaptured in some subsequent layer. You could continue to merge layers until you have a complete layer, but that strikes me as excessive.

Adam Horne wrote:I have a 2TB external HD as my recovery drive. I partitioned this drive into (2) sections with 1TB each. Would there be any problem using QRecall on 1 section and Time Machine on the other?

There shouldn't be any inherent problems, as long as 1GB is sufficient for you backup needs.

Would there be any potential issues?

You could experience performance degradation if QRecall and Time Machine are both copy data to the drive at the same time. So you might want to schedule QRecall to run when Time Machine is normally idle.

Perhaps I'm being a little too cautious, also...

Cautious is good ...

Neil Lee wrote:I just did some AJA speed tests on the drive, and the average write speed was 50+mb/s. Reading, however, was barely 10mb/s.

That's very weird. I don't have any explanation why the Time Capsule would be transferring this slowly, or why the read speed is so much slower than the write speed.

You might try resetting the Time Capsule (via Airport Admin). If it's an external drive, you might also consider plugging it into your Mac to repair the volume, and possibly consider defragmenting it. All just shots in the dark, but sometimes they help.

At any rate, after about 6 hours the restore operation finished (145G of data in total) and everything was exactly as it was. This is the first time I've tried restoring this much data and it's reassuring that QRecall did what it was supposed to.

Well I'm glad it all worked, even if it wasn't as fast as it could have been.

Neil Lee wrote: I launched QRecall and started the restore process. I think there was around 100G of data.

Four hours later, it's barely 1/2 done.

That's slower than I would expect.

That works out to a transfer rate of about 3.5MB/second.

My primary machine is connected to the Time Capsule via ethernet, so I assume it's at least a 100MB connection. It could be gigabyte ethernet, too

As a test, I connected a MacBook via 100Mb ethernet and performed a recall from an Xserve hosted AFP volume. As one would expect, the recall is transferring at about 7-8MB/second. After 1 hour, its recalled about 22GB of data.

I'm not sure if that's the default protocol between the Time Capsule and a 2010 MBP.

3.5MB/second sounds suspiciously like WiFi. That's about the rate you get with a solid 802.11g connection. Are you sure your MacBook Pro isn't connecting to the Time Capsule via WiFi? This has happened to me a number of times with my MacBook Pro (a loose ethernet cable that I never noticed because the laptop switches immediately to WiFi).

Adam,

Good suggestion. I am adding a place in the interface where this would fit perfectly.

Johannes wrote:Just for the records: revealing an item via Service or Spotlight brings up QRecall but not the item. I guess this is related to the not yet implemented search.

It's closely related. Just one of the "many other things" that aren't yet re-implemented.

Johannes wrote:I tried to check the behaviour systematically and all the time, when it "did not work" it was a selection in list or column view somewhere down the hierarchy. So it seems to behave accordingly to your programming. No bug then, but different philosophy than expected

That's a good observation, and I might change how the column view handles this. I was trying to be consistent (read, the application shouldn't do unexpected things) in preserving the current browser path across all views. I didn't think that changing the view should change the folder or volume you were anchored at, nor should it create history.

Apple's Finder has the same problem and they went with the 50/50 solution; the Finder is consistent half the time.

Apple's list view acts just like QRecall's. Expanding and selecting items in subfolder doesn't change the the path of the browser window. If you switch from list to icon view, the icon view shows the top-level items in that folder and any selected sub-items disappear.

Column view is different. The Finder treats selections in a sub-columns as navigation. If you drill three folders into a column view and then switch to the icon view, the icon view shows the folder with the selected items. Also, selecting folders in column view adds steps to the navigation history.

So the Finder takes the approach that expanding folders and selecting items in list view does not constitute navigation, but selecting folders in column view is navigation. It changes the browser window's root path and adds steps to the navigation history.

I have to say that the Finder's approach, while somewhat inconsistent, has merit and wouldn't be terribly difficult to emulate in QRecall.

Johannes,

First, please send a diagnostic report. Then try reindexing the archive. That should fix the problem.

This is an internal error that occurs when the names index has somehow gotten out-of-sync with the actual item names in the archive. Normally (i.e. in the release version), this situation is ignored and will eventually correct itself. The beta version, however, worries about such things and throws an exception.

Johannes wrote:One more suggestion on the path navigation placement:
Place the history arrows and an "up" Button at the left side between layers and browser.

All good suggestions. The UI is still in flux. I've also considered moving the history buttons to the toolbar, make them into keyboard shortcuts, add a column of navigation shortcut buttons to the left margin of the window, or any combination of those things.

So please keep your observations and suggestions coming.

Johannes wrote:The easiest and most user friendly way would be to restrict selection in the time view to one item (or items within on layer).

I also would hate to do that too, for a number of reasons.

I haven't given up on selecting individual historic items in the timeline. I implemented the current method simply because it was consistent with the other views and I knew it wouldn't create any complications. I'd still really like the ability to switch to the time view, zoom through time, pick out an older version of some file, and immediately recall it. I just have to figure out how to do that in a way that doesn't make other things so complicated that people's heads explode.

Too more things:
- I miss a toolbar item for instant recall

Noted

- I would prefer if switching browsers-styles would retain root, selection and layer shading

Whoa, it should be doing that now. If it's not, then that's a bug (or probably five).

When switching between views, the root folder should remain the same and QRecall will attempt to preserve the current selection. Now there are obvious limitations, as some views (like list and column) can select nested sub-items that can't be represented in other views. But at the top level of each view, the selection should be preserved when switching between views. If it's not, please note the circumstances and I'll try to fix the problem.