948950 - [Download Manager] The ogg files are not correctly reproduced

Status: VERIFIED INVALID

(Firefox OS Graveyard :: Gaia::Music, defect)

Description

[rafael.marquez]

Attachment: error.png

*Procedure
1. Download ann .ogg file
2. Open the download list (Settings / downloads list)
3. Click on the downloaded .oog file to open it

*Expected result
The file is reproduce successfully

*Actual Result
A error is displayed and the file is not reproduce (see the screenshot attached)

Comment 1

[rafael.marquez]

Attachment: One_Big_Rabit.ogg

Comment 2

[Jason Smith [:jsmith]]

Couple of questions:

1. Can you play that file in the browser when visiting https://bugzilla.mozilla.org/attachment.cgi?id=8345896?

2. Can you play that file from the sdcard in the video app?

That will help isolate where the bug is here.

Comment 3

[Jason Smith [:jsmith]]

QA Wanted for comment 2

Comment 4

[rafael.marquez]

1. Can you play that file in the browser when visiting https://bugzilla.mozilla.org/attachment.cgi?id=8345896?

Yes, I can

2. Can you play that file from the sdcard in the video app?

Yes, I can

You work in qa. why you put a "qawanted"? 
Perhaps it is faster for the team if you try it yourself.


(In reply to Jason Smith [:jsmith] from comment #2)
> Couple of questions:
> 
> 1. Can you play that file in the browser when visiting
> https://bugzilla.mozilla.org/attachment.cgi?id=8345896?
> 
> 2. Can you play that file from the sdcard in the video app?
> 
> That will help isolate where the bug is here.

Comment 5

[Cristian Rodriguez (:crdlc)]

Interesting, the problem is because of the mime type received from mime mapper is "audio/ogg" :) And the Audio app cannot open this file. It would be a miracle if it will work fine jajaja

I added some logs and the Download API created a download object with mime type "audio/ogg" for this video, so moving to the API component

https://github.com/mozilla-b2g/gaia/blob/master/shared/js/mime_mapper.js

Jason, which is the component for the API?

Comment 6

[Jason Smith [:jsmith]]

General seems fine for now - we don't really have a downloads API component. I should look into getting a component built for that though if we're going to have a lot bugs in this area.

Comment 7

[Aus Lacroix [:aus]]

In this particular instance, it isn't a bug in the API. This is what is returned by the server: audio/ogg; name="One_Big_Rabit.ogg"; charset=

There's no way for the Downloads API itself to figure out that this is the wrong mime type without understanding how to parse ogg.

We could possibly be smarter about routing to the correct application but that's not part of the Downloads API :)

Comment 8

[Cristian Rodriguez (:crdlc)]

OK, in that case, this problem was not in the API's roof, the server is tricking us so, what could we do? front-end is receiving a wrong mime-type from server. Some suggestion guys?

Comment 9

[Francisco Jordano [:arcturus] [:francisco]]

mmm Aus, correct me if I'm wrong, but in the download object we already have a mime type istn?

We could try to give preference to that one over the one returned by mime mapper?

Comment 10

[Aus Lacroix [:aus]]

We could, but unfortunately in this case it's the server that's returning the wrong mime type for the file. This would in turn cause '.ogg' files that are Ogg Vorbis (which is audio only) to fail to play in the Video (or play in a degraded experience).

Let me check with the media team to see what they think. :)

Comment 11

[Dave Hylands [:dhylands]]

There may be some device storage interactions going on here as well.

.ogg files can be video or audio.

You can't tell which type it is until you actually open the file and device storage doesn't persist the mimetype.

Currently, I believe that there is a bug (but I cant seem to find it) where device storage will only notifiy video or audio (but not both) when a .ogg file is added to the storage area, so if the app which doesn't get notified is currently running, then it won't see the newly added file until it does a rescan.

Looking at http://dxr.mozilla.org/mozilla-central/source/toolkit/content/devicestorage.properties ogg, .mp4 and .3gp are all extensions that can be either music or video, and we nee dto figure out how to distinguish which one a given file is.

Comment 12

[rafael.marquez]

Any news about this bug? The bug still happens. I can't reproduce the ogg video from download list but I can reproduce the same video file from video app

Comment 13

[Preeti Raghunath(:Preeti)]

QA,

Please help reproduce this in 1.4.

This is not a high priority till mid Feb given 1.3 being higher priority

Comment 14

[Jason Smith [:jsmith]]

(In reply to Preeti Raghunath(:Preeti) from comment #13)
> QA,
> 
> Please help reproduce this in 1.4.
> 
> This is not a high priority till mid Feb given 1.3 being higher priority

Rafael already reproduced this - he's the QA lead on the feature.

Comment 15

[rafael.marquez]

Thanks Jason. 
Preeti, I can reproduce the bug and I think we should investigate what happens as it is a rare bug.

Comment 16

[Gregor Wagner [:gwagner]]

Hema, can your team take a look here? Dave already gave a good summary in comment 11.

Comment 17

[rafael.marquez]

Gaia::Music? this .ogg is a video file.

Comment 18

[Jason Smith [:jsmith]]

(In reply to rafael.marquez from comment #17)
> Gaia::Music? this .ogg is a video file.

Well, the app in the screenshot here is the music app.

Comment 19

[Jason Smith [:jsmith]]

I think there's a missing question here in the testing.

Where was this ogg file originally downloaded when this was originally tested? That greatly affects what the problem here is. If this was downloaded from a site that had the correct mime type served, then this should be a blocker, as this means we'll never be able to view ogg video files downloaded in the video app.

Comment 20

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #19)
> I think there's a missing question here in the testing.
> 
> Where was this ogg file originally downloaded when this was originally
> tested? That greatly affects what the problem here is. If this was
> downloaded from a site that had the correct mime type served, then this
> should be a blocker, as this means we'll never be able to view ogg video
> files downloaded in the video app.

I'm specifically looking for a target URL to use to download the ogg file.

Comment 21

[rafael.marquez]

The ogg file was downloaded from https://owd.tid.es/dm/

I do not understand because the bug has been selected to backlog. Will be fixed in v1.4?

Comment 22

[Jason Smith [:jsmith]]

(In reply to rafael.marquez from comment #21)
> The ogg file was downloaded from https://owd.tid.es/dm/
> 
> I do not understand because the bug has been selected to backlog. Will be
> fixed in v1.4?

It isn't a bug in the download manager - it's a bug on the server side. I've just confirmed this by studying the HTTP Headers of that target URL. See below.

$ curl -I -k https://owd.tid.es/dm/One_Big_Rabit.ogg
HTTP/1.1 200 OK
Date: Wed, 19 Feb 2014 08:37:09 GMT
Server: Apache/2.2.15 (CentOS)
Last-Modified: Thu, 28 Nov 2013 11:48:07 GMT
ETag: "64081b-4288cf-4ec3b498868b3"
Accept-Ranges: bytes
Content-Length: 4360399
Connection: close
Content-Type: audio/ogg

Note the last piece of that output - it's indicating that the file is an audio file. So what the download API doing here is it's downloading the blob & encoding it with the server's mime type - which is audio, not video. However, the file is a video file. So when we try to open the file, we produce the relevant web activity that makes sense in this case based off the mime type of the file - which is audio/ogg. This causes the music app to open to try to read the file. However, it fails to read the file, as the file is a video file, not an audio file.

Does that make sense? 

On that regard, that makes this bug invalid, as this is problem on the server side.

Comment 23

[rafael.marquez]

If that's the problem. Why then the file is opened by the application of video from the gallery?


(In reply to Jason Smith [:jsmith] from comment #22)
> (In reply to rafael.marquez from comment #21)
> > The ogg file was downloaded from https://owd.tid.es/dm/
> > 
> > I do not understand because the bug has been selected to backlog. Will be
> > fixed in v1.4?
> 
> It isn't a bug in the download manager - it's a bug on the server side. I've
> just confirmed this by studying the HTTP Headers of that target URL. See
> below.
> 
> $ curl -I -k https://owd.tid.es/dm/One_Big_Rabit.ogg
> HTTP/1.1 200 OK
> Date: Wed, 19 Feb 2014 08:37:09 GMT
> Server: Apache/2.2.15 (CentOS)
> Last-Modified: Thu, 28 Nov 2013 11:48:07 GMT
> ETag: "64081b-4288cf-4ec3b498868b3"
> Accept-Ranges: bytes
> Content-Length: 4360399
> Connection: close
> Content-Type: audio/ogg
> 
> Note the last piece of that output - it's indicating that the file is an
> audio file. So what the download API doing here is it's downloading the blob
> & encoding it with the server's mime type - which is audio, not video.
> However, the file is a video file. So when we try to open the file, we
> produce the relevant web activity that makes sense in this case based off
> the mime type of the file - which is audio/ogg. This causes the music app to
> open to try to read the file. However, it fails to read the file, as the
> file is a video file, not an audio file.
> 
> Does that make sense? 
> 
> On that regard, that makes this bug invalid, as this is problem on the
> server side.

Comment 24

[Jason Smith [:jsmith]]

(In reply to rafael.marquez from comment #23)
> If that's the problem. Why then the file is opened by the application of
> video from the gallery?

I'm not sure if I follow your question. Can you reword?

Comment 25

[rafael.marquez]

I can see in your comment that the file is invalid because it has "Content-Type: audio/ogg" 
But do not understand why if I open the gallery app the file is opened as video type.

Comment 26

[Jason Smith [:jsmith]]

(In reply to rafael.marquez from comment #25)
> I can see in your comment that the file is invalid because it has
> "Content-Type: audio/ogg" 
> But do not understand why if I open the gallery app the file is opened as
> video type.

I've pinged David to provide input on this.

Comment 27

[David Flanagan [:djf]]

(In reply to rafael.marquez from comment #25)
> I can see in your comment that the file is invalid because it has
> "Content-Type: audio/ogg" 
> But do not understand why if I open the gallery app the file is opened as
> video type.


By the time the file is stored on sdcard, we've lost any mime type information from the server. All we know is that the file has a ".ogg" extension.

The gallery app sees all .ogg files when scanning the sdcard.  It trys to play each one as a video. If it succeeds, then it knows it is a video file. If it fails, it ignores the file.