Greetings James,

I continue to encounter an error with the beta version 46 (posted today) of QRecall running on OSX 10.7.2. Build 11C71

After my system is booted...I launch QRecall...and kick-off a task from the Actions window. The task goes to a "Running" status in the Actions window...but the Monitor window does not open as expected.

If I then click on Restart Monitor...the Monitor window opens and works fine. It even works fine on subsequent Actions...until you reboot...then I am forced to perform the manual Restart Monitor once again.

I also tried setting the Monitor window to open at QRecall launch...the window does comes up...but after I kick-off an action the Monitor remains dormant and shows no activity...until I do the manual Restart Monitor....then all is Ok.

The Monitor seems to be detached from the other QRecall processes after a boot...but once manually restarted...seems to work fine.

Any ideas?

Gary K. Griffey wrote:If I then click on Restart Monitor...the Monitor window opens and works fine. It even works fine on subsequent Actions...until you reboot...then I am forced to perform the manual Restart Monitor once again.

I've received a couple of similar reports. I still haven't been able to duplicate this problem here, but I have no doubts that it's an inter-process communications change introduced in Lion.

I have a plan to address this, but it didn't make it into the latest release.

Thanks...I just wanted to get an update...

James,

Is there any update on this issue?

I would say that 50% of the time...after I boot my mac...then launch QRecall...open the Action window...and manually kick-off a task...

1) The Action Window does not show the task's status...normally it would say "Running", "waiting", etc.
2) There is no Activity Monitor window opened as expected...(restarting the Activity Monitor window via the menu bar does not restore it either).

Thus, the only way to know if the action that you just kicked-off is running is to open the log window. I also noticed that when Qrecall is in this state...if I open an archive with Finder...and then click Verify...it does not open the Activity Monitor window...it performs the verify with the progress bar within the archive window...normally, when I do this...I can close the archive window and the verify continues as seen through the activity monitor.

I am running 10.7.3 with the latest beta.

Thanks,

GKG

Gary K. Griffey wrote:Is there any update on this issue?

This, and related issues, were addressed in QRecall 1.2.0(53), QRecall 1.2.0(58), and again in QRecall 1.2.0(59).

The changes in 1.2.0(53) should have solved, or at least improved, the monitor window problem that you're describing. I can't fix the communications failures in Lion, but the helper process is now much more aggressive about trying to re-establish a connection with the monitor window. When I start an action manually, ever once in awhile, it does not immediately appear in the activity window. But the action now knows this and retries about every 15 seconds, so after 15-30 seconds it finally appears. My advice is to leave the monitor process alone for a minute or so and see if it catches on.

The status of the actions in the QRecall actions window is not as robust. Basically, if the scheduler's announcement to the application gets lost, the application simply won't update its display until the next announcement arrives. But you could quit and restart QRecall to see if that causes it to catch up.

And please send a diagnostic report. Maybe there's some clue about what's (not) happening in the log.

Report sent...

If there is anything that I can do to assist in recreating this issue, logs, etc., please let me know...

Thanks,

GKG

James,

Yesterday, after sending the report on this issue...I decided to try an experiment.

I simply unchecked the "Start and Run Actions while logged out"...and this issue has, at least so far, completely disappeared.

I have restarted my mac several times and have not seen the issue since. I'm not sure if this helps...but I thought I would share this...

One other question...does deleting the QRecall log from the mac's Console application...then restarting the system and emptying the trash have any deleterious effect on QRecall from that point forward? Sometimes, I like to clean out all the log entries and start fresh.

Thanks,

GKG

Gary K. Griffey wrote:I simply unchecked the "Start and Run Actions while logged out"...and this issue has, at least so far, completely disappeared.

Good, that saves me from posting that I think this might have something to do with the scheduler process running as a system daemon.

One other question...does deleting the QRecall log from the mac's Console application...then restarting the system and emptying the trash have any deleterious effect on QRecall from that point forward?

QRecall won't care in the least.

Of course, I prefer that people not throw away their log files, because there's sometimes diagnostic gold in those mountains of text. But that's just me.

Sometimes, I like to clean out all the log entries and start fresh.

I will note that QRecall has automatic log rotation built in (QRecall > Preferences... > General). You can set it pretty aggressively, up to the point of only keeping one day's worth of log records.

Gary,

I've investigated the problem, but I don't have a solution.

I can tell you what's not happening. When a command process starts, it announces itself by sending a message to all listening processes. This is handled by a OS X framework called the Distributed Notification Center.

In a nutshell, the command says "hey, I'm starting, if anyone wants to monitor my progress you can do so." The monitor process listens for that message, connects with the command, and displays its progress.

On your system, the message sent by the command doesn't always get to the monitor. I filtered your log records down to just those between the monitor process and the commands. Most of the time it works the way it should, like this:

2012-02-21 06:37:47.325 - Monitor process started (pid=190)

2012-02-21 06:47:03.827 Command requested monitoring (pid=403)

2012-02-21 06:47:03.829 Monitor received request for monitoring (pid=190)

2012-02-21 06:50:23.423 Command requested monitoring (pid=406)

2012-02-21 06:50:23.426 Monitor received request for monitoring (pid=190)

2012-02-21 09:21:11.037 Command requested monitoring (pid=1031)

2012-02-21 09:21:11.041 Monitor received request for monitoring (pid=190)

The command announces itself, the monitor receives that announcement within milliseconds, and starts monitoring it.

But for some reason, the announcement sometimes gets lost. This if from the same diagnostic report you sent:

2012-02-23 00:14:54.776 - Monitor process started (pid=195)

2012-02-23 00:15:23.959 Command requested monitoring (pid=235)

2012-02-23 00:16:14.360 Command requested monitoring (pid=242)

2012-02-23 00:16:33.947 Command requested monitoring (pid=235)

Here the commands announce themselves again and again, but the monitor process never receives any announcements. This agrees with the behavior you describe; you start an action, but the monitor window never appears.

I don't see anything unusual about your configuration, nor can I explain why it works sometimes and not others. The only thing I can think of would be to look in the system.log console log to see if there are any messages related to the QRecallMonitor process around the time that the notification wasn't delivered.

I'll report my findings to Apple, but I don't have a fix for this at this time.