Wrong Import with Multi-Value Field

bug-fixed

#1

BUG: Wrong Import with Multi-Value Field

I'm using two Actions to export and import what I call Preferences fields, which include fields such as:
Genre, all types of Ratings, Mood, Occasion and Keywords.
Some of the those fields are Multi-Value: Genre, Mood, Occasion, Keywords

I'm not doing this directly through the Export Menu and the Command to Import Text File to Tags.

I detected the problem by chance, because it's hard to detect, but then tested it carefully in this
SITUATION:

  1. Field: Genre
  2. Current Value="New Age\\Chill-out"
  3. Imported Value="New Age"

PROBLEM (Bug):
Since the first value is the same, it doesn't do anything, leaving the field as is, and therefore not removing the second value (Chill-out) as it should.
It only happens when trying to import only one value. If importing at least two values, even if they already exist, it will clear the remaining values correctly.
So my guess is that it has to do with the presence of the split character: if there is one, everything works fine, if there is none, it fails in this particular case.

TURNAROUND
Remove the fields before importing them.
However this is only doable in a practical way if you're using an Action, like I am. If you are doing this directly, it's not very easy or practical, because not all values might be updated and you don't know which ones will be.

FURTHER HELP:
If you want, I can send you both my Export and Import actions, along with the export file and some empty FLAC files where I tried this.

I consider the consequences of this bug very tough to find (and that's the main concern about it), although it's not critical.

It's never too much to say: Thank you Florian, for producing this great piece of software. :slight_smile:
[Edit: corrected a few "typos" and omitted words]


Natural Mixed Case and Natural MixedLower Case
#2

How to test for a multi-value tag-field ...

$if($neql($meta(GENRE,1),),'multi-value','standard')' tag-field' $if($eql($meta(GENRE,1),),'standard','multi-value')' tag-field'

If you know in advance that a multi-value tag-field should be changed overall, ...
then use the new value appended with the string '\\' ...

Field: Genre
Current Value="New Age\\Chill-out"
Imported Value="New Age\\"
New Value="New Age"

See also ...
/t/12626/1
/t/11800/1

DD.20140902.1253.CEST


#3

Hi DetlevD. Thanks for you reply.

Unfortunately, I can't apply that strategy. If I knew in advance that a Tag needed a multi-value, then I would probably know its value and therefore I would put it there directly, without import/export. :wink: So, that is no solution for an Action, which has the main purpose and great advantage of being generalist.

As for the links, unfortunately I don't know enough German to understand what you wrote on the first thread, but I saw the code. :wink:
The second thread is more intended for beginners, which is not my case in this matter, but thank you anyway.

I think I do know how to use the multi-values splitter and I do understand the difference between characters. I've read the online manual and I've already used it extensively, especially in interacting with MusicBee, which uses a semi-colon ( ; ) as separator, and I had no problems with that fact. So, I'm pretty confident this has nothing to do with something wrong that I did.

My definition of bug is something like: Non-beneficial and Inconsistent (usually unintentional) behaviour of an application. I think this falls into that type of behaviour, that's why I still think this is a bug and not a feature or "normal" behaviour.

Besides, it makes no sense having to put a separator after the first value when you know there are no more values, or at least you are not sure if there are.
After all, it only makes sense to use the backslash ( \\ ) as value separator when there are at least two values to separate, and not always at the end of a field, because then it would be a field terminator (like the zero on a C language string) and not a separator, which are completely different things. :slight_smile:


#4

I've fixed this with Mp3tag v2.91b. Thanks for reporting!