Can anyone help me understand why KM seems to start working incorrectly after a period of time? It seems like I've seen a few other posters ask about something like this before.
In any case, it's weird. Things will be working just fine and then, after a while (a few hours?) certain macros start acting weird, and not working as they should. If I close down KM and then open it again, things go back to working as they should. It's almost like the macros get "worn out" and start to fail after they get "old". I know that doesn't make any sense, but I can't think of any other way to describe it.
I don't have any macros that run over some sort of long period of time. They all run from start to finish in just a few seconds, so it's not like there is some sort of lingering macro running in the background. The same macros can run correctly, dozens of times, but then things will start running incorrectly after a few hours or whatever. It seems so random. Is there some sort of limit on the number of macros that can run before the KM engine needs to be restarted?
I am also using Find Image a LOT. Multiple times a second, just like you.
So what's up with that? What is it about Find Image that would cause this issue, and what is the solution to overcome this? It's really annoying. Everything works, and then, all of a sudden, it starts acting weird and malfunctioning. Is there some kind of cache or something within KM that fills up with found images or something?
The KM engine probably uses a library, which is probably where the fault is occurring. So technically, it is not KM’s fault. Overall, I’m so happy with the product that I don’t worry about this little glitch too much.
For me it's kind of a big deal, as a significant percentage of my overall macro group relies on image recognition. The whole thing hinges on image recognition working reliably. I'd like to find a solution to get this to stop being a problem, if possible.
Do you suppose it's the total number of images that have been searched, since the engine was last started, or simply just the number of images being searched within a relatively short period?
Is restarting the KM engine the only solution you've found?
Yes, restarting the engine is the only solution I have found. And I’m not sure precisely what kind of image searches caused the problem. It could even be something like whether the images are all white or all black or something like that. One thing you could do is watch the amount of ram that the engine takes. When you start the engine, it may start around 50 MB. But the problem probably won’t manifest itself until it reaches 500 MB. I usually reboot when it reaches 500 MB, and it may only take a few hours to reach that size. It should be fairly easy to write a script that reboot the engine if it gets too large. But this script would have to be outside of keyboard maestro because it has to stop ….. and then restart the engine.
Interesting. I'm now realizing that some of the problems I've had at times, while working on this big project I've got going, may have just been a result of the image library we're talking about. If I had known about that, I might not have gone down some of the rabbit holes I've gone down, trying to sort these problems out.
In any case, I wonder if Peter might have some additional insight on this. I suppose you could just set something up to empty that library folder every now and then. Or maybe there's a Terminal command that can be used to increase the total available volume of that library? I know that there is a similar Terminal command that can be used to increase the total number of macros in KM that can run simultaneously. I had to use that command to increase the default of 50 macros to 200 macros. I have a lot of macros firing at the same time.
How did you determine this threshold of 500 mb? Also, are you uploading your search images directly to within KM, or just telling KM to look for these images using a file path? I have mine setup to search for the files found at a file path.
A “library” is code - not a folder - so there really is nothing for us to increase there. Maybe we should ask the architect if he’s using the latest version of the library.
In my experience, 500 MB is when I started to notice KM slow down. It got sluggish before it produced false Find Image results. But now my new M3 iMac computer has 24 GB of ram so I haven’t seen slowdowns recently. But I still restart the engine at least once per day.
It may be code, but it clearly seems that some sort of memory storage threshold is being reached. So it only stands to reason that either the size of that storage would need to be increased or, alternatively, regularly cleared to make room for future image searches. Restarting KM may take care of this problem by clearing out the library as part of the reboot, but I'm wondering if there is a way to automate clearing out the library without having to restart KM.
I don't know of any cases where the engine stops working.
There may be memory or other leaks, especially in the OCR or Screen Searching code, but I have yet to find any or resolve any reliable cases.
Without a reliable way of duplicating the issue it is virtually impossible to know what the issue might be, and whether it is possible to resolve. Any issue could be in Keyboard Maestro code, but just as plausibly it could be in the system somewhere.
If you can find a way of inducing the issue reliably that I can duplicate then I'm happy to look in to it further, but I'm afraid there is little I can do or suggest based solely on it stopping working for you after a while.
That's almost certainly a memory issue. Monitor with Activity Monitor or similar, determine a "comfortable" threshold that will indicate it's time for a restart but won't have you relaunching the Engine every 5 minutes, put in place an method to restart the Engine when that threshold is reached.
Even a notification for you to do it manually would be a good start -- if you find those restarts help you can then look at automating things (while avoiding in progress macros, etc).
I wouldn't necessarily say it quits working altogether. It just gets sluggish, which at some point becomes sluggish enough that it takes longer to do certain actions than the macro is set up to handle.
These macros involve a series of actions with image search and mouse clicks/keyboard presses. All of these actions take place very quickly (< 2 sec, in total). This sluggishness, of course, causes issues with the timing and pauses inside these macros. This causes the macros to fail. So KM is technically still "working", but the macros fail because the timing gets wonky, and mouse clicks happens where they're not supposed to, and things like that.
Up until now, I had assumed that these sort of issues I had been experiencing just came down to some optimization that I needed to do on these macros. But I'm now at the end of those optimization efforts, and realizing that the problem still persists.
I didn't know that memory leakage was a potential issue with image recognition or otherwise in KM. From what I'm reading online, it seems like memory leakage is a problem for a lot of people, with many different apps, and in many different scenarios.
I'll see what I can do about trying to nail down how/when this is happening, and get back to you if I'm able to do so.
In any case, what is the best way to deal with the symptoms, if no cure is available? Sometimes it seems like a full restart of my Mac is necessary to get the macros to perform as intended, and a simple restart of the KM engine is not enough. While I could maybe get okay with the idea of manually (or finding an automated way to do so) restarting the KM engine on an occasional basis, having to fully restart the Mac every hour or two is not really viable.
I will look into this. What would you suggest as a method to monitor and restart the KM engine? I'm not sure how to approach this outside of KM. Does restarting the KM engine release all of that memory? I assume it's supposed to.
Erm... KM? You do need a bit of shell scripting to get the current memory usage, but the biggest problem is how to use the Engine to launch the Engine when you've just quit the Engine... You could farm that out to an external AppleScript app, but using an asynchronous AS action is working in my tests.
I won't guarantee the "multiplier" section, as I've only seen MB-usage -- but it should work if (as I suspect) top use K and G for kilo and giga. I didn't bother with T -- if KME's memory usage is that high then you've other problems to worry about!
Use the "Memory" figure from Activity Monitor to judge the highest amount you want KME to have before a restart, and put that value into the first action. Then just have the macro run every so often, for example on an "every 5 minutes" periodic trigger. If the Engine's memory usage is higher than your stated maximum the macro will pause until no other macros are executing then restart the Engine for you.
This has been hacked together, and I'm sure it could be improved on -- more effort has gone into making it work (and not blow up your Mac!) than in making it efficient/pretty. I look forward to what others suggest.
So I have approximately 120 macros which all interact with one another to control my DAW (Luna). This does image recognition, midi control, and all kinds of other stuff in concert with one another. There is a lot going on. There is a lot of image recognition going on, as well as midi shuffling back and forth.
As a result of all this stuff going on at once, and given the nature of what DAW use typically looks like, there is probably always going to be some sort of macro(s) firing at any given moment. In other words, it's possible that there may not be many opportunities for the KME restart macro that you created to actually find a break in the action to run. How long does your macro take to run, from start to finish? If it's pretty quick, it may not be a big deal.
Either way, I appreciate you putting this macro together. I'm definitely going to give this a try. It's been a bit of a bummer to get to the end of this project, and find out that it may not be as reliable as I'd like it to be because of something like memory leakage.
Run it yourself and find out? My machine is not your machine, so my results will be meaningless to you.
Take the opportunity to contact the DAW's developers and ask them to implement proper automation hooks -- Shortcuts, AppleScript, something -- so you don't have to rely on KM's image detection. Show them what you've managed to achieve without their help, convince them how much better their software would be (how many more sales they would make!) if they made automation easier and more robust.
Oh, many people have asked UA for proper hooks into their DAW (Luna). But it's like talking to a brick wall with them, and they move slowly anyway. So I'm not holding my breath on UA ever getting anything done . So I've just decided to make something on my own.
I definitely intend to try your macro out. I just won't have a chance until tomorrow at the earliest. I was mostly just curious about the rough estimate on time. I mean, I'm guessing it doesn't take a full minute to execute. I'm also guessing it doesn't take 1 second to execute either. If it just takes a few seconds to execute, that probably isn't too big of a workflow interruption for my purposes.
The only bit that matters is the time it takes to kill and relaunch the Keyboard Maestro Engine. Since that's dependent on your machine's speed, what else it's doing at the time, and the number, complexity, and size of your macros -- I can't begin to guess how long it will take.
You've manually quit and relaunched the Engine, according to your OP. It'll take that long, minus the faffing about trying to find the menu item.
I've just realised the macro posted above will break if memory usage includes a decimal point, eg 1.134G. Will that matter? I don't know -- but, just in case, here's a fixed version (post above also updated):
You do need a bit of shell scripting to get the current memory usage, but the biggest problem is how to use the Engine to launch the Engine when you've just quit the Engine... You could farm that out to an external AppleScript app, but using an asynchronous AS action is working in my tests.