Action Groups list display load time

Currently, if the user have actions grouped [thus have sub-menus with actions], the user must wait a split second before the list of actions is revealed

I see no benefit in that at all. Such hold up is counter productive, when you need to apply more than one action to a file from some of the sub-menus; especially when I am looking for the right one, no remembering where exactly have I put it. Yes, the pause is minimal- but when multiplied, all of them become simply annoying

If that split of a second is needed for Mp3tag to read the content of C:\Program Files (x86)\Mp3tag\data\actions, then OK- let it take the time needed for it to read it; the very first time. But then, save that list of actions [MTA files] to some simple temporary file- and load it [hopefully the second and every next time] immediately.

Or to improve it even better- let Mp3tag create that temporary list the moment it is opened, not waiting for the user to go into Actions drop down list icon

I doubt that this is such a good idea as it limits MP3tag to a list of actions that is there when the menu is opened for the first time during a session.
As this forum also supplies readymade actions for download (mta files), these imported actions would not be visible until the next restart of MP3tag.
I would consider a program restart much more user-unfriendly for this purpose than to wait a very short time while MP3tag reads the action folder.

PS: Looking at the topic: Shouldn't it be a decrease in time? An increase is even longer than the current implementation.

And it would be a big problem to adjust such temporary list every time an action is added / renamed?

Every time Actions icon is clicked, a reload / recreation of such list could occur

Yes; I reworked it

I think that this fairly accurately describes the current implementation: every time the actions menu is called, the list of actions is updated.
So i would say that the request is already reality.

There is a small but relevant difference in what @Zerow is describing (to my understanding): the list should only get updated when the actions icon is pressed, not when the actions menu ist triggered via the small arrow next to the icon.

While I can understand the suggestion, I see one important drawback with this: consistency. Updating the menu only in certain situations (e.g., icon click, not menu click) could result in inconsistent display state — i.e., after an action is deleted in the file system and the icon hasn't been clicked yet, the drop-down menu still shows the already deleted item.

Just out of curiosity: experiencing a slow-down like you're describing, requires are fairly large amount of actions. If you could reduce the amount of actions (e.g., move unused ones to some kind of archive folder) the delay would most likely be reduced.


You have nailed it

Is it the number of actions o their content or both that slows down Mp3tag?

I have ~165 action groups. Most of them perform one task [like adding a specific GENRE]. But one invaluable consists of 74 steps while the other of 233 steps. But here is whats interesting: these two big ones are in the "main menu"- and the main menu of action groups [the first list containing the sub-menus] always loads up immediately. This main menu also has the most of groups and actions; over 50 items all together. But various sub-menus have something like 10, 15, 20 and 40

So how is it that 50+ items [with summary of ~400 actions / steps] loads up immediately, while some sub-menu with 10 single-action items has a delay? But yes- I can see a difference between a sub-menu with 10 and with 20 [the abundant ones take more time]

Unfortunately those actions I do no use are only some old temporary ones- something like 2-3 of them, that eventually I get rid of. All of the rest is what I need to make my workflow easier and less erroneous

After going thorough many upgrades of Mp3tag and going from Windows 7 to Windows 10, that slight difference is still present and noticeable:

the load up of main list of actions is immediate, while the load up sub-menus within it [containing much less data] is delayed

see this external link on the delay for submenus:

1 Like

Thank you

This is exactly the issue- which as it comes out, has nothing to do with Mp3tag alone

Based on that tutorial I wrote a Registry hack, and contained an explanation it in

Windows Registry Editor Version 5.00

; The numbers are the milliseconds needed for a the sub-menus to be shown in various pieces of software;
; The default value is 400, which is equal to 0.4 seconds
; After a change a reset of the system is required or a sign out & sign it

[HKEY_CURRENT_USER\Control Panel\Desktop]

After tests I have chosen 0.1 second to be my delay [which is used in that hack above]. Because lesser number [e.g. 50 miliseconds] makes the menus to me look weird, as if they were speeding on drugs