I have to say I don’t encounter this as much now. When I do it’s usually because I restarted Kantu (after it stalled) before closing the tab that was open.
1 Like
Hi @admin. Just a quick update on this issue.
When I was reading CSV rows using Play Loop the freeze issue wasn’t so bad. When I switched it from Play Loop to a while / endWhile, the problem got a lot worse (using v4.2.6).
But now some good news. With v5.0.1, the problem seems to be less frequent (or being hopeful, resolved?)
I’m not sure if you applied a fix specific to this issue. But the last 2 days, I’ve read through the following CSV files with zero freezes.
- Jun 4 - 25, 3
- Jun 5 - 18, 43, 14, 14, 5, 30
The above shows that in the last 2 days, I looped through 8 CSV files (each item shows the number of rows per file). Smallest was 3 rows, largest was 43 rows.
Before v5.0.1, I don’t recall a streak this long without any errors. So I’m eager to get feedback from others facing the same issue.
@william19 That is good news! Indeed, V5.0.1 contains some improvements for this issue, but it is not completey resolved. We are still working on it.
1 Like
@TheWhippinpost the issue you mentioned in [Fixed] ipcPromise: onAsk timeout 3000 for cmd "RUN_COMMAND" is probably a side effect of these fixes. That is why it would be great to get a test macro.
I’ve messaged you with links to screencasts.
Unfortunately I have faced the same issue today on V5. Only refresh of the page brought the macro back to life. 
We know that the issue is only partially fixed in V5.0.1. But we plan to have a complete solution this month.
Hi, I have the same issue, after 20 to 30 loops the macro stops without error message, when refreshing the page, the macro starts working again. If it hangs on a pause command, the refreshing on the page doesnt work.
I tried executing a macro with 15 “pause” commands and 38 loops, the macro stopped at loop 26 with no error message, and refreshing the page didnt helped.
Something new here. Now I see a timeout. Not counting. And refresh of the page or pause/resume do not work.
Update on my post from last Jun 5th (post #52). I do get the freezing again. And quite often. I will switch storeEval to excecuteScript_Sandbox where applicable as I think it may help minimize the freezes further (even if not fully resolve it yet).
Meanwhile, thank you for continuing to look at the issue and hopefully a permanent solution is in the horizon
Hi, a potential fixed has been found 
=> Please test the latest UI.Vision V5.0.5.
Technically V5.0.5 is exactly the same as V5.0.3 but with the issue fixed.
@admin For firefox this bug was solved too ?
I do not find any news version of ui.vision oin firefox addons page
Thanks
Thanks @admin. We do several runs in a day where we encounter the freezing so we’ll test with V5.0.5 BETA and provide feedback.
Hi, I hope this will definitely fix the problem, thank you very much for your reactivity and for the way you take care of the users !
Louis
Thank you! Initial test runs show improvement. I’ve been able to run my macro longer than before, though I did have an error output that may point to an additional issue. I think a problem has been solved, but perhaps not all problems that contribute to this behavior. Will continue to monitor…
Seems like this bug actually mutated into [Fixed] ipcPromise: onAsk timeout 3000 for cmd "RUN_COMMAND"
@commensal No, that is something different (I replied in the ipcPromise thread). The error this thread is/was about is if the macro suddenly stops with no error message.
Hi @admin. Thank you once again for the fix. Just want to report that we’ve had ZERO issues related to this particular bug (freezing for no reason) since the release of v5.0.5 last June 19th.
We do several runs a day as explained in this earlier post. So it’s a pretty good test case for this particular scenario.
Seeing that no one else has posted an issue since the release of v5.0.5, it does look like this is finally solved! Thank you again.
I’m kinda curious what the issue was, if you’re willing to share. Keep up the great development work.
Thanks for the great feedback, and thanks again to everyone for their patience while we where hunting down this issue. Overall, it was a collection of several issues which is one of the reasons that made this bug so tricky. And in fact, we are still aware of an rare issue with the OPEN command, and will be working on this, too.
But the key issue was that a random ID was not really random and unique, and so we had sometimes the same inter-process communication ID even when they should have been different.
2 Likes