Bugzilla – Bug 5898
Bad display of a specific foreign character
Last modified: 2009-09-08 09:27:43 UTC
I have several songs with titles in Estonian which do not display correctly in the Beta version of 7.0 - 14001. These titles have two consecutive characters which are an "a" with an umlaut (two dots) over them. When these titles are in the playlist or song list, SqueezeCenter displays them as two characters which appear to be in the Hebrew alphabet (they look like a disconnected lower case "n"). Single instances of this character display correctly. In my environment I run SqueezeCenter on a server (running a 64-bit version of XP Pro), and I usually access it on a desktop (running standard XP Pro) over a network. On the desktop display (either the playlist or the song list in an album) the two characters appear to be wider than the software expects, and this causes the symbols normally at the end of the line (the plus sign in the song list or the delete symbol in the playlist) to be wrapped around and appear on the left. However, when I look at SqueezeCenter directly on the server (using Remote Desktop) the characters are still incorrect but the wrapping doesn't happen. I have tried this both in full screen mode and in a reduced window, and the behavior stays the same in each environment. I would like to include one of the files which cause the problem, but I don't see how to attach something to this bug (I have attached files to bugs in the past, but I don't remember how I did it). Please let me know how to do this.
Created attachment 2313 [details] Song File with Bad Estonian Characters
Created attachment 2314 [details] File with a single instance of the bad Estonian character The second character in the title of this song is the one which causes the problem when doubled. It seems to display correctly in this case.
I obviously figured out how to add attachments. Note that a single instance of the character works fine. This displays correctly in iTunes, and I believe it was correct in all the earlier versions of SlimServer. I know that the wrapping problem did not occur, but the control symbols were handled differently then anyway. It is possible that the characters displayed incorrectly before, since it is not easy to notice this without the wrapping to highlight it.
In version 7.0 - 14500, the character display is still incorrect but the symbols (delete, etc.) are now correctly positioned at the end of the line in both Fishbone and Default skins.
I looked at the character in more detail, and it is a hex E4. The single and double instances are both the same character (I thought perhaps the double character was a unique value). I had another display issue, where a character which is hex B4 displayed correctly as a reverse apostrophe in iTunes, but a sequence of that character followed by an uppercase N followed by that character displays as two Chinese characters in SqueezeCenter in IE7, and as two of the small square unrecognized character symobols in IE6. This file is attached.
Created attachment 2424 [details] Song File with Bad Character Sequence The song title has the bad hex B4 characters around the N.
QA to reproduce.
Very strange. I don't see this as you describe, in the web interface I just see the boxes windows regurgitates when it can't recognize the character, I don't see anything resembling Hebrew as you mention. What do you see on the players display? I see Chinese characters there, very odd.
Created attachment 2432 [details] picture of Chinese characters on SB2 display
I am attaching screen captures of the bad character display which looks like Hebrew. One of them is in the Fishbone skin, and the other in in the Default skin. Tracks 8 and 12 have the bad display, and tracks 1 and 2 have the correct single "a" with umlaut. The Squeezebox display is exactly the same. I can look with either IE7 on my client machine, or with IE6 on the server, and the display is the same. This would lead me to assume this means the issue is related to the fonts loaded in the server, except that the "Chinese character" problem displays differently in the IE6 vs. IE7 environments. The server machine is running a 64-bit version of XP Pro.
Created attachment 2441 [details] Default skin with bad characters
Created attachment 2442 [details] Fishbone skin with bad characters
Both attachment 2313 [details] and attachment 2424 [details] are reported by MP3::Info (after changing $debug_Tencoding = 1;) as having malformed ISO-8859-1/UTF-8 content in several of the tags, title included. While this doesn't necessarily indicate something inherently wrong, it does indicate where the trouble is coming from. At this point in the code, MP3::Info is attempting to fix what it sees as a corruption. However, the fix clearly isn't accomplishing a fix, nor is there any improvement when bypassing the fixes. This section of the code appears to have been added by Dan at change 7266, based on a patch provided by Justin Fletcher. I'll add him to the CC in case he might have some insight after checking one of the attached files.
Steve: Can you try having iTunes "Convert ID3 Tags..." try to fix the encoding with Reverse Unicode? That may be the best solution.
I tried changing the ID3 tags in iTunes using Reverse Unicode. Unfortunately, this doesn't change the specific problem characters in the first file - they remain as hex E4 and still display incorrectly. When I try to change the ID3 tags for the second failing file (the one which produces the Chinese characters), I get an error message in iTunes that says the tags are of the wrong type, although the Title displays correctly in iTunes.
Steve - this sounds like a dupe of 5686. Would you agree?
*** Bug 9047 has been marked as a duplicate of this bug. ***
Michael - I agree that this is a dupe of 5686.
thanks! *** This bug has been marked as a duplicate of bug 5686 ***