Following code is leaving a couple of files out:
@async: "C:\Program Files\Mp3tag\Mp3tag.exe "{filepath$}
The first couple of files will be randomly ignored. So if songs 1-14 are used, fo rexample, only 3-14 might arrive in the program. I think, the @sync is supposed to catch some delays, but mostly a couple of files will be left out. Maybe someone has an idea, how to solve this?
I have to add, that this effect won´t show, if some normal folder ist used, containing maybe a dozen or so MP3s, but when a number of files is selected from a folder containing a couple of thousand files. I just tested it & it won´t occur in small folders.
It's almost certainly a bug in Mp3tag.exe.
Lots of programs have bugs like this, where they try to detect multiple instances and forward the command to another instance (so just one instance of the program handles everything), but they do it incorrectly and go wrong if things happen exactly in parallel.
Is there any reason to use @async here? All of the files will end up in a single copy of Mp3tag, which will only process one file at a time, so I don't see much reason not to add the files one at a time.
Oh, ok, then i have to move the files into some smaller folder, then it will work. Why there is that @sync, i don´t know, because this is a button from the other forums, which is part of a planned tutorial targeting MP3 sort of buttons. I found, that the button is also working well if i remove the @sync.
Even if moving the files to a smaller folder seems to make it work, the button will never be completely reliable if a race condition exists in Mp3tag.exe and the button is sending multiple files to Mp3tag.exe in parallel. If the computer is running slowly (e.g. because it's doing lots of other work) one day then the problem might come back.
If you use @sync instead of @async then Opus will wait for each Mp3tag.exe to finish before launching the next one, ensuring the files are sent to it one-at-a-time.
That said, using @sync may cause you a problem: If Mp3tag isn't running initially then Opus will launch it with the first file and then wait for it to exit before running it with the second file.
(If Mp3tag is already running, Opus will launch a second copy of Mp3tag and wait for that copy to exit. That second copy will just send the filename to the first and exit.)
So you might want the button to ensure Mp3tag is running (e.g. by running it without any arguments) and then have a slight delay to give it a chance to start (to ensure it is ready to start receiving filenames*).
(*It is probably there that the bug in Mp3tag exists. If the first copy is still starting up it may not be ready in time to receive filenames passed to it by the subsequent copies. I am just guessing, though, based on the bugs I've encountered in other programs.)