I have multiple export scripts. I export them to this file
C:\Users\MY-USER-NAME\Documents\Mp3tag export list %_DATETIME%.txt
[which I took from this topic Multiple export results at the same time are not available]. This allows me to display multiple export results without the need of leaving the Mp3tag and renaming existing TXT file
Unfortunately when I select from my list of export scripts this one
$getEnv(TEMP)\Send_To_Audacity.vbs
[which I took from this topic Send tracks to Audacity with an export script], my list starts to mess up. Depending on what I will highlight and to what move next with my left click, I either get that $getEnv(TEMP)\Send_To_Audacity.vbs for every export action, or C:\Users\MY-USER-NAME\Documents\Mp3tag export list.txt which is an older version that I was using before getting acquainted with that %_DATETIME% parameter. If I execute export with such malfunctioned name- it gets saved. But if I notice / remember about the glitch and leave the export window [either by clicking Cancel button, clicking the X icon or by pressing Esc key], then the next time I enter my Export window the situation is as it should be [till the time I click than VBS and then click something else, overprinting the its name on other available scripts]
Because the name in the export script overwrites that what you set in the export selection dialogue.
So either you remove the code for the filename from the export script or you add %_datetime% to the filename in the export script code.
You wish; and I wish even more
So I have export actions [thus filenames]
A] with TXT extension that start with [lets say] MUSIC and are followed by wordily description of what they do
B] with TXT extension that start with tag and are followed by the name of a tag field
C] that one VBS script
And I am able to sustain that %_DATETIME% at the end of filenames only for B. Also if I add it to one of the A's , it stays there. But if I add it to a second one from A, the first one it wiped out of it- it reverts to its previous name
So this shows me that it is not only the problem with that one VBS [which I did not notice earlier]. And of course question arises: how is that possible? Why do B's are remembered and I can jump between them- but other entries mess things up?
I think I already explained it.
So now you would have to show us the export scripts to find your problems.
That vbs-script, BTW, is also a plain export script only that is also has text in it that can be interpreted by visual basic. Just like csv exports that are interpreted by e.g. Excel or html exports that are interpreted by browsers.
The principal source stays the same: a script that is generated by Mp3tag with text constants and variables.
I do not now what exactly is happening. But I can report what I have ruled out:
''#'' in the name of the export action being a culprit
some other other punctuation signs being a culprit
some leftovers from my manual updates [I have removed exiting scripts and created them from scratch with different names]
actually using a script and not just selecting it
And now, this is the overall issue: sometimes Mp3tag takes notice of the first line of the code of a given export actions- and changes the data in the Export File Name box; while sometimes it does not. Or I would rather say not sometimes for some of the actions
But I just cannot find a pattern. Before that suggestion
put at the beginning. Result: only my B's retained the %_DATETIME% in that box [unless A was selected], while A's were loosing it. Except for one A that looked just like all of the other A's
Now I have put to all of my A's
and yet they also retain in the box that %_DATETIME%. I can even jump to that VBS, the select some B and see that the box was overwritten with $getEnv(TEMP)\Send_To_Audacity.vbs. But when I click cancel and then once again evoke the window of the export actions- my B's have the %_DATETIME% in theirs filename in the box]
This does not make sense. Why are not my A's not overwritten any the first lines of my B's? [But I do not care anymore- this is giving me a headache and I have now the solution: the ``$filename(X:\Any Path\To\some folder\something - %_DATETIME%.txt,utf-8) in my A's]
I just cannot believe it...
It seems that this issue comes down to this:
if the code has $filename [written in lower case letters] then it cannot be overwritten with the filename of previously selected export action - but if the code has $FILENAME [written in capital] then it's path will be overwritten
Is this a bug or what?
I can't confirm that.
If you have set a fixed (fully qualified) filename then the export is created with this filename, regardless, what you have set in the export selection dialogue.
If you have set no filename but a type (e.g. csv) then the filename is taken from the export selection dialogue but the extension is replaced with that of the type.
If you leave out everything except the data format, then the filename is taken from the export selection dialogue.
The export selection dialogue remembers the last name that has been used.
So please check your export scripts and whether they have a specification of some kind as this is most likely the cause for the