GNOME Bugzilla – Bug 147441
typefind recognizes ELF files as audio/mpeg
Last modified: 2004-12-22 21:47:04 UTC
Right click library, click Add to Library..., select a folder containing an application (gnome shows them as Type: application/x-executable), and the application is added to the library. These should be ignored, they just play as noise, and caused a couple crashes for me.
What rhythmbox version? I believe this is fixed in newer rhythmbox (0.8.5 is the latest stable version).
It's version 0.8.5, I just installed it earlier today
Using what backend ? GStreamer or xine ? (if you have no idea what I'm asking, it means it's GStreamer ;)
Gstreamer version 0.8.2 (latest stable version I think)
Could you provide one such file ?
Created attachment 29475 [details] Example application The original file I obxerved this bug with, it's a binary used to play back moneky's audio files that happened to be living in my music directory. I confirmed the bug with two other apps as well.
Hm, interesting. I suspect that this binary happens to have something that looks like an ID3 frame. Not much we can do about that. I'll investigate a bit more to be sure.
walters@nexus> file /tmp/fooooo /tmp/fooooo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), stripped walters@nexus> gst-launch-0.8 filesrc location=/tmp/fooooo ! typefind ! spider ! audio/x-raw-int ! fakesink RUNNING pipeline ... ERROR (0x94d88f8 - 302930:01:20.676254000) spider(31273) gstspider.c(458):gst_spider_identity_plug:<spider0> There is no element present to handle the stream's mime type audio/mpeg. ERROR: from element /pipeline0/spider0: There is no element present to handle the stream's mime type audio/mpeg. ERROR (0x94d88f8 - 302930:01:20.677197000) scheduler(31273) gstoptimalscheduler.c(2607):gst_opt_scheduler_iterate:<GstOptScheduler@0x95406c8> in error state Execution ended after 2 iterations (sum 110894000 ns, average 55447000 ns, min 1638000 ns, max 109256000 ns).
I added a typefind function for ELF, which fixes the problem. I'm not sure how to make audio/mpeg less aggressive, but that would be wise as well. Leaving bug open until there's consensus as to what to do with audio/mpeg.
The problem is that this elf file contains 5 consecutive valid mp3 frames (if you only check the headers), which is the current way to detect an mp3 file as valid. So we'd either need to identify mp3 files better or hope the ELF identifier is enough.
This is not a blocker, since we etect ELF files correctly now.
Then this is fixed.