GNOME Bugzilla – Bug 729328
EasyTag tells to apply patch to id3lib even when it is applied
Last modified: 2014-05-09 15:41:46 UTC
When I try to save tags in ID3v2.3 format, EasyTag sometimes gives a message: "You have tried to save this tag to Unicode but it was detected that your version of id3lib is buggy" It also tells to apply a patch to id3lib. The problem is that I do have that patch applied. It seems that the problem occurs when I give a genre that is in the predefined list, but write it with some letters in different case, e.g. I write Jpop -> EasyTag saves that as JPop. Could it be that this change is somehow misinterpreted as caused by buggy id3lib?
The method of determining whether a buggy id3lib is in use is: https://git.gnome.org/browse/easytag/tree/src/id3_tag.c#n1327 The (very long) function that saves tags and checks the result of the buggy id3lib check is: https://git.gnome.org/browse/easytag/tree/src/id3_tag.c#n134 The dialogue should only be shown if id3lib is buggy, so it is probably worth splitting that check out to a test, and trying it against various id3lib versions to see if there is a problem which causes the check to fail.
The Id3tag_Check_If_Id3lib_Is_Bugged function indeed reports my version of id3lib as buggy. I just wonder how it is possible to obtain a version that is not buggy. I tried installing the default packages in Arch Linux, Ubuntu Precise, Gentoo, and Fedora 16. I got the same error from EasyTag in all of them. As far as I understand from their source packages, they all are including a bunch of patches, including the one mentioned in EasyTag's error message.
Thanks for doing some testing! I am travelling at the moment, but next week I can investigate this a bit further, as it may well be that the check in Id3tag_Check_If_Id3lib_Is_Bugged() is broken.
I investigated this a bit, and found that I was using an invalid UTF-16 string as input, when I should have been using a UTF-8 string. Therefore, the check always found a "buggy" id3lib. After fixing the test string, based on the string in the original id3lib bug report, this seems to correctly report a non-buggy id3lib implementation. I will making a new 2.2.2 release with the fix (and other fixes) soon.