Non-ascii chars in Shoutcast Protocol

[KD7TKJ]

While I was testing tags support, specifically with Shoutcast support enabled, I noticed some errors in my logs pertaining to "Secrets" by Dutch DJ Tiësto, to the effect that the "ë" was out-of-range for ASCII encoding.

The song ID in question is http://localhost:9999/get_song?id=Tolnlbjpoxmhg7hermh5kkfud7i

And the specific error was "UnicodeEncodeError: 'ascii' codec can't encode character u'\xeb' in position 2: ordinal not in range(128)"

I SUSPECT that changing all of the "encode" and "decode" methods to use some superset of ASCII, but I haven't tested anything yet.

[KD7TKJ]

Alright, I changed every instance of encode('ascii') to encode('utf_8'), and GMusicProxy is no longer spitting errors on Tiësto songs. The patch is attached.

NOTE: I did NOT change the decode('ascii') methods, as they weren't spitting errors... But I don't know what consequences may arise from doing so.
fix-ascii-encoding.patch.txt

[KD7TKJ]

Alright, I ended up having more problems with this, so I ended up ALSO changing the .decode('ascii') methods to .decode('utf_8'), and I changed the char encoding to unichar.

The attached patch supercedes the previous one, making all of the required changes to convert from ASCII encoding to UTF-8 encoding, and should now support weird chars.
fix-ascii-encoding.patch.txt

[KD7TKJ]

I think this patch may have introduced a new bug... Let's see if it's reproducable for anyone else before I start jumping to conclusions.

I am running the latest 1.0.7 beta 1. Now all the songs will play and display shoutcast metadata, even with special characters. However, in both Amarok and VLC, those songs that have special characters will play at a highly accelerated rate (Maybe 2X speed?). I did most of my initial testing with the volume down, so I didn't notice :p

Anyway, two examples I have are Secrets by Tiësto, http://localhost:9999/get_song?id=Tolnlbjpoxmhg7hermh5kkfud7i
and Final Song by MØ, http://localhost:9999/get_song?id=T7ikzhjbcpxslr7wxuaj6ikcwba

[mario-tux]

I can confirm this VERY strange bug: it could be related to the shoutcast metadata implementation (not mine) and the characters could be the trigger condition that raise (in this very strange way) the bug. The same songs play well without the shoutcast metadata.
Could you see if you are able to found other songs with the same speed problem but without special characters in the metadata?

I'm reopening this report as reminder, but I have not time for this now.