[F] _FILENAME is case-sensitive in column configuration

In the Column management window you can use both both "%_filename" and "%_FILENAME%" for "Value" and "Sort By", but if you use "%_FILENAME%" for "Field" then it gets blocked- you can no longer change the name of the file in the main window. But you can change the TITLE and then copy it to the _FILENAME with action. So at the same time it is blocked and it is not

And also it does not matter if you put "%_FILENAME_EXT%" or "%_filename_ext%"- they both work the same 100%. So you can have a settings of Columns where changing of the filename is blocked via the "%_FILENAME% but is not restricted via the "%_FILENAME_EXT%". So this is either merely an inconsistency or an obvious bug. [If it was to me, I would deem such blocking of edition of "%_FILENAME" a bug]

And also there is some kind of strange bug. When I started to temper with using small and big letters for those two variant [of showing and sorting of filename or of filename and its extensions] I got a box with an error every time I entered the Columns management window. But that message box displayed nothing: it was empty, only with the OK button. Or was it without even the OK button? I do not remember now: but for sure it had no text and had a form of a small square or almost a square. It showed itself also every time I chose the entry bearing my "%_FILENAME%". But that buggy message did not appear at the very beginning of my tests with those values but only some time [steps] later. I am also unable to repeat its appearance now, but back then it was coming back every time I was using the "%_FILENAME" for "Field" and going away after switching to "%_filename". And then it just stuck itself, no matter what I was using. But it finally disappeared when I used "%_filename" for "Field" and closed and reopened the whole Mp3tag [and not just the Columns management window]. [And just to be sure that this bug did not hide along itself for the ride, I restored my settings from a copy]

[And if you are wondering, what do I need capital letters for inside the %%- for visibility. As there are no colors in Mp3tag, reading long scripts can be hard and generate errors. But sticking to a simple rule that all tag fields and those system information kept inside %% are to be in CAPITALS, makes a very helpful difference]

You do not run into problems if you use the names as supplied by the menu that can be opened with the arrow button next to the input box.

Yet, I find it puzzling that the field name input is case sensitive.

This is another inconsistency at least. In that one content works no matter how is written and the other similar only when it is in CAPITALS

And also it is inconsistent on the account that Mp3tag under Options > Tag Panel > Tag Panel> Add field... > Field shows the user what is written in capitals [you can write "_filename" but you will see "_FILENAME"]- but the same Mp3tag punishes the user for using capitals somewhere else by a showcase of buggy behavior

I kindly ask you to read 1.) About the Bug Reports category and 2.) the Community FAQ.

As explained in 1.), your bug report being marked as [C] means that it's a confirmed bug report and that I'll fix the issue in one of the upcoming versions.

Please make sure that you're improving the discussion with our posts.

I was only replaying to what @ohrenkino wrote as I might have been interpreted as @ohrenkino not viewing this behavior as a bug; and the same time I was giving a further context to why this should be viewed as a bug

And to add more info, that might save you sometime when trying out to figure this bug out, I will quote the https://docs.mp3tag.de/customization/file-list:

This field is optional. The placeholder of this field is used for editing the content of the field through the file view - if this field is empty, the column is write protected.
You can only use placeholders for tag fields (e.g. %artist%), %_filename_ext%, or %_filename% here.

So it seems that Columns do see %_filename% but are blind to %_FILENAME% - thus treating such capitalized Field as empty thus protecting it from writing

This is now fixed with Mp3tag v2.86b. Thanks for reporting!

1 Like

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