Deborah McMillion-Nering wrote:SHould the reindex be this slow?

No. There's an issue with the Reindex command in 1.0.0(46). One of those situations where trying to make things faster actually slows it down.

There are two competing processes (one reading the data and the other updating the index) that cause your hard drive to thrash, dramatically slowing down the reindex process.

You can avoid this problem by first opening the archive package (select the archive icon and choose Show Package Contents from the Right/Control+Click menu). Delete the negative.index file. Now reindex the archive.

A fix for this problem will appear in the next release.

Version 1.0.0(46) will now bring the activity window to the front (assuming it's open) when you choose Window > Bring All to Front in the QRecall application.

Version 1.0.0(46) now ignore users with invalid home directory paths.

This should eliminate the repeated errors you are seeing when constructing capture filters for that user.

Version 1.0.0(46) will now auto-mount volumes using an alias.

See the release notes for details.

Once you upgrade to 1.0.0(46) you will need to update any existing actions to use an alias record by opening the action, re-choosing the same archive, and then saving the action.

Steven M. Alper wrote:You mean like Apple's Address Book's alarm: Repeat in 1 minute; 5 mines, 30 minutes, 1 hour, 1 day, 1 week... etc.? That would be fine, although I think it should be a separate button on the activity d.b. so that you don't have to go through another screen if you really do want to completely cancel at this point.

I was considering two interfaces: If the action was canceled, an additional "Reschedule..." button would appear in the confirmation dialog. Click it and the "Run At..." dialog would appear.

Alternatively, I'm considering adding these kinds of "power user" features to some contextual pop-up menus, rather than cluttering up the core interface. If you right/command+clicked on a running action, "Cancel and Reschedule..." would be one of the options.

Of course, the other way around, if the user left the pause "hanging indefinitely" they'd always have the activity d.b. floating around to remind them.

Assuming they haven't closed it.

Steven M. Alper wrote:1. Could QR play more fairly with the other children? Share the CPUs in a less monopolistic fashion?

That's the job of the operating system. QRecall just does its thing. It's up to the kernel to balance the load amongst multiple processes.

That said, there are number of ways in which QRecall can be less of a burden on system resources. Significant ones have already been done, which you'll see in the next release. Others I'm still experimenting with.

2. Could QR's activity monitor gain a "Pause" button, obviating the need to remember to launch QR and manually start a canceled action?

A "pause" button is interesting, but I'm worried the process could be left hanging indefinitely. What would you think about a "reschedule" button that would appear if you cancel an action?

Steven M. Alper wrote:Although no other app was able to handle the situation, is there perhaps a way to design QR to exit more gracefully in such a situation?

Sadly, no. QRecall (like every other application) is at the mercy of the operating system. If an application makes a system call and that call fails to return, there's nothing—short of killing the process—that can be done about it.

You took the only course of action available.

On my MacBook Pro I do notice that the hard drive is significantly slower than in my desktop machines. A few applications that fly on my G5 seem to crawl on my MBP, even though my MPB has more (CPU) horsepower and just as much RAM. When I put my ear to the MBP, I can hear the drive just trashing about.

I haven't really noticed any slowdown with QRecall because I run my captures at night.

Most performance degradation is due to swapping. The amount of RAM you have can have much more impact on performance than CPU or even drive speed.

Thanks for the update. I'll check into that.

In my defense, I was writing a user manual not a UNIX man page.

I agree that it might be worded better.

You might want to check your NetInfo database. I suspect that a partial user account with a home folder path of "99" still exists.

Internally, QRecall uses the list of defined user accounts to generate a number of programmatically created filters. The "trash" and "cache" filters are two such filters, as there are trash and cache folders relative to every user's home folder. If a user account contains an invalid home path, the filter creation will fail, which is exactly what you're seeing in the log.

Aside from the onslaught of log messages, it shouldn't affect the capture since QRecall simply failed to create an exclusion filter for a bunch of folders that don't exist.

I think a better solution is to simply have the scheduler immediately run all actions that have missed a scheduled run time while the system was shut down.

This would make the behavior of actions during a shut down consistent with sleeping -- and consistency is a good thing.

Frederic Thomas wrote:I *don't* understand why something that is to run at an INTERVAL of ONE day does *not* given the chance one hour too late. Again, my only problem is that what QRecall does not correspond to what I understand in the term INTERVAL.

An Interval schedule simply means that the scheduled run times are determined by fixed time intervals (some number of hours/days/weeks). So if an action is scheduled to run at 12 hour intervals starting at 2:00AM, it would be scheduled to run

Yesterday 2:00AM
Yesterday 2:00PM
Today 2:00AM
Today 2:00PM
Tomorrow 2:00AM
Tomorrow 2:00PM
and so on

If the action ran yesterday at 2:00PM and the computer was shut down at 2:00AM today, that scheduled run time was missed. The next scheduled time will be at 2:00PM Today.

Except for the way that the run times are calculated, an Interval schedule behaves exactly like a Daily schedule.

Note: There's an alarm clock for mac out there that makes the mac wake up from sleep at some time: integrating that in QRecall would be smart. You can even program power on I think...

I'm reluctant to have QRecall arbitrarily change system settings, but I have considered adding certain power management features to actions (i.e. sleep when finished).

Frederic Thomas wrote:Not sure why they did take that long to appear.

I have no idea. But I do know that JForum has a few idiosyncrasies.