Closed Bug 868891 Opened 8 years ago Closed 8 years ago

Video media DB can't get camera recording file.

Categories

(Firefox OS Graveyard :: General, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(blocking-b2g:tef+, firefox20 wontfix, firefox21 wontfix, firefox22 wontfix, firefox23 fixed, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 verified)

RESOLVED FIXED
1.1 QE2 (6jun)
blocking-b2g tef+
Tracking Status
firefox20 --- wontfix
firefox21 --- wontfix
firefox22 --- wontfix
firefox23 --- fixed
b2g18 --- fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- verified

People

(Reporter: leo.bugzilla.gecko, Assigned: dhylands)

References

Details

(Keywords: regression, Whiteboard: [fixed-in-birch])

Attachments

(2 files)

delete all video file. 
start Video -> "Load videos on to the memory card" Text view -> Home Key -> Camera -> change recording mode -> Record Complete -> Home Key -> Video  
still "Load videos on to the memory card" View 
close video and restart video -> can see record video file view

test version info 
Software : 1.1.0.0-prerelease
Build ID : 20130429070204
Current STR is unclear, please clarify and also provide expected behavior.
Flags: needinfo?(leo.bugzilla.gecko)
The thumbnail is not update during video app is alive.
After you start the video app and the gallery app, take a video using camera app.
When you launch the Gallery, you can see the new video file.
But you can't find the new video file in video app.

You can see the new video file after restart the video app.
Flags: needinfo?(leo.bugzilla.gecko)
Triage - getting STR from reporter:

1. Start video app
2. Home
3. Start camera app and record video
4. Home
5. Start video app

In Step 5, the video recorded in step 3 cannot be seen within Video app.
Keywords: qawanted
It looks strange. If you see closely to the left-top, you can find video app already got parsed. But just the cover doesn't disappear.
Sorry, I found last comment (comment #4) may not be always correct. It sometimes shows but somethings not.
Can you never see the video in video app or just on first launch after capturing?  Being able to see it in Gallery app listing is a strong case for not blocking here.
Using Inari device and:

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/66334a3bddcb
Gaia   186d31782d8cadb296661a7d104bc28846d1dfb9
BuildID 20130508070204
Version 18.0

I get inconsistent results.

The video does show up in the filmstrip and in gallery, but doesn't always show in my list of videos. 

Unlike Comment 0, I did not delete any of the existing videos in the video app before beginning.

Following STR in Comment 3, the first two times I opened the video app the videos were not there. When I opened it a third time, the videos I recorded the previous two times now showed.
Keywords: qawanted
Pretty sure this still has to do with the video app being opened in the background during the time you filmed or not.

Please make sure you close out the video app in the background.

bug 836783 eludes to this.  This occurs for Video app still, I think it may still happen for music?  Not sure.

You should have consistant results, that if the video app is still running the videoes do not show.  If the video app is not running in the background, after shooting, you should see the videos in the video app.
Gallery app uses different way to monitor the event of filmed video. In Video app, it uses DeviceStorage API for listening the change of video files. But in gallery, it uses photo created by Camera app to do it. see: https://github.com/mozilla-b2g/gaia/blob/master/apps/gallery/js/gallery.js#L217.

It is possible to use the same mechanism to do so. But this needs the confirmation of the module owner. I am just new to here and can't make sure it is the correct idea.
BTW, 

The logic of video is using mediadb.js. And I think the logic in mediadb.js is correct.
There is a strange thing here. 
The DeviceStorage dispatches a modified and a deleted event at the same time while we tap the record button of Camera. like: 

E/GeckoConsole(  522): Content JS LOG at app://video.gaiamobile.org/shared/js/mediadb.js:528 in deviceStorageChangeHandler: filename: DCIM/100MZLLA/.VID_0019.3gp, reason: modified
E/GeckoConsole(  522): Content JS LOG at app://video.gaiamobile.org/shared/js/mediadb.js:528 in deviceStorageChangeHandler: filename: DCIM/100MZLLA/.VID_0019.3gp, reason: deleted

And when we stop recording, it dispatches another modified event with empty file name, like:

E/GeckoConsole(  522): Content JS LOG at app://video.gaiamobile.org/shared/js/mediadb.js:528 in deviceStorageChangeHandler: filename: , reason: modified

According to the logic of mediadb.js, a video record will be parsed while a modified event got, and a video record will be deleted while a deleted event got. So, if the last event dispatched with the correct filename, video app may get the record film.
Flags: needinfo?(dflanagan)
John,

Thanks for reporting this. Your diagnosis in comment 10 is very helpful.

When you first tap the record button in the camera, it creates and deletes a file just to ensure that the directory is created.  Note that the file begins with ".". That means that mediadb will ignore it and not tell the video app about it.

Then as the video is recorded, the camera hardware creates the real video file. It does not use the DeviceStorage API but is supposed to report the new file to DeviceStorage so that MediaDB will know about it and can tell the Video app about it.

This used to be broken. Then it was fixed. Now it appears to be broken again.

Mike or Doug will fix it for us, I hope. Mike and Doug: could you take a look at this? Any idea why device storage would be sending a notification about a file with an empty string for its name?

This breaks the Camera->Video app communication and should probably be a leo+ blocker.
Flags: needinfo?(mhabicher)
Flags: needinfo?(doug.turner)
Flags: needinfo?(dflanagan)
The code that sends the event is in a runnable thrown from StopRecordingImpl()[1], and it looks like that's working.  The 'aSubject' of the message is of type nsRefPtr<DeviceStorageFile>[2], which also looks correct--at least, compared to Bluetooth[3].

1. http://hg.mozilla.org/mozilla-central/annotate/ea059733677c/dom/camera/GonkCameraControl.cpp#l953
2. http://hg.mozilla.org/mozilla-central/annotate/ea059733677c/dom/camera/GonkCameraControl.cpp#l958
3. http://mxr.mozilla.org/mozilla-central/source/dom/bluetooth/BluetoothOppManager.h#194

'mVideoFile', which sets 'aSubject', is set in StartRecordingImpl()[4].

4. http://mxr.mozilla.org/mozilla-central/source/dom/camera/GonkCameraControl.cpp#908

It looks like that was changed on April 18[5].

5. http://hg.mozilla.org/mozilla-central/diff/1071ca655e43/dom/camera/GonkCameraControl.cpp
Flags: needinfo?(mhabicher) → needinfo?(dhylands)
Assignee: nobody → dhylands
There seems to be 2 problems here.

One was introduced by bug 860934. That turns out to be a one-line fix.

But in my testing, I wasn't able to get deviceStorageChangeHandler to be called when recording a video. I tracked this down to the fact that the listener is listening on getDeviceStorage('pictures'), but the video is being saved in getDeviceStorage('videos'), so because the types mismatch, the change event doesn't get sent.

I observed the above in m-c and b2g18.

The steps I performed:
- boot phone
- launch camera app
- press video button to switch from stills mode to video mode
- press video button again to start recording
- press video button again to stop recording

I noticed that the timer text (for when it was recording) in b2g18 was considerably smaller than in m-c
Flags: needinfo?(dhylands)
OK - I was able to reproduce using the Video App - Doh.

Patching coming real soon now.
blocking-b2g: leo? → leo+
I think that this need to be tef+ since it's a regression caused by bug 860934, which was tef+.

If you disagree, that's fine, we can set it back to leo+.
blocking-b2g: leo+ → tef?
I need to code up a test for this.
Attachment #747689 - Flags: review?(doug.turner)
Blocks: 859171
Attachment #747689 - Flags: review?(doug.turner) → review+
https://hg.mozilla.org/mozilla-central/rev/096bac1de6ee
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
blocking-b2g: tef? → tef+
Keywords: regression
I can still reproduce this bug on Leo.

Build ID: 20130512070206
Gecko revision: 3bed81ce628db3b4bb3500582a672e49de226fad (hg changeset 119369:bfba8196af9d)

--
I observed that video app updates dialog before metadata parsing and addVideo() finish, so 'no video' overlay remains showing. Attached patch makes video app update dialog after adding the first video and go back to thumbnail list view after deleting the last video.

David, can you review the attached patch?
Attachment #749786 - Flags: review?(dflanagan)
Ben, please don't attach a gaia patch to a closed gecko bug. Please open a new bug. It's fine to make the new bug block this bug.

I think that you're probably running into bug 872170.
Comment on attachment 749786 [details] [diff] [review]
link to https://github.com/mozilla-b2g/gaia/pull/9783

Sorry - but I have to r- this patch (it has nothing to do with the patch).

The problem is that its a gaia patch attached to a FIXED gecko bug, so it messes up all of the scripts used by sheriffs working on the gecko tree.

Please open a new bug.
Attachment #749786 - Flags: review?(dflanagan) → review+
Component: Gaia::System → General
Comment on attachment 749786 [details] [diff] [review]
link to https://github.com/mozilla-b2g/gaia/pull/9783

pick r- - Doh
Attachment #749786 - Flags: review+ → review-
Issue as described in STR of comment 3 does not repro on v101.

Environmental  Variables:
Inari Build ID: 20130530070213
Mozilla RIL
Kernel Date: Feb 21
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/11b55d3ada71
Gaia: ac293ce59acc3bede083fad1b973794fa8bf0253
Flags: needinfo?(doug.turner)
You need to log in before you can comment on or make changes to this bug.