Hi,

I decided to start test driving QRecall 3.0 beta yesterday. All seemed to be fine until I realized just now that one of my archives using event-based capturing schedule--to run when "capture items change" with a 3 min. delay to be exact--had not run since QR 3 beta was installed.

What I have tried so far:

1. A manual run from the action window that went smoothly--no difference.

2. Reboot my system--no difference.

3. Tweaked the scheduling details a little bit (from 3 min. delay to 5 min. delay) -- still no go.

4. Tweaked the scheduling details some more, this time removing the "ignore new events for 20 min." restriction -- still no difference.

5. Tweaked the scheduling details again by re-selecting the target archive and the "item to capture" and changing the delay back to 3min -- still no difference.

After each step above, some files on the backup source (the drive selected as the "item to capture") were changed to make sure new file change events were triggered. One of my cloud sync tools (Syncovery) also works on file-change events-based scheduling, and it sync'ed all the changes dutifully.

More details about my system:

I'm running QR 3.0 beta v.74 on a hackingtosh desktop on freshly installed (not upgraded) Mac OS 12.1. QR version 2.2 was installed first before upgrading to 3.0 B74. QR2 has been working on the system for years. With QR2 and now QR3 beta I have two active archives. The other one is on time-based capturing schedule (every 6 hours) and is working uneventfully.

Thanks for listening.

Sorry to hear you're having problems with the beta.

The first thing to try is to open the action and remove, and then re-add, all of the items to capture. Then save the action and see if that helps.

The location of the items to capture are stored as bookmarks, and it's possible those they were out-of-date. Removing and re-adding them will create new bookmarks.

Also, send a diagnostic report. (Open the QRecall application and choose Help > Send Report). This will upload your recent log records so we can examine them. These records contain a lot of low-level details about the scheduler and change events.

Doh! How come I didn't think of making a new action. Silly me. I thought what I did in step 5 above (re-selecting the backup source and the target archive) would be the same. Apparently it isn't. After removing the old action and made a new one, RB3 does capture following file changes. Thank you!

I might have run into another bug, though, while making the new action: the details of the schedule--specifically the length of the delay and the length RB should ignore new events after a capture run--don't always stick.

E.g., the last thing I did before sending in the diagnostic report was to change the delay from 3 min. to 5 min. and to ask RB to ignore new events for 20 min. The second change was kept while the first one was ignored. The delay remains 3 min.

One minor suggestion, if I may: please consider adding a set of "Save/Cancel" buttons to the action settings dialog. Having to close the window before being offered an opportunity to save the settings feel odd.

Thanks

Ming-Li Wang wrote:One minor suggestion, if I may: please consider adding a set of "Save/Cancel" buttons to the action settings dialog. Having to close the window before being offered an opportunity to save the settings feel odd.

An action document window, which you get if you open the action from the Actions window or by choosing "Edit in Separate Window", is a standard macOS document window. Changes aren't saved until you choose File > Save, or try to close the window without first saving it.

QRecall's UI became a little more complicated (read "inconsistent") when action documents were added to the sidebar in the archive window. Since the "Save" command doesn't apply to an archive document, and the sidebar can show multiple action documents at once, the "hack" was to add individual "Save" and "Revert" buttons to the sidebar interface?equivalent to the standard File > Save and File > Revert commands.

So while I appreciate the confusion, I'm reluctant to add yet another layer of non-standard window behavior when the action is being edited in its own window.