One of the computers I'm testing QRecall with is an old mid-2007 iMac, running El Capitan 10.11.1. It actually works surprisingly well, although it does tend to bog down a bit when QRecall is doing things while I'm running Windows 10 in a virtual machine, since each of them only gets 2 GB of the total 4 GB installed RAM. I've replaced the spinning hard drive with an SSD, so I assume contention for drive resources probably isn't much of a factor. Because of the slowness, sometimes I put QRecall actions on hold for a while, using the QRecall system menu on the right side of the menubar.

This morning, I had just booted the computer, for the first time in several days, and it had been a week (I think) since I last did any backups. As far as I know, there were no problems with QRecall when I last used it. (This is b20, by the way.) I knew I was going to be downloading and installing a big windows update in the VM, so I went to the QRecall system menu, intending to hold all schedules for a while. I couldn't do it, because both the "Hold All Schedules" and "Resume All Schedule" items were "grayed out". Then I noticed that the bottom item in the menu, below the dividing line below Resume All Schedules, was also grayed out and said "NSMenuItem".

I figured something that should have run at boot time didn't, so I fired up QRecall to see what would happen. After launching QRecall, I checked the system menu, and it was now working correctly. Hold All Schedules was no longer grayed out, and the bottom item was the next action on the schedule. I checked the log file and noticed that QRecall couldn't contact the scheduler and then uninstalled and reinstalled some things:

Monitor 2015-11-13 10:23:23 Minutia Cannot connect to scheduler
QRecall 2015-11-13 10:59:55 Minutia Removed resource link QRecallScheduler
QRecall 2015-11-13 10:59:55 link: /Users/bgiles/Library/Application Support/QRecall/QRecallScheduler
Action 2015-11-13 10:59:55 Minutia Install
Action 2015-11-13 10:59:55 ------- Install finished (00:00)
QRecall 2015-11-13 10:59:55 Installing system components
QRecall 2015-11-13 10:59:55 Minutia Cannot connect to scheduler
QRecall 2015-11-13 10:59:55 Minutia Uninstalling daemon scheduler
QRecall 2015-11-13 10:59:55 Minutia Installed resource link to QRecallScheduler
QRecall 2015-11-13 10:59:55 resource: /Applications/QRecall.app/Contents/Resources/QRecallScheduler
QRecall 2015-11-13 10:59:55 link: /Users/bgiles/Library/Application Support/QRecall/QRecallScheduler
QRecall 2015-11-13 10:59:55 Minutia Installed com.qrecall.scheduler.plist
QRecall 2015-11-13 10:59:55 Path: /Users/bgiles/Library/LaunchAgents/com.qrecall.scheduler.plist
QRecall 2015-11-13 10:59:55 Minutia Installed scheduler
QRecall 2015-11-13 10:59:55 version: 2.0.0b20

At the moment, QRecall is doing a scheduled capture, and everything seems to be working OK. When it finishes, if I have a few moments, I'll reboot and see if the situation repeats. I'll let you know the results, and I'll also send a report.

Bruce,

The problem is that OS X isn't starting the scheduler. You have the scheduler set to run in the background (the "Start and run actions while logged out" scheduler option is checked). Currently, OS X is not starting the scheduler the way it should when you start up. When the monitor can't connect with the scheduler, most of the commands related to the scheduler will be disabled, and the special menu item that displays the next scheduled action is broken.

When you ran QRecall, it saw that the scheduler wasn't running, (redundantly) reinstalled it, and told OS X to immediately start the service. So now the scheduler is running, and the monitor menus all work.

Short-term solution is to uncheck the "Start and run actions when logged out" and the scheduler will get installed as a user agent, which works reliably (knock wood).

I've spent the better part of this week running this problem to ground, and I think I'm really close to a (partial) solution. Details in the release notes of 2.0.0b21...

Bruce Giles wrote:It actually works surprisingly well, although it does tend to bog down a bit when QRecall is doing things while I'm running Windows 10 in a virtual machine, since each of them only gets 2 GB of the total 4 GB installed RAM. I've replaced the spinning hard drive with an SSD, so I assume contention for drive resources probably isn't much of a factor. Because of the slowness, sometimes I put QRecall actions on hold for a while, using the QRecall system menu on the right side of the menubar.

You also might consider adding either "Ignore if Application <Your VM Software> is open" or "Hold if Application <Your VM Software> is open" conditions to the scheduler of your more demanding actions.

James Bucanek wrote:You have the scheduler set to run in the background (the "Start and run actions while logged out" scheduler option is checked).

And there's a good reason why I have it set that way, if only I could remember what it was. Seriously, I think there's a message thread here somewhere about it, but I'm too busy/lazy to go look for it at the moment. As best I can recall, however, it had something to do with unexpected or unwanted behavior by QRecall when I booted a machine which had been turned off for a week. I think maybe it queued up all the actions that should have occurred while the computer was off, and tried to run them all at once, or something like that. The workaround was to turn on the "start and run actions while logged out" option, and not power up the external backup drive until after I had logged in. By that time, QRecall had already determined that the backup drive was offline, and the waiting actions were ignored. Or something like that. Anyway, that was prior to the QRecall 2 betas, so may not even apply any more.

Short-term solution is to uncheck the "Start and run actions when logged out" and the scheduler will get installed as a user agent, which works reliably (knock wood).

I've now done that. Also updated to b21. We'll see how things go...

James Bucanek wrote:You also might consider adding either "Ignore if Application <Your VM Software> is open" or "Hold if Application <Your VM Software> is open" conditions to the scheduler of your more demanding actions.

Ah, good point! I knew QRecall could do things like that (I'm using it to back up my VMs after Fusion quits), but it hadn't occurred to me to try your particular suggestion. I'll do that.

By the way, I won't be constrained by an ancient 2007 iMac at work for much longer. I'm about to place an order for a new 27" iMac for home (with 1 TB SSD), and then the existing 27" Late 2012 model I have at home now (which is still plenty fast) will transfer to work.