Comment 8 for bug 1364466

Pat: the underlying problem is that there are bugs in some of the media codecs when faced with invalid files. The bug was deprioritised in mediascanner2 (but not GStreamer!) is because we added code to mitigate the problem by making the media scanner service not rescan a file that caused it to crash previously.

We do have a plan to improve this further in a way that will stop the errors showing up for media scanner. Basically:

1. separate the metadata extraction into a separate process.
2. add this process to the apport blacklist
3. have the media scanner service use the out of process metadata extractor

We haven't been working on this in the short term (i.e. RTM time frame) because it is a fairly disruptive change and we already have a mitigation strategy in place. Further more, any file that crashes media scanner will almost definitely crash the media player too (hence the GStreamer bug task).

Note also that there is unlikely to be a single fix that will stop all future crashes: we will likely continue to find files that cause the codecs to crash as time goes on (and since we have hardware decoders, we will likely find files that only crash on particular devices). If we want to be methodical about this, one strategy would be to:

1. put together a collection of problem media files.
2. write a test harness that will attempt to decode each file and record any crashes (ideally with stack traces if applicable).
3. run this test suite on the devices we care about (desktop, mako, krillin, etc) at regular intervals
4. when new codec crashers are discovered, add those media files to the collection so we can ensure that we don't regress (and have more test cases for when we bring up a new device).