[Bug] Tags including the Polish character "ł" are randomly regressing to "l"

[VulgarAscetic]

Mp3 tags which include the Polish character "ł" are randomly regressing to the English "l", most notable when Polish "ł" is included in more than one tag, eg. song title and album title.

Repro steps:
1. From the library view, open "Edit item metadata" window on an mp3
2. Change the song title to something including "ł" (eg. "hijkłmno")
3. Change any other field to the same title, eg. artist, album artist, album name, etc.
4. Click Update

Expected result:
All fields should maintain the new titles

Actual result:
One of the fields with "ł" will regress to the English character "l"

[MarkRH]

Due to the font size I thought you were typing the same characters, but it's

"ł" vs "l"

The Polish one has that diagonal cross thing.

[VulgarAscetic]

Thanks for helping clarify that!

[dro]

Is what's stored in the mp3 files incorrectly changing? If so then it's most likely an in_mp3 plug-in issue which is one of the few things I'm still pulling in from the 5.666 installer & other than messing with it's config options for tag handling I don't have a quick solution. If it's only affecting what's showing within in the local library then I'm not sure why that'd fail as I do all of it in unicode to try to avoid issues like this.

[VulgarAscetic]

I know that these tags have been correct for years, and at *some* point changed to the incorrect character, but unfortunately I can't say when that occurred, but I'm inclined to believe it was recently, as in since changing to WACUP, as one of them was appearing as an incorrect Artist which I'd be surprised if I hadn't noticed until now.

I have now managed to change the tags using the external mp3tag tool, and they appear to be sticking correctly now, so there is definitely a bug with tags changed via WACUP regressing to the incorrect English characters.

I'll keep an eye on them moving forward and see if they change back again.

[dro]

As you're saying it's what was in the file tags then that's the re-used nullsoft in_mp3 plug-in being buggy & that's only really being kept around as I've not gotten around to coding my replacement mainly for the tag editing aspects since the x64 build can't edit mp3 tags until that's implemented (& then in_mp3 will be dropped).