GNOME Bugzilla – Bug 539963
doesn't scrobble tracks with Japanese or Cyrillic characters properly
Last modified: 2008-12-29 22:19:59 UTC
Please describe the problem: I have some tracks that have been tagged on Windows (ansi webpage, if it's important) with Japanese and Cyrillic characters, for instance. They are shown properly in the UI, but when they are sent to last.fm, they are displayed in some crazy manner on their webpage. It was confirmed by someone on your irc channel, that it used to be a problem in older versions as well, but there was no problem with it in 0.13.2. (the latter I checked by myself - it works correctly). There is also no problem with such a behaviour in e.g. Quod-Libet or Rhythmbox, so I assume that's a problem with banshee. Steps to reproduce: 1. play a song 2. wait for the submission 3. look at last.fm :D Actual results: Expected results: Does this happen every time? yes Other information:
I can confirm this one. When I play: 谭盾 - Eight Memories in Watercolour My userpage on Lastfm shows: è°ç¾ – Eight Memories in Watercolour,
could the reporter "Me" verify this: It only shows the tracks wrong in the "now playing" entry in the chart, not when it has finished playing the track: è°ç¾ – Eight Memories in Watercolour, Op. 1: VI. Floating Clouds now listening 谭盾 – Eight Memories in Watercolour, Op. 1: V. Ancient Burial just listened 谭盾 – Eight Memories in Watercolour, Op. 1: VII. Red Wilderness 4 minutes ago
Last.fm's "now playing" processing is just not properly handling the requests, since Banshee does submit the exact same artistname in the case of 谭盾. %e8%b0%ad%e7%9b%be = nowplaying %e8%b0%ad%e7%9b%be = final submit So, if the problem is indeed that "now listening" is not correctly displayed, then it's Lastfm's error and not Banshee's.
(In reply to comment #2) > could the reporter "Me" verify this: > > It only shows the tracks wrong in the "now playing" entry in the chart, not > when it has finished playing the track: > > è°ç¾ – Eight Memories in Watercolour, Op. 1: VI. Floating Clouds > now listening > 谭盾 – Eight Memories in Watercolour, Op. 1: V. Ancient Burial just > listened > 谭盾 – Eight Memories in Watercolour, Op. 1: VII. Red Wilderness 4 > minutes ago > my bad, that's true; I'm pretty sure that in the beta version it wasn't scrobbling correctly and when I looked that this "now playing" behaviour is bad, I assumed it's still wrong... Or sth like that... Anyways - looks strange, afair there weren't any problems with that with Windows players. I thought that maybe the submits for "now playing" and standard scrobbling are handled in a different way, but since you've checked the strings coming out... no idea.
I think I've figured out what causes this; Banshee submits the metadata as parameters in the URL, while Audioscrobbler expects them to be in the request body. If AudiscrobblerConnection.NowPlaying(uri) can be modified to send metadata this way, it should work correctly. Incidentally, this is why "real" transmission works; TransmitQueue() sends data in the request body.
Created attachment 122631 [details] [review] Send "now playing" metadata in the request body Quick patch; rename `current_now_playing_uri` to `current_now_playing_data`, encode it to the request body. I'm unfamiliar with C#/.NET, so this is likely not the best way to do it, but it works well for me.
John, your patch looks good - I assume you've tested it quite a bit and it works 100% for you? Did you try/consider having the body of the POST be UTF-8? Not sure if that is accepted by Last.fm, but if it is, we should probably use it.
> I assume you've tested it quite a bit and it works 100% for you? Yes, I've been using it for a few weeks now with no errors. > Did you try/consider having the body of the POST be UTF-8? I believe HttpUtility.UrlEncode encodes to UTF-8. Last.FM might accept non-URL encoded input, but I've not tested this and would not want to rely upon such behavior.
I meant the part where you take the url-encoded data and write it to the request stream as ascii-bytes (ASCIIEncoding encoding = new ASCIIEncoding (); etc) - could we do that as UTF-8. From monodoc re; ASCIIEncoding: "The limited range of code points supported by System.Text.ASCIIEncoding makes ASCII inadequate for many internationalized applications. System.Text.UTF8Encoding and System.Text.UnicodeEncoding provide encodings that are more suitable for internationalized applications."
There's no need, and it would have no effect on the output. URL-encoded text is entirely ASCII. For example, if an album is titled Привет , it will be url-encoded to %D0%9F%D1%80%D0%B8%D0%B2%D0%B5%D1%82 .
Ah, ok, great! I tested the patch, works fine - committed!