GNOME Bugzilla – Bug 664457
totem-pl-parser cannot correctly recognize MP3 files
Last modified: 2011-11-21 19:49:55 UTC
Created attachment 201793 [details] [review] Patch to force totem-pl-parser to call g_content_type_guess - a quick hack totem-pl-parser handles parsing out new additions to the playlist through some excessively complicated logic, from within a worker thread. Somewhere along the line this has been broken - either from a change to GIO (most likely), or some change to totem-pl-parser. In any case, when it starts executing the parser, it knows that it's dealing with a reasonable mime type of audio/mpeg, but after: my_g_file_info_get_mime_type_with_data Uses the following gio provided function: g_content_type_guess It becomes convinced that the correct mime type is application/x-designer, and then refuses to play the MP3, which never gets added to the playlist. The correct fix is to do one of the following: 1). Fix g_content_type_guess so that if it doesn't have a filename passed (which it doesn't at this point, and probably is true in other cases) it will either make a sane decision or actually use the confidence logic correctly to say "I have no idea what this file type is", in which case totem's existing logic would likely fallback correctly to what it already knows. 2). Fix totem-pl-parser to always call g_content_type_guess with a filename if it has one (doesn't if it's a stream, but that name could be a NULL). It is this quickhack solution that I've implemented on all of my systems, through the attached patch. With it, I can once again play really bad 80s pop. Jon.
Your patch makes the test suite (run as part of "make check") fail. "It becomes convinced that the correct mime type is application/x-designer" That means that the MP3 is detected as that based on data from shared-mime-info. Please attach the file so we can see whether the file is that broken.
Of course it makes the test suite fail :) It's a quick hack because I want working MP3 playback...not ready for consumption beyond that :) I can't attach the MP3, but I can attach a fair use 4K block from the beginning of the file that includes the header. It's a commercial recording. The particular file (though I'm sure others reproduce this just fine out of the box on F16) was: [jcm@constitution ~]$ md5sum Downloads/01\ -\ Back\ To\ The\ 80\'s.mp3 f1c6aeb84dbc0d038eccb5f0de5b60fb Downloads/01 - Back To The 80's.mp3 [jcm@constitution ~]$ id3info Downloads/01\ -\ Back\ To\ The\ 80\'s.mp3 *** Tag information for Downloads/01 - Back To The 80's.mp3 === PRIV (Private frame): (unimplemented) === TIT2 (Title/songname/content description): Back To The 80's === TPE1 (Lead performer(s)/Soloist(s)): Aqua === TALB (Album/Movie/Show title): Greatest Hits === TCON (Content type): Pop === TCOM (Composer): Sxren Nystrxm Rasted === TPE3 (Conductor/performer refinement): === TRCK (Track number/Position in set): 1/19 === TYER (Year): 2009 === COMM (Comments): ()[eng]: Amazon.com Song ID: 213352431 === TPE2 (Band/orchestra/accompaniment): Aqua === TCOP (Copyright message): (C) 2009 Geffen Records === TPOS (Part of a set): 1/1 === APIC (Attached picture): ()[, 3]: image/jpeg, 287370 bytes === COMM (Comments): (ID3v1 Comment)[XXX]: Amazon.com Song ID: 21335243 *** mp3 info MPEG1/layer III Bitrate: 256KBps Frequency: 44KHz This file was purchased from the Amazon MP3 store. I suspect if there's a "problem" with this file, the same is true of millions of others. And that then means that the problem is not with the file (if everyone else is wrong, then they are not wrong) :)
Created attachment 201835 [details] hexdump -n 4096 -s 0 Downloads/01\ -\ Back\ To\ The\ 80\'s.mp3 >aqua-back_to_the_80s-header.txt
Just attach the first 100k of the file to this bug. And no, there's no problems with millions of others either. Only way this could be the case is if there was "<ui" in the first 256 characters.
Additionally, I just purchased a "gift" version of this song on Amazon.com for you to download at your leisure. Amazon sent email to hadess@hadess.net.
Created attachment 201837 [details] First 100K of the file
You'll need to rename to an ".mp3" extension for totem to even think about using this file, even with my patch. My patch just tries to make some of the GIO logic get used, but really if it's trying to process bitstreams and figure it out from that, it's not working at all.
00000040 22 55 54 46 2D 38 22 3F 3E 0A 0A 3C 75 69 74 73 "UTF-8"?>..<uits 00000050 3A 55 49 54 53 20 78 6D 6C 6E 73 3A 78 73 69 3D :UITS xmlns:xsi= But I suspect you'll find this true of *millions* of other MP3 files, especially those purchased from the Amazon MP3 store.
I didn't see this in any of the MP3s purchased through Amazon UK. See also: http://invertedsky.net/?p=471 Fixed in shared-mime-info git: commit 003ccc12e1cb81ff8c6dc51796ac7fe7888fe52a Author: Bastien Nocera <hadess@hadess.net> Date: Mon Nov 21 18:18:54 2011 +0000 Fix MP3 being detected as Qt Designer https://bugzilla.gnome.org/show_bug.cgi?id=664457 commit 6458b701aa29da1189b63995d6bf1fec3e452308 Author: Bastien Nocera <hadess@hadess.net> Date: Mon Nov 21 18:17:48 2011 +0000 tests: Add test case for wrongly identified MP3 Was detected as a Qt Designer file because of the PRIV comment at the start of it containing "<ui". https://bugzilla.gnome.org/show_bug.cgi?id=664457 Patch is here: http://cgit.freedesktop.org/xdg/shared-mime-info/commit/?id=bb6a26ff9f45363e8290372e113044a2dd2b70dd Feel free to commit to the shared-mime-info Fedora package.
Ok. I'll do a build of the shared-mime-info Fedora package in 30 minutes from now after my next meeting.
I built the package, but the update needs to be pushed to F16 and I can't do that.