Inaccurate returns by $meta(x,0) in a special case



Inaccurate returns are given by meta placeholders for value 0 if they refer to their own field.

I've made some tests with Format value, based on this multivalue field: TESTING=Arnold\Bruce\Cedric

Tested in v2.93

Note: The forum replaces double back slashes with single so Arnold\Bruce\Cedric means triple values

===== Issue 1 =====

Format string : $meta(testing,0)

the return is the multivalue Arnold\Bruce\Cedric

However, with

Format string : $meta(testing,1)

the return is Bruce

and with

Format string : $meta(testing,2)

the return is Cedric

So it seems that the format string in the first example (value 0) incorrectly returns the full multivalue. But if you use it for a different field:

Format string : $meta(testing,0)

then the return is Arnold

So the issue only occurs when the format string refers to value 0 and to its own field

===== Issue 2 =====

A similar issue but for %fieldname%

Format string : %testing%

returns Arnold\Bruce\Cedric


Format string : %testing%

returns Arnold


Thanks for reporting!

I can reproduce and confirm Issue 1, which is based on a (wrongly performed) optimization in the Format value action. I'll fix that to the next release.

If you're interested in the details: I'm comparing the existing and new values and don't change anything, if they're identical. However, I was only comparing the first value, which leaves the complete field untouched in case of $meta(field,0).

Issue 2 is a little bit different: it currently leaves the field untouched if you're using %field% as format string. This is only due to the erroneous check described above. Why? Because %field% always returns the first value of field. So after Issue 1 is fixed, both cases from your example in Issue 2 should return Arnold.

A meta comment: you can wrap strings containing backslashes in backticks ` so that they're formatted as preformatted text, e.g., Arnold\\Bruce\\Cedric.


Thanks for the details, they made me realize that if the receiving field is a multivalue field too, and value 0 is identical in both fields, then this bug will occur regardless. So the format string doesn't need to refer to its own field as I concluded.

Great that you can fix it soon!


I've fixed this with Mp3tag v2.93a. Thanks again for reporting!


Thanks for the fix! I've tested and it's working properly now.


Excellent! Thanks for confirming the fix.