1. Go to the website http://210.55.198.68/aj/core/DRM/All_DRM/FL/ 2. Find that the file FL_AUD_MP3_1.dm and FL_AUD.MP3_2.dm cannot be played

Hi David - Not sure if this one belongs to you...could you help to check why these FL MP3 file cannot be played? Thanks Vance

Vance: could you be more specific about the issue you're seeing? Do you see the file download and then the dialog that says "Download Error: This type of purchased media is not supported on your phone. [err_unsupported_type: audio/mp3]" Also: are there other forward-locked MP3 files that do play correctly, or has everything broken? I verified that FL_AUD_MP3_1.dm does in fact contain a valid MP3 file. If I unpack it manually and put it on the sdcard I can play it in the music app. Logcat output indicates that the FL app is extracting 555,594 bytes, which is what I get when I unpack the file manually, so the issue is probably not related to extracting the mp3 file from the dm file. I do notice that the mp3 file's metadata is not Unicode so it displays incorrectly when I put the mp3 directly on the sdcard and play it in the music app. I don't think that the FL app would reject it for that reason, however. I have not yet looked at the code that triggers the err_unsupported_type error message, but presumably the issue is there somewhere. Antonio: is this a bug that you'd like to take? Vance: is this a blocker bug for any of our partners?

To be clear, this is a bug I can take, but given my current backlog and some upcoming vacation, I'm unlikely to be able to work on it for two weeks at least. Antonio, if you don't want this bug, please assign it to me.

I can take this next week, I'm on PTO this one. In any case, I've seen that error before on some builds that didn't had all the codecs installed (hamachi/buri builds used to suffer from that in fact). Can the phone that's failing play other files that use the same codec?

Hi David/Antonio - Partner just help to attach the logs and screenshots of this issue, and yes it is a TA blocker for our partner. They really need this one to be fixed soon. I understand that we get our backlog and PTO plans, so it would be nice if you can point out where in the source code the partner can look at for checking this problem. Then maybe Mozilla and partner can both check this issue simultaneously to increase the possibility to solve this one in time Appreciate your help

Well, according to [1] audio/mp3 is not a supported audio type. Now, I don't know if that's because that's not a correct mime type or why. As a test, you could try adding audio/mp3 to that list and see if that fixes the problem. Or you could try changing the mime type of the dm file to one of the supported ones. If neither of those are feasible solutions then as I said I can take this next week but this one the only 'work' device I have is a smartphone, which is where I looked at the code and I'm writing this :). [1] http://mxr.mozilla.org/gaia/source/apps/fl/js/constants.js#59

Oh, I forgot to say, just using audio/mpeg as the mime type for the dm file content should work (there's no need to actually touch the content, just use a correct mime type).

Antonio, Thanks for looking that up! I thought it might be something simple, but didn't figure it would be this simple. I'll take this and attach a patch to accept audio/mp3 in addition to audio/mpeg. I'm working on a blocker bug today, so this might not happen until tomorrow, but I'll see what I can do.

Comment on attachment 8476333 [details] link to patch on github Antonio, Thanks for the clue about audio/mp3 not being a valid mime type. It turned out not to be enough to just add it to the list of supported audio types, however. That allowed us to get past the first type check, but then we'd use the bad audio/mp3 type to create a blob and then Gecko would refuse to play the file. So I had to add code to actually map from audio/mp3 to audio/mpeg. I took your removeMimeTypeParameters() method and renamed it normalizeMimeType and added this mime type mapping to it. Also, I moved the call to normalizeMimeType so that it is always called whenever we read a mime type from the activity, and xhr, or from a file. So instead of fixing up the mime types before we use them, we're now fixing them up as soon as we read them. This is simpler because it means that if we've got a type stored in a variable or passed to a function we know it has been normalized. Please review when you're back in the office.

Vance, Antonio is the only one I know of who is familiar enough with this code to be a good reviewer. Unfortunately he is out of the office until next week, and won't be able to review until then. The patch seems to work for me, and our partners can start using it right away. If you think this needs to be reviewed immediately, it is a straightforward patch and you should be able to find someone to do it.

This patch applies cleanly to the 2.0 tree, and it ought to be uplifted to that release. It does not apply cleanly to the 1.3 or 1.4 trees, however, because it is built upon bug 971618 which has not been uplifted to 1.3 or 1.4. I know that our partner has something like bug 971618 in their tree, however, because the bug enables direct download of .dm files which is what this bug is about. If they uplifted 971618 then they should be able to apply this patch to their tree. If they have an earlier, carrier-private version of that patch from TEF, then this patch will probably not apply cleanly. But they ought to be able to use this patch to figure out how to modify their tree.

Thanks a lot David, Antonio for your help! Liu Bin, is this information enough to apply to patches and check if this solves the issue? Thanks a lot! David

Comment on attachment 8476333 [details] link to patch on github Given that this bug was reported on a 1.3 device, I think we ought to uplift the patch as far as we can. It applies cleanly to 2.0 so let's uplift it there. I expect that a number of carriers shipping 1.3 and 1.4 devices will have privately applied bug 971618 to their trees, and they may also want to apply this patch. NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] [Bug caused by] (feature/regressing bug #): some ringtone vendors use the incorrect mimetype audio/mp3 [User impact] if declined: won't be able to purchase ringtones [Testing completed]: yes, with the link at the top of this bug [Risk to taking this patch] (and alternatives if risky): low-risk [String changes made]: none

Antonio, If you give r+ to this patch when you review, please feel free to land it. I will be OOO when you are back in the office. Assuming you are still at TEF, will you let your downstream carriers know about the availability of this patch?

Comment on attachment 8476333 [details] link to patch on github The patch LGTM, thank you! As for uplifting this to 1.3 on our (TEF) builds, I don't believe this has come out in our own services. And I think it's too late to include this on the devices anyway. Needinfo'ing Beatriz just in case though. Beatriz, do you know if this is needed in our builds?

As David asked in comment 17, landed: https://github.com/mozilla-b2g/gaia/commit/4b0dcdacfc2e5b35000cc4af0bbdb565fcdd855a

(In reply to Antonio Manuel Amaya Calvo (:amac) from comment #18) > > As for uplifting this to 1.3 on our (TEF) builds, I don't believe this has > come out in our own services. And I think it's too late to include this on > the devices anyway. Needinfo'ing Beatriz just in case though. > > Beatriz, do you know if this is needed in our builds? It is enough to have it in 2.0. Thanks!

v2.0: https://github.com/mozilla-b2g/gaia/commit/5bf3b8cdea15e62ce7bf77a15085a18e24e33c44

Issue is verified fixed on Flame 2.0 and Flame 2.1. Music app can play Forward Lock/DRM mp3 files. Device: Flame 2.1 (319mb)(Kitkat Base)(Shallow Flash) BuildID: 20141126001202 Gaia: db2e84860f5a7cc334464618c6ea9e92ff82e9dd Gecko: 211eae88f119 Version: 34.0 (2.1) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Device: Flame 2.0 (319mb)(Kitkat Base)(Shallow Flash) Build ID: 20141126000203 Gaia: f9d6e3d83c3922e9399a6c27f5ce4cdd27bdfd05 Gecko: 45112935086f Version: 32.0 (2.0) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0