I observed this 'error' while trying to reproduce bug 820139 (which I was not able to, BTW). Putting the camera into video-recording mode and tapping the Start button causes this error to appear on the screen, and no video is recorded. logcat shows: E/AudioHardwareMSM76XXA( 418): More than one instance of recording not supported E/AudioRecord( 899): Could not get audio input for record source 5 E/GonkRecorder( 899): audio source is not initialized E/MPEG4Writer( 899): Stop() called but track is not started E/VENC_OMX( 899): OMX_VENC_MSG_HIGH component_deinit::3278 deinitializing component... E/VENC_ENC( 899): VENC_MSG_HIGH venc_unload::1175 Received command VENC_CMD_UNLOAD E/mm-camera( 899): discard frame preview,discard_frame_cnt=0 E/VENC_ENC( 899): VENC_MSG_HIGH venci_process_command::4524 Processing command VENC_CMD_UNLOAD E/VENC_OMX( 899): OMX_VENC_MSG_HIGH process_DL_status::4899 got DL status for VENC_CMD_UNLOAD E/VENC_ENC( 899): VENC_MSG_HIGH venc_sys_down::4727 Killing command thread E/VENC_ENC( 899): VENC_MSG_PROFILE venci_process_command_unload::2665 Encoder time taken to Exit from Stop command: 37860 E/ ( 899): OMX_VENC_MSG_HIGH ~VencMsgQ::155 mutex destroy for VencMsgQ 0x0 E/ ( 899): OMX_VENC_MSG_HIGH ~VencMsgQ::164 Signal destroy for VencMsgQ 0x0 E/VENC_OMX( 899): OMX_VENC_MSG_HIGH component_deinit::3374 Encoder exit E/VENC_OMX( 899): OMX_VENC_MSG_HIGH ~Venc::223 OMX-ENC:-destructor The error seems to be related to the audio path. The error message can be dismissed, but once this error appears, video cannot be recorded. Switching to picture mode and back does not clear the error state. Tapping the Start button again causes the same error message(s) to appear on the screen and in the logcat. Also, force-closing the camera and restarting it does not clear the error state either!
blocking-basecamp: --- → ?
Assignee: nobody → mhabicher
blocking-basecamp: ? → +
I have not been able to reproduce this error since encountering it. Will likely not have a patch before the Target Milestone.
I saw this error during smoketesting today, and it is happening even after I restarted the phone. This is using Gaia: b4bcf70792f4 Gecko: e261861b0270
Hi Marcia, any ideas on steps to reproduce?
Mike: The odd thing is that I was able to reproduce it, but I don't for sure what triggered it. In my case I shot a series of 8-9 short videos, and was quickly pressing the record button as soon as each recording finished. At some point I just would get that error. I will continue to test this as I will be running smoketests the rest of this week. (In reply to Mike Habicher [:mikeh] from comment #3) > Hi Marcia, any ideas on steps to reproduce?
QA Contact: mozillamarcia.knous
I reproduced it again today during smoketesting, using the 12-27 nightly unagi build. I noticed it started happening after I did an operation in the camera app and ended up launching contacts. Following that I kept getting the error in succession when I tried to launch the video record mode. This bug never happens the first few times you record. It only happens when you spend a fair amount of time recording videos in the camera app.
(In reply to Josh Matthews [:jdm] from comment #0) > STR: > 1. open camera app > 2. visit gallery > 3. return to camera > 4. start video recording > > Expected: > Video records. > > Actual: > Video fails to record, error message appears: "Video not recorded. An error > prevented Camera from recording the video." > > If you switch to the still camera and back, the video records fine.
Oddly, I added the STR in Comment 7 when I duped the bug and the text did not show up. Bugzilla is behaving very strangely.
Sometimes I see a crash as well when following the STR mentioned in Comment 7. Though the callstack in the minidump is not helpful at all. Strangely it doesn't show any relevant symbols for the crash.
I/PRLog ( 7602): 1074599160: mozilla::StartRecordingTask::StartRecordingTask(mozilla::CameraControlImpl*, mozilla::dom::CameraStartRecordingOptions, nsIFile*, const nsAString_internal&, nsICameraStartRecordingCallback*, nsICameraErrorCallback*, uint64_t):433 : this=446ca650 I/PRLog ( 7602): 1304816[44822b00]: virtual nsresult mozilla::StartRecordingTask::Run():443 I/PRLog ( 7602): 1304816[44822b00]: [Child 7602] WARNING: NS_ENSURE_TRUE(mRecorderProfile) failed: file /home/cjones/mozilla/new-b2g/gecko/dom/camera/GonkCameraControl.cpp, line 856 I/Gecko ( 7602): [Child 7602] WARNING: NS_ENSURE_TRUE(mRecorderProfile) failed: file /home/cjones/mozilla/new-b2g/gecko/dom/camera/GonkCameraControl.cpp, line 856 I/PRLog ( 7602): 1304816[44822b00]: virtual nsresult mozilla::StartRecordingTask::Run():445 : result -1041039359 I/PRLog ( 7602): 1304816[44822b00]: virtual mozilla::StartRecordingTask::~StartRecordingTask():438 : this=446ca650
Simpler STR (1) Launch camera (2) Switch to video mode (3) Press HOME button (4) Tap camera to bring to foreground (5) Press record button Looks like it might be a gaia "bug" ...
Assignee: mhabicher → jones.chris.g
Component: General → Gaia::Camera
Created attachment 698893 [details] [diff] [review] Switch back to record mode when unhidden if we were in record mode when hidden
Attachment #698893 - Flags: review?(dale)
(In reply to Inder from comment #9) > Sometimes I see a crash as well when following the STR mentioned in Comment > 7. Though the callstack in the minidump is not helpful at all. Strangely it > doesn't show any relevant symbols for the crash. Strongly suspect that the crashes are bug 826829.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #13) > Created attachment 698893 [details] [diff] [review] > Switch back to record mode when unhidden if we were in record mode when > hidden Weird--I could have sworn we fixed this (or something like this) a while back. Thanks, Chris.
Comment on attachment 698893 [details] [diff] [review] Switch back to record mode when unhidden if we were in record mode when hidden We had fixed this elsewhere earlier, missed a case, thanks Chris
Attachment #698893 - Flags: review?(dale) → review+
(In reply to Dale Harvey (:daleharvey) from comment #16) > > We had fixed this elsewhere earlier, missed a case, thanks Chris Oh good, I'm not going crazy.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.