Risk of explosion with .dds files

See #95 (closed) for the background to this issue. Issue #95 (closed) is very general, but one data point is that sometimes Tracker is causing desktop lockups for people when trying to process .dds files.

.dds is an image format used mainly in video games and video game mods. The MIME type is detected as image/x-dds, and due to our 90-gstreamer-image-generic.rule extract rule we end up sending the file to GStreamer.

There is no GStreamer plugin that could decode .dds files. Running tracker-extract on a random .dds file with GST_DEBUG=*:3 produced many warnings like this:

0:00:00.057568078 12862 0x7f23f80e86d0 WARN          mpegaudioparse gstmpegaudioparse.c:475:gst_mpeg_audio_parse_head_check:<mpegaudioparse0> invalid bitrate: 0xf

A different file produced this:

0:00:00.058564737 12892 0x55fb9e837700 WARN              discoverer gstdiscoverer.c:1584:handle_message:<mpegvparse0> Got an error [debug:gstbaseparse.c(3625): gst_base_parse_loop (): /GstPipeline:Discoverer/GstURIDecodeBin:discoverer-uri/GstDecodeBin:decodebin1/GstMpegvParse:mpegvparse0], [message:No valid frames found before end of stream]

Another produced a long stream of these warnings, and several seconds of high CPU usage:

0:00:05.267261435  2926 0x7f76780e76d0 WARN                   libav gstavauddec.c:756:gst_ffmpegauddec_handle_frame:<avdec_mp1float0> decoding error

Obviously the GstDiscover object is doing something wrong here.

We should do a fix on the stable branch for this. First we should specifically blacklist image/x-dds files in 90-gstreamer-image-generic.rule. And, perhaps we could see if GstDiscoverer could be improved to avoid parsing image file formats with an MP3 decoder.