User Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0 Build ID: 20120420145725 Steps to reproduce: 1 copy video files such as *.3gp *.mp4 into "sdcard/DCIM/101MZLLA " 2 open gallery app Actual results: these video files can not be list. Expected results: list files correctly
We'll some additional answers to determine if this falls into expected behaviour or not. Were these files copied using USB Mass Storage? Was the sdcard ejected from the PC and the USB cable unlugged? Was USB Mass Storage enabled or disabled? Was the USB cable still plugged into the PC when running gallery? Essentially, the SDCard can only be viewed by the PC or the phone, and not both at the same time. Once you've started sharing the SDCard, you MUST unplug the USB cable before the phone will see any new files. If USB Mass Storage is disabled, you can then replug the USB cable back into the PC and the phone will continue to see the SDCard.
Triage: partner confirmed between step 1 and 2, the usb cable is unplugged from the device. partner will upload video files
First USB Mass Storage enabled in device，then connect Device and PC through USB cable. In PC，we can see the the content of SDcard. Copy the video in the attachment into files such as"sdcard/DCIM/100MZLLA ". Unplug the USB cable,then open Gallery to see if this video is in the list. But unfortunately,this video can not be in the list.
Triage: BB+, P3 - target market customer (In reply to Firefox_Mozilla from comment #3) > Created attachment 695947 [details] > video can not read the attached file seem to be an audio only file in .3gp format? my commercial android phone does not load this in gallery app either based on codec information it's: MPEG-4 ODSM, MPEG-4 SDSM, AMR Narrowband did you attach the wrong file?
blocking-basecamp: ? → +
Priority: -- → P3
set the priority and blocking-basecamp by accident, meant to say only the below the attached file seem to be an audio only file in .3gp format? my commercial android phone does not load this in gallery app either based on codec information it's: MPEG-4 ODSM, MPEG-4 SDSM, AMR Narrowband did you attach the wrong file?
blocking-basecamp: + → ?
Priority: P3 → --
Triage: blocking- The gallery app should only show photos and videos that were captured with the device, so we do not expect an imported file to be available from the Gallery. Please re-nominate if this is a supported video format and it is not showing up in the Video application.
blocking-basecamp: ? → -
Triage: issue reporter will confirm again
We test only video that were captured with the device are shown in Gallery. Other video such as the attachment"MM_ST_CDEC_MP4_0001_NXT.3gp" are not shown in Gallery. Is it by design?
Seems like the video file will appear in video app but not in gallery app
Assignee: nobody → dkuo
tracking-b2g18: --- → ?
QA Contact: jhammink → atsai
I have took a quick look on the metadata parsers in Video and Gallery, and found that Video app records videos to MediaDB by using the "loadedmetadata" event of the video tag, and Gallery app uses the "seeked" event. And because the seeked event is not fired after Gallery seek 1 second to the offscreenVideo, so the logic that records the metadata will not be executed, and means MediaDB didn't successfully record that video. That's why we were unable to see the attached video in Gallery but Video. Ccing David, the author of Gallery. David, feel free to take this because you should know Gallery and Video better than me, or I can fix this if you are blocked on other bugs.
blocking-b2g: --- → tef?
This may be expected behavior, but regardless, the user can still play their desired video. Not tef+
blocking-b2g: tef? → -
tracking-b2g18: ? → +
(In reply to Dominic Kuo [:dkuo] from comment #12) > I have took a quick look on the metadata parsers in Video and Gallery, and > found that Video app records videos to MediaDB by using the "loadedmetadata" > event of the video tag, and Gallery app uses the "seeked" event. > > And because the seeked event is not fired after Gallery seek 1 second to the > offscreenVideo, so the logic that records the metadata will not be executed, > and means MediaDB didn't successfully record that video. That's why we were > unable to see the attached video in Gallery but Video. The reason the gallery seeks one second into the video is that it wants to take a screenshot one second into the video to use as its thumbnail. I think that was part of the initial UX design. I wonder why the seek event is not being delivered. Is it because the video is in a format that we cannot actually play? Or is the test video less than one second long? If we're not getting a seek event for the video, it makes me nervous about adding the video to the database, because I'm not sure we're going to be able to play it back correctly. It would be nice to know what is going wrong here, but as other have noted, it is low priority, I think. Copying videos into the DCIM directory is not a user feature that we need to support. If this is blocking testing by one of our partners, that might be different. > Ccing David, the author of Gallery. > David, feel free to take this because you should know Gallery and Video > better than me, or I can fix this if you are blocked on other bugs.
Here's another thought: the Video app plays videos with hardware decoding. The gallery app plays videos with software decoding. So it is possible, I suppose, that there are some videos that can be played in one app and not in another. I don't know enough about video codecs to assess whether the attached .3gp video is different in any way from the .3gp videos that our camera records. Firefox_Mozilla@126.com: thanks for the attachment. Next time, remember to set the mime type. This one is attached as text/plain. I can still save it and play it, though.
Just a fyi, speaking with jcarpenter during work week on this specific issue in terms of ux design: - Only videos taken from the phone should be in the gallery. - All videos on the phone should be shown in the video app. At least this is what I recall.
Naoki, Yes, that's what we do. The way we tell whether a video came from the camera is if it is in the DCIM directory and ends .3gp. Occasionally it is useful for testing to copy a file to that directory. I don't know who the reporter of this bug is, but if it is someone from one of our partners who needs this bug resolved for testing, that would give it higher priority.
This bug is invalid. Per Naoki, in comment #16, the intended behavior is as follows: * The only videos displayed in the Gallery are those taken from the device Camera. * All videos—whether shot from the Camera or loaded on the SD card—are displayed in the Video app. The user in the scenario from comment #1 would need to know—or learn—that their videos are the Video app. Again, this is a deliberate design decision. (In reply to David Flanagan [:djf] from comment #17) > I don't know who the reporter > of this bug is, but if it is someone from one of our partners who needs this > bug resolved for testing, that would give it higher priority. It's from a partner, but we're also cleared to close invalid bugs, per a Dec 25 email from Kevin Hu to project drivers. Adding Kevin for needsinfo. Kevin, what's the process for closing partner bugs like this?
Flags: needinfo?(jcarpenter) → needinfo?(khu)
(In reply to Josh Carpenter [:jcarpenter] from comment #18) > Kevin, what's the process for closing partner bugs like this? I have regular bug review meeting with this partner. Based on Naoki's comment #16, we have an agreement on the expected behavior before and I will close this bug for now.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.