What follows is the result of at least 4 man-days worth of effort
involving at least 6 different people. It ended with a solution that had
people in disbelief at the simplicity of the workaround and the
For the most part, playing music from within an app is simple and there are lots of ways to do it: background audio, MediaElement, or launcher.
Sometimes things go wrong, though, and last week was one such time. I was asked to look at a bug in a new app that plays music. The bug was that for some tracks there is an obscure error when playing from isolated storage. If the file is copied to the PC from isolated storage, then it plays fine, though.
In the exception, with its entirely external call stack, we could see a HRESULT of 0xC00D36C4 or a message of -1072875836. Neither of which are particularly helpful.
Even the internet couldn't give us much help. All we could find was a constant name of MF_MEDIA_ENGINE_ERR_SRC_NOT_SUPPORTED for the hex value but that was in a streaming video context. This didn't really help at all.
Beyond that, we found records of bugs relating to playing some audio files on Windows Phones, but these had all been closed and marked as "no repro".
I looked at files sizes when the tracks were downloaded on the phone and on a PC and everything looked the same.
After much experimentation, I realized there was a step in our reproduction process that hadn't been fully explored. When files are saved on the phone they were given a name based on their identifier. This meant that in IsolatedStorage they looked like: "/tracks/tr123456". When copied to the PC, we were renaming the file to include an extension (of ".mp3") so we could double click them to try and start playback. Starting to approach the limit of possibilities, I wondered what would happen if we tried to play the file with the ".mp3" extension on the phone. Low and behold the track started playing on the phone without issue.
So, the Fix?Just make sure that the files all had a ".mp3" extension on them and they all played fine. Yes, really that simple.
Why Does This Solution Work?Here's what I think is happening:
Without a file extension to tell the internal media stack what format the file is, it guesses, probably based on looking at part of the file's contents. In the instances where the file will not play correctly, it is probably assuming that it is not a regular MP3 file, even though it is, and so tries to play it assuming a different format. I must admit that my knowledge of the internals of the MP3 format is non-existent, and my knowledge of the internals of the media playback stack is even smaller, but this seems to be the most likely theory.