v5.49 - Feedback

[md_sgf]

But if you decide to change the macro's name later... it would be a nightmare searching in all the macros for all the reffering links.

Unless you used a global variable containing the macro name, within all such Macro Run actions. Then if you change name of macro, just change this variable also
--> DONE

 

[GamBIT]

Dear Developer, there's one other bug that bothers me often enough.
If to change a name for a dictionary that is used in the App Foreground constraint (containing a list of apps), the dictionary's name would not be changed at the constraint, while at the other places of the macros its name is changed as it would.
This leads to the broken macro logic after changing.
Please fix it in the next beta if you can.

Have you tried other automation apps? Such as Tasker, Automagic, E-Robot.

No, but I like this one. And wanna make it better. So I suggest many items I miss for (features request) and show the investigated bugs I bump into.

 

[huashimacro]

What i meant was maybe the original triggers (in the original macro) are partially corrupted. So, see if recreating the original triggers in the original macro, and then try to copy them again, eliminates this issue.

Okay, thank you very much for your work. I've been using the original macros and the floating button has mysteriously disappeared, but it suddenly started working again today after I deleted some other cloned macros. I'm not entirely clear on the specific reason, but I don't recall encountering any such issues with the version prior to 5.49.5. These problems have occurred multiple times in the versions after that, so there might still be some bugs. I will provide feedback if I find the cause of the issue and can reproduce it.

Also, my phone usually experiences some minor glitches, such as the screen content trigger not activating occasionally, and the proximity sensor trigger not activating occasionally. These accessibility permissions have been granted, and I've already set the power-saving mode to unlimited, yet these issues still occur. When this happens, if I close the software and reopen it, or turn off and then restart the macro, the screen content trigger or the proximity sensor trigger will start working. I'm quite puzzled by this.

Additionally, the last time with the variable change trigger, when there were a large number of millisecond-level variable changes in an instant, the logs recorded them, but the variable change trigger could not detect and activate them. The system log trigger also deals with a large number of instant logs, but it does not detect the specified content and activate it either. However, I've noticed that on phones with a newer Snapdragon CPU, there is a certain chance of success with the variable change trigger, but it's not very high. On the older Snapdragon CPUs from a few years ago, with a large number of changes to the same variable information in an instant, there is almost no possibility of the variable change trigger being activated. It might be that the phone's processor is not fast enough to handle the information, which could be one reason for this issue. But all changes are logged; it's just that the trigger doesn't detect and activate them. I wonder if there could be a better solution to resolve this problem?

 

[MacroDroidDev]

Dear Developer, there's one other bug that bothers me often enough.
If to change a name for a dictionary that is used in the App Foreground constraint (containing a list of apps), the dictionary's name would not be changed at the constraint, while at the other places of the macros its name is changed as it would.
This leads to the broken macro logic after changing.
Please fix it in the next beta if you can.


No, but I like this one. And wanna make it better. So I suggest many items I miss for (features request) and show the investigated bugs I bump into.

Dear @GamBIT once again thanks for reporting this bug, but can I please implore you to simply use the report a bug feature in the troubleshooting section of the app to report such issues.

This is a very minor issue that has existed in the app for years and the fix is trivial. If it gets reported via the desired mechansim I will most likely fix it within hours of receiving it and it will automatically go into the next build whatever that is.

Unfortunately these beta threads are starting to stray from their useful purpose and are getting full of too much noise. At the moment I am stuck in some kind of paralysis state as I hate to push a release to production while I know of one or more bugs are present. I end up fixing one minor issue and then another pops up. The reality is the app is full of small bugs like this and I need to just draw a line and push to production and then fix the next set of bugs for the next release.

Reporting the bug here or there might not seem like a major difference, but I have so much noise to deal with (you don't see the email support levels I deal with) that the difference between getting bug reports properly or not is the difference between me functioning and collapsing under the load. So many issues reported are very complex to understand and might be specific to device types or OS versions, so I can easily spend every hour of the day debugging and responding if I don't draw a line somewhere.

Thanks for your understanding.

 

[GamBIT]

By the way, I have found that the problem of dictionary renaming is now and for calling the action block too, if to point the global dictionary as an input/output variable (parameter) for the action block - the dictionary name isn't changed while the global dictionary is renamed. So the macro is broken. The same for the App Foreground constraint.
I think the problem may be very old and is not specific for my very standard device. Motorola Edge X30. I don't see any sense of recreating with the testing macro since it is easily recreated. And I wonder why nobody has noticed it earlier. Maybe somebody has already sent you such a bug report, but it was lost in tons of such e-mails?
But it also may be the recent problem because it happens very frequent when you do smth with MD, and then smth that was running well becomes faulty. So it may concern to the beta too.

 

[Marcelluss]

If I export a macro from version 5.49 and try to import or edit it in an earlier version, I encounter an error, and MacroDroid crashes when attempting to edit the macro. I also see this error in the log, both when importing or trying to perform an auto-backup: 'java.lang.ArrayIndexOutOfBoundsException: length=10; index=10.

 

[Endercraft]

If I export a macro from version 5.49 and try to import or edit it in an earlier version, I encounter an error, and MacroDroid crashes when attempting to edit the macro. I also see this error in the log, both when importing or trying to perform an auto-backup: 'java.lang.ArrayIndexOutOfBoundsException: length=10; index=10.

This is an older version, so not sure what this is doing here. Anyway, this likely means that you are using a feature that recently got an option added and that you used this option, which makes the macro invalid for previous versions. If the handling is not done correctly in these versions, then the app will crash or hang.

 

[md_sgf]

No, but I like this one. And wanna make it better. So I suggest many items I miss for (features request) and show the investigated bugs I bump into.

I meant not to switch to one of those apps, but to outsource just the function of Sensor Light Trigger to.

 

[GamBIT]

I meant not to switch to one of those apps, but to outsource just the function of Sensor Light Trigger to.

I've made it in another way with endless loop (10s) and light condition checking. Also I've left that sensor light triggers to help the main loop, but do not count on them. Using the 3-party apps for a part of the macro I found not easy way, having its own difficulties and possible problems and lags. I'll check if the Developer would report of some sensor light engagements, to test its stability. There's some other way do avoid the problem - creating the secondary macro that reads the luxes to the variable each several seconds, and later using this var as a trigger to the main macro instead of the standard Sensor Light Trigger. But it will lead to the looped readings with the macro anyway.
By the way, I have found that there some similar problems with stability of the condition 'Macro invoked by - Test actions, Test macro'. If I press to test the macro, it may see that fact in 'If Condition' action. Or not to see. To see or not to see - that is a question! (c)

 

[LinerSeven]

I've made it in another way with endless loop (10s) and light condition checking. Also I've left that sensor light triggers to help the main loop, but do not count on them. Using the 3-party apps for a part of the macro I found not easy way, having its own difficulties and possible problems and lags. I'll check if the Developer would report of some sensor light engagements, to test its stability. There's some other way do avoid the problem - creating the secondary macro that reads the luxes to the variable each several seconds, and later using this var as a trigger to the main macro instead of the standard Sensor Light Trigger. But it will lead to the looped readings with the macro anyway.
By the way, I have found that there some similar problems with stability of the condition 'Macro invoked by - Test actions, Test macro'. If I press to test the macro, it may see that fact in 'If Condition' action. Or not to see. To see or not to see - that is a question! (c)

Hi, @GamBIT,

As this is a feedback thread, could you please conduct verification and discussion in separate thread, and provide feedback with some organised content?

I would like summary of topic. (I can't fully trace this thread...)

Best Regards,
Liner Seven

 

[md_sgf]

By the way, I have found that there some similar problems with stability of the condition 'Macro invoked by - Test actions, Test macro'. If I press to test the macro, it may see that fact in 'If Condition' action. Or not to see. To see or not to see - that is a question! (c)

Well I'm happy i asked dev to add these 2 conditions, but they need to work properly. I'm not sure i follow. These seem to work reliably for me.

 

[GamBIT]

I promised to show the great problem with the preview of the big/huge macros in the Macros layout if the option 'Show macro details' is on.
Here is an example of the big macro you can import and then click 'Show macro details' to on. I did a big work to clean this macro out of the references to make it openable as standalone.
(!!!) I warn that if this macro would be at the Macros page visible, MD would be freezed and stuck Immediately if the option is on. So you better first disable the option if you've got it on, open the macro to look into if interesting, and only then click 'Show macro details' to watch what will happen.
If the 'Show macro details' is off, everything goes well, the macro is being edited with no problems. And is saved fast enough due to its size. I don't know that does exactly do MD when is looking into the macro for preview, but it is knocked out. As a rule, I do the phone's restart at this situation since MD would not run properly anymore after this.
I ask Dev to find out why MD behaves so.

 

[md_sgf]

I promised to show the great problem with the preview of the big/huge macros in the Macros layout if the option 'Show macro details' is on.
Here is an example of the big macro you can import and then click 'Show macro details' to on. I did a big work to clean this macro out of the references to make it openable as standalone.
(!!!) I warn that if this macro would be at the Macros page visible, MD would be freezed and stuck Immediately if the option is on. So you better first disable the option if you've got it on, open the macro to look into if interesting, and only then click 'Show macro details' to watch what will happen.
If the 'Show macro details' is off, everything goes well, the macro is being edited with no problems. And is saved fast enough due to its size. I don't know that does exactly do MD when is looking into the macro for preview, but it is knocked out. As a rule, I do the phone's restart at this situation since MD would not run properly anymore after this.
I ask Dev to find out why MD behaves so.

Yes, MD crashes when i either scroll down to your macro, or search for it. I recall having this same issue a year or so before. Probably also with a big macro.

 

[md_sgf]

I promised to show the great problem with the preview of the big/huge macros in the Macros layout if the option 'Show macro details' is on.
Here is an example of the big macro you can import and then click 'Show macro details' to on. I did a big work to clean this macro out of the references to make it openable as standalone.
(!!!) I warn that if this macro would be at the Macros page visible, MD would be freezed and stuck Immediately if the option is on. So you better first disable the option if you've got it on, open the macro to look into if interesting, and only then click 'Show macro details' to watch what will happen.
If the 'Show macro details' is off, everything goes well, the macro is being edited with no problems. And is saved fast enough due to its size. I don't know that does exactly do MD when is looking into the macro for preview, but it is knocked out. As a rule, I do the phone's restart at this situation since MD would not run properly anymore after this.
I ask Dev to find out why MD behaves so.

I now realize this mammoth macro is about (a conservative estimate) x100 times bigger than a normal macro
When I collapsed all blocks 1-by-1 (which took about 10 minutes , as almost all were expanded probably so can search) it still crashed MD.
What about splitting it up? Maybe using 2 or 3 separate smaller macros might fix this issue. Your macro is 2.6 MB (which includes all the called action blocks), so try to maybe get under 1 MB per macro?. It seems that just under 1 MB the macro starts causing lagging issues in MD, and then some size above ~1 MB it starts crashing. I suspect it's related to the Action Block calls (as they need to be searched also, when in Macros screen). I suspect if you replaced all Action Block calls with Macro calls, this would fix this issue, but am not certain. Although it's not a practical solution, just my theory.

 

[GamBIT]

I now realize this mammoth macro is about (a conservative estimate) x100 times bigger than a normal macro
When I collapsed all blocks 1-by-1 (which took about 10 minutes , as almost all were expanded probably so can search) it still crashed MD.
What about splitting it up? Maybe using 2 or 3 separate smaller macros might fix this issue. Your macro is 2.6 MB, so try to maybe get under 1 MB per macro?

It has been about twice reduced! And deleted many actions referred to vars, blocks, etc to make it savable. Anyway I can easily navigate in it since it has a logical structure, loops as a rolling blocks, etc.
I wanted to show to Dev that despite the huge macro is operated and edited well, the details preview leads to the crash, so MD has some mistake in this feature.
p.s. any macro may be easy rolled with find/search string. just do searching, but do not type in it, simply click on <> or ><. In a rolled state this macro is tiny. Click again and see all its size.
By the way, if MD is trying to export this macro as a picture, it crashes anyway. Pic limits, I guess...

 

[Endercraft]

I now realize this mammoth macro is about (a conservative estimate) x100 times bigger than a normal macro
When I collapsed all blocks 1-by-1 (which took about 10 minutes , as almost all were expanded probably so can search) it still crashed MD.
What about splitting it up? Maybe using 2 or 3 separate smaller macros might fix this issue. Your macro is 2.6 MB (which includes all the called action blocks), so try to maybe get under 1 MB per macro?. It seems that just under 1 MB the macro starts causing lagging issues in MD, and then some size above ~1 MB it starts crashing. I suspect it's related to the Action Block calls (as they need to be searched also, when in Macros screen). I suspect if you replaced all Action Block calls with Macro calls, this would fix this issue, but am not certain. Although it's not a practical solution, just my theory.

The funny thing is that the actual macro likely comes closer to ~100kb, because the export isn't optimized at all and ends up with a lot of fields that are unused depending on trigger/action/constraint configuration or not properly cleaned up. Even then I'm surprised you end up with such a big size, no wonder the app is crashing (probably doesn't have enough memory).

 

[GamBIT]

The funny thing is that the actual macro likely comes closer to ~100kb, because the export isn't optimized at all and ends up with a lot of fields that are unused depending on trigger/action/constraint configuration or not properly cleaned up. Even then I'm surprised you end up with such a big size, no wonder the app is crashing (probably doesn't have enough memory).

Since I have understood that the crashes were interconnected with the 'Show macro details' and switched it off, nothing wrong is happened. The only thing is the macro always saved a little bit longer then the usual small macros. It is running well and fast. MD is able to have a deal with the big macros, except 'Show macro details' feature.
Actually I do not understand the reason for 'Show macro details' to be existed, what kind of good is made it for. But if a user has it enabled, MD will crash if meet such a macro being imported.
A lack of memory or size limit is only when exporting the macro as a picture.
Its content now is not actual as I have wiped a lot making it savable after you load. MD doesn't allow to save if where are any wrong things as not existed other macros, blocks, etc. So don't judge on its functionality and format. Else I would have to send all the project of about 50 macros )))

 

[LinerSeven]

Hi, @GamBIT ,

You should send a macro list to the developer, as your topic is repetitive without the 'probable information' that will eventually become the foundation.

Macros do not need to be retrieved individually.

See capture below:






I would be happy too if you would respond.

Regards,
Liner Seven,

 

[GamBIT]

Of course I know about mdr, but don't think it would be a good idea to send the whole project. Just only to show that MD would crash on one macro, that I've sent. I'm preparing to publish the new version soon, so everybody would be able to download the project if he/she wants, there are many interesting things I guess. I'm waiting now for 5.50 official release.

 

[md_sgf]

When I collapsed all blocks 1-by-1 (which took about 10 minutes , as almost all were expanded probably so can search)

p.s. any macro may be easy rolled with find/search string. just do searching, but do not type in it, simply click on <> or ><. In a rolled state this macro is tiny. Click again and see all its size.

Somehow I didn’t realize that was there!
But now I know!