Hide Forgot
Created attachment 534744 [details] Force totem-pl-parser to pass the filename to g_content_type_guess Description of problem: 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.
Created attachment 534745 [details] Source RPM that builds into a fixed package
As noted in the upstream bug, this is wrong as it breaks the test suite. Please attach the example file to the upstream bug.
We discussed it upstream. As I said there, my hack was to make MP3 playback work for me only, and as an interim solution. I am preparing an update to shared-mime-info with the upstream fix.