1010472 - [B2G][Camera][Video] Battery level dropping to 5% while recording a video, loses the video

Status: RESOLVED WORKSFORME

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

Description

[Roland Kunkel [:RolandK]]

Description:
When the user is recording a video in the camera app with their battery level >5%, while recording, if their battery level drops <5% the recording is stopped and their video is not saved.

Repro Steps:
1) Update a Flame device to BuildID: 20140514000204
2) Make sure the device's battery percentage is <5%, (6 - 10%)
3) Camera app > Start recording a video
4) Allow the device's power drop <5%
5) Observe "The battery is too low to use camera" warning obscures the screen and user is unable to save their video
6) Observe that the device does not automatically save the video

Actual:
The video is not saved when the battery percentage drops <5%

Expected:
While using the camera if the phone's battery is at or below 5% the photo or video file to be saved so that file doesn't get corrupted     

v1.4 Environmental Variables:
Device: Flame v1.4 MOZ RIL
BuildID: 20140514000204
Gaia: b40103dec34a147c9018a1af76eb21c3184f2f93
Gecko: 7788969f70b0
Version: 30.0
Firmware Version: V10F-3

Notes: I am unable to retrieve a logcat as the USB connection charges the phone...

Repro frequency: 100%
See attached: video clip

Comment 1

[Roland Kunkel [:RolandK]]

Video url: https://www.youtube.com/watch?v=rF8ktiDKkJo&feature=youtu.be

Comment 2

[Jason Smith [:jsmith]]

Does this reproduce on 1.3?

Comment 3

[Cody Roesch [:croesch]]

This bug does NOT happen on Flame Base 1.3.
The camera app keeps recording past 5% until the phone actually shut down.

Environmental Variables
Device: Flame V1.3 Base Image
Build ID: 20140505215459
Gecko: b637b0677e15318dcce703f0358b397e09b018af/rev/
Gaia: ec462dc62979dae593b4ad96ac3851ccbafe1813
Platform Version: 28.0
Firmware Version: v10F-3

Comment 4

[Jason Smith [:jsmith]]

This sounds intentional potentially.

UX - Can you clarify the expected behavior here?

Comment 5

[Stephany Wilkes]

I recall, from the Long Long Ago, from The Time Before, a bug about 10% thresholds and low battery warnings, but only vaguely. Flagging Tif on expectations here while a large # of the UX team is on the road.

Comment 6

[Tiffanie Shakespeare [:tif]]

Attachment: camera v1.5 - low battery.pdf

There are three points when we briefly show a message about the battery getting low - 15%, 10%, 6%.

Once the battery drops to 5%, we show a full screen message and the user is unable to continue to use the camera app. At this point, video should stop recording and save.

Comment 7

[Tiffanie Shakespeare [:tif]]

Btw - the video looks correct as far as the UI goes (assuming the critical message is shown at 6% and the full screen is at 5%). 

We just need to make sure the video is getting saved.

Comment 8

[Jason Smith [:jsmith]]

Okay - This is a bug that we should fix, but I don't think I'd hold a release on this, mainly because the updated behavior isn't that bad.

Comment 9

[Tiffanie Shakespeare [:tif]]

If the videos aren't being saved or are corrupted, it should block the release. Isn't that what this bug is about?

Comment 10

[Stephany Wilkes]

Videos must save. I would nominate this to block if videos are not saving.

Comment 11

[Mike Habicher [:mikeh] (high bugzilla latency)]

I thought I saw something mentioned in another bug where we deliberately delete partially-recorded videos under some circumstances. I can't remember the bug number, however. :(  Wilson/Justin: do you know what I'm talking about?

Comment 12

[Stephany Wilkes]

Thanks, Mike. It would be great if we could find that. For the user, I am not sure they think of a video as partially recorded or not - rather like the popular "there's no such thing as being a little bit pregnant." The UX we want to avoid is a user thinking they've recorded a video, especially one of a moment that can't be repeated (a wedding, a child's ballet performance, a baby walking for the first time) only to find that it did not actually record. Thanks for looking into this!

Comment 13

[Justin D'Arcangelo [:justindarc]]

(In reply to Mike Habicher [:mikeh] from comment #11)
> I thought I saw something mentioned in another bug where we deliberately
> delete partially-recorded videos under some circumstances. I can't remember
> the bug number, however. :(  Wilson/Justin: do you know what I'm talking
> about?

Mike: I can't find the bug either but the only time we intentionally don't save the video is if it less than 1 second long. In those cases, the video file becomes corrupt. I suppose it's possible though that something is happening in this low battery case that we aren't handling properly. I'll check into it.

Comment 14

[Jason Smith [:jsmith]]

Based on UX input, I think this is unintentional data loss outside of user's control, as they lose the video they were recording on a low battery.

Comment 15

[Jason Smith [:jsmith]]

Adding window wanted to find out when this behavior changed.

Comment 16

[Wilson Page [:wilsonpage]]

mikeh: Correct. If videos are under 1 second long they are deleted instantly. We used to not save if the video was under 1 sec, but this lead to other issues. We found it easier to complete the usual new video flow and delete after.

I have simulated this low battery scenario and am unable to reproduce with these steps:

1. Start the recording
2. Create a fake battery object and set it to 5% charge
3. Update the battery status

OUTCOME

Overlay shows and video stops recording. Video is present and playable in gallery app.

It is particularly difficult to reproduce this bug for real. Has anyone else has any success?

Comment 17

[Preeti Raghunath(:Preeti)]

Please review

Comment 18

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Stephany Wilkes from comment #12)
>
> Thanks, Mike. It would be great if we could find that.

I can't find the bug anymore. It's possible I may have misread a different bug--I was sorting through a few thousand emails yesterday. I'll keep looking, and will update this bug if I find anything.

Comment 19

[Justin D'Arcangelo [:justindarc]]

Unable to reproduce this on the latest 1.4 build:

Gaia      93623f6435849cc9f54d9996e8e64828ac9091d1
Gecko     https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/12fe2b67a099
BuildID   20140521000202
Version   30.0

Also unable to reproduce on latest master (2.0) build.

DISCLAIMER: I did not wait for my battery to actually hit <5% -- I cheated and triggered the low battery event manually through the JS console in App Manager. However, in doing so, it did stop the recording (you could hear the stop-recording sound) and it threw up that full-screen overlay saying "The battery is too low to use the camera".

Comment 20

[Justin D'Arcangelo [:justindarc]]

In case anyone else wants to try this, in the JS console using App Manager, you can run the following code to simulate the <5% battery event:

`app.set('batteryStatus', 'shutdown')`

Comment 21

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

I have worked with reporter and we are unable to reproduce this issue on the latest 1.4 Flame Build.  Videos were saved as expected when the critically low battery message appeared.

Environmental Variables:
Device: Flame
BuildID: 20140521003002
Gaia: 93623f6435849cc9f54d9996e8e64828ac9091d1
Gecko: 12fe2b67a099
Version: 30.0
Firmware Version: V10F-3

Comment 22

[Justin D'Arcangelo [:justindarc]]

(In reply to Jayme Mercado from comment #21)
> I have worked with reporter and we are unable to reproduce this issue on the
> latest 1.4 Flame Build.  Videos were saved as expected when the critically
> low battery message appeared.
> 
> Environmental Variables:
> Device: Flame
> BuildID: 20140521003002
> Gaia: 93623f6435849cc9f54d9996e8e64828ac9091d1
> Gecko: 12fe2b67a099
> Version: 30.0
> Firmware Version: V10F-3

I'm going to go ahead and close this issue now since both the reporter and I have been unable to reproduce using the latest builds.

Comment 23

[Jason Smith [:jsmith]]

Moving to wfm since there isn't a patch here.