Hi James,

Thanks for your recent advice here: http://forums.qrecall.com/posts/list/768.page#3359

Recently I upgraded to the latest Qrecall version and perhaps co-incidentally my MacBook 12" 2017 has been discharging to 0% battery overnight, it's temperature is hot in the morning and I am not so thrilled about this situation that has happened several times now.

I have no idea if it is directly a result of my Qrecall scripts that run at 3am or if it is entirely co-incidental or unrelated.

Is it possible for you to direct me how to rule out Qrecall as a cause for this issue?

Hopefully attached are useful information

I had a battery discharge even Saturday January 18 and Thursday January 31. Looking at the Qrecall log it doesn't explicitly show any difficult with actions. In fact both days the actions are scheduled at about 3am. you can see the actions completing later in the morning as the MacBook was plugged into power and the dock that contains the backup drive.

Is there anything else to look at to rule out Qrecall

Many thanks,
David

David,

QRecall, like any software, uses energy while it's running and if your laptop isn't connected to A/C your battery will get used.

However, it shouldn't cause it to drain completely. In fact, if you used the capture assistant to create your capture action, QRecall will have added a "Stop if power remaining drops below 20%" condition to your capture action; this is designed to stop a running action once the battery gets too low. If you don't have that condition, consider adding it to your actions that run at night.

Another test is to simply skip all of your QRecall actions for a few, or alternate, nights and see if there's any difference. This can be done by choosing the Hold All Scheduled Until… command and selecting a time tomorrow.

If you want me to look into this further, please send a diagnostic report (Help > Send Report…). It will include a lot of details that aren't visible in the log window.

Thanks James,

to be more specific the battery drain issue is occurring while the MacBook is asleep, in a travel bag, lid closed, and not plugged into power. It is also not plugged into my dock that is connected to the USB backup disk. Thus IFF QR tried to back up while the MacBook was sleeping with the lid closed it would never find the disk

Is it possible, likely, or impossible for QRecall to try to complete a back up while sleeping with the lid closed? Or, would it do that but abort if the disk is not found?

David Cretney wrote:Is it possible, likely, or impossible for QRecall to try to complete a back up while sleeping with the lid closed? Or, would it do that but abort if the disk is not found?

Unless you have "power nap" enabled, nothing at all runs when your laptop lid is closed.

And if the volume containing the archive isn't connected, no QRecall action will accomplish anything. Any action that did start would simply log an error that the archive could not be reached and stop?end of story.

David,

Thanks for sending a diagnostic report. It was just want I needed to determine ...

... QRecall is totally at fault!



So here's what's happening,

You have a capture action set to run at 3:00 each day. That action has a condition that holds the action until the archive volume is attached. So the scheduler starts the action at 3:00 (something that shouldn't be happening because Apple's power nap is not supposed to run third-party software when your laptop is closed, but that's another story), but then immediately places the action on hold.

Now here's what's going wrong. We recently made a change to the scheduler so that it prevents your system from going into idle sleep because a few users were having an issue with actions starting at the same time the computer wanted to go to sleep; the action would start, connect to a file server, then immediately go to sleep, which would result in network errors when the computer woke up again.

In your situation, however, this is a disaster. Once your action starts, the scheduler is now preventing the system from going to sleep since actions are "running." But your capture action isn't really running yet because it's held by a condition. So the laptop stays awake until the battery is dead.

I think I've fixed this and you can try this pre-release of QRecall version 2.1.14: This version only treats actions that have started but are NOT being held as "running", for the purposes of determining if the system should be allowed to go to sleep. If you do try this version, let it run for a few days and then send another diagnostic report.

Another solution that would work with the current version is to remove the "hold while no archive" condition and change the schedule to an event schedule that runs the action when the "archive volume connects". Now, the action won't attempt to start until you connect your external drive. If you connect and disconnect your backup drive once a day, that's all you need to do. If you have occasion to leave the drive connected for more than a day, consider adding a "Repeat again" interval so that capture runs again the next day.

Thanks James for your time. I like the idea of implementing the fix and your description of running when the volume connects also sounds more suitable.

I will probably run the pre-release version for you and monitor if it happens again.

Cheers,
David

Hi James,

I installed QRecall 2.1.14(1) as you provided, about 2-3 days ago. Last night I did not plug in the MacBook and the battery was dead in the morning (Feb 5)! I will submit a report for your review. It would be nice to know if qrecall is still involved in this issue or not.

I will leave unplugged again to see if it happens again and at that time will probably modify the script as you mentioned earlier.

-David

Sorry for the delay in addressing this; it took a little time to reproduce exactly what was happening.

I'm pretty sure this pre-release version will fix it: QRecall 2.1.14(3)

Same drill as before: install 2.1.14(3) and let it run overnight.

Hi James, FYI I sent in another log as the MacBook was drained again this morning...I'm sorry to report.

Good news: we're getting closer

The problem was that you weren't running 2.1.14(3). All of the action logs up to now were still running 2.1.14(1). When you launched QRecall to send this report, that was 2.1.14(3) ... which should now be installed.

I suggest

Launch QRecall again and use QRecall > About QRecall… to verify that you are, indeed, still running 2.1.14(3).

Deleting all other copies of the QRecall application you have lying around. It's OK to keep the installer disk images for earlier versions, as long as they're not open.

Continue running 2.1.14(3) to see if it fixes the problem.

Send another report in about a week if you don't see any problems.