Sending file paths via command line must be sent twice

Via PowerShell, when running:

& "C:\Program Files\Mp3tag\Mp3tag.exe" /fn:"C:\a.mp3" "C:\b.mp3" "C:\c.mp3"

This only succeeds without fail when Mp3tag is currently closed. If however it is already running with some files having been previously added to its list, running the above command will replace that list but only show a.mp3. The command must be run a second time for the list to now show song a, b, and c.

There are other quirks such as if you only run the command once, and then drag-and-drop different files to the list, the dropped files will be added but also the files that would've been added by a second run of the command. Something isn't right here.

Mp3tag 3.15
Windows 11

I would say that a look at the documentation is missing:

You are leaving out the /add switch.
You need a separate call for each file, each with the /add switch. A list of files is not mentioned.

1 Like

On closer inspection, you're right. However, it's strange that specifying a list of file paths does actually succeed flawlessly when the program isn't running, or on the mentioned command's second run, so it's indeed possible, just not supported which I find a little odd considering what the program does. The confusion arises because sometimes it works and other times not.

I think it's quite typical to call a program once with a list of file paths instead of resorting to calling it multiple times once for each file of interest, so ideally Mp3tag would support this in the future. Maybe with a /replace or /list switch so that no matter if the program is open or closed, what is passed will be what is listed in the UI.

My use case is selecting a bunch of media files in my file manager and sending those to Mp3tag as the files I want to focus on tagging. For now, I will stick to running the command twice, or killing Mp3tag before each run of the script to ensure I get the behaviour I'm looking for. Not ideal, but it works. The other option would be to create a temporary M3U8 playlist containing the desired files and only only that file.

Oh, there is a lengthy thread about calling a program which obviously does not support a list of filenames...

so I am not sure about "typical".

Be it typical or not, i'd argue it should be supported to some extent as attempting to do this does lead to the program appearing broken in some way from a UX perspective, specifically because of it succeeding in some but not all cases when intuitively you'd think it would. Maybe the docs could be more explicit that the program doesn't support passing a list of files.

1 Like