Export filename changes by itself

#1

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]

Send tracks to Audacity with an export script
An efficient / quick way to make playlist of looped files - or some alternative?
Multiple export results at the same time are not available
#2

I don't understand.
Where do you see the MP3tag bug?
The

is exactly that what is coded in the export script.
If you want to set the name yourself, remove the code from the export script.

#3

The bug is: I constantly loose the %_DATETIME% parameter

I add it to my TXT scripts and it is there. But the minute I select that VBS it dissapears. Why should VBS script affect my TXT scripts?

#4

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.

1 Like
#5

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?

#6

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.

1 Like
#7

I suggest that you start every export script with a line in this form:
$filename(X:\Any Path\To\some folder\something - %_DATETIME%.txt,utf-8)

If such a line is not included, then the export filename for a newly selected script will be whatever was last used, unless manually changed.

If that doesn't help, then take ohrenkino's advice and give an explicit example that illustrates your problem.

2 Likes
#8

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

I had everywhere [except for that one VBS script]

$filename(X:\Any Path\To\some folder\something.txt,utf-8)

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

$filename(X:\Any Path\To\some folder\something - %_DATETIME%.txt,utf-8)

and they retain it. But the B's still have the old

$filename(X:\Any Path\To\some folder\something.txt,utf-8)

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]

#9

Of if you shorten that to
$filename(,utf-8)
Then you can enter the filename for each export separately.

#10

And with such change the problem still occurs- the path from the box gets carried over onto other export actions; thus I loose that individual path

A mess, simply a mess

#11

No

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?

#12

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

#13

THis may be a strange and unintended behaviour (which I could reproduce).
(BTW: all the examples that you supplied did not show that)

1 Like
#14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.