Closed Bug 817939 Opened 7 years ago Closed 7 years ago

[FM Radio] Turn on the FM Radio and then sleep the phone for a while, the UI will inconsistent to interaction

Categories

(Core :: DOM: Device Interfaces, defect, P2)

ARM
Gonk (Firefox OS)
defect

Tracking

()

RESOLVED FIXED
B2G C4 (2jan on)
blocking-basecamp +
Tracking Status
firefox19 --- wontfix
firefox20 --- fixed
firefox21 --- fixed
b2g18 --- fixed

People

(Reporter: johnshih.bugs, Assigned: sinker)

References

Details

Attachments

(1 file, 2 obsolete files)

## Environment :
Unagi phone, build 2012-12-03
Build info: 
gaia master : 5d150b2b10472478e8841730abd9ae9597595206
mozilla-beta : 1e56f66d7ee9

## Repro :
1. Launch the FM Radio with headphone plugged-in
2. Check can listen to the Radio through the headphone
3. Sleep the phone for about 2~ minutes
4. Wake the phone and unlock the lockscreen
5. Back to FM Radio, hit the next/previous button to switch the channel

## Expected:
* After searching for a few seconds, radio will switch to next/previous channel and displays the frequency on screen

## Actual:
* Hear the radio is change to different channel
* The frequency displayed on screen won't change
* The searching animation is keep active
* Hit the next/previous buttons several times will see the frequency change inconsistently (Please the the video in attachment)
Due to the file is too large and the problem in youtube (can't upload video), I'll upload later
blocking-basecamp: --- → ?
blocking-basecamp: ? → +
Priority: -- → P2
Assignee: nobody → schung
Hi John,
I could not reproduce it with 12/09 unagi build.
Could you please verify with this version? thanks.
Hi Pin,
Can you look this bug?
Target Milestone: --- → B2G C3 (12dec-1jan)
(In reply to StevenLee from comment #4)
> Hi Pin,
> Can you look this bug?

I can't reproduce this issue either.
yeah, seems like this has been fixed by some modification
closing

2012-12-11 Unagi
gaia master : d6aaf482785f51eed6d9e38080d140a078e902c2
mozilla-beta : 32929d7d0a1f
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
since can't find the core reason for this bug, and it still can be reproduced sometimes so reopen the bug
I'll spend time to find more information about this bug
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Hi John,
Since I still could not reproduce this issue, I added some debug message in FM DOM api to verify the root cause that is seek success event missed from beck-end or error while Service.DOMRequest.fireSuccess. I can flash the debug version gecko for you, thanks.
Keywords: qawanted
Try it w/ 12-16 Engineer Nightly build on unagi.
Cannot reproduce it.
I found it can not be reproduced after the device just flashed, but after reboot (several times) it can still happen
Thanks for your help, Al.

Hi John,
You mean it may still happen if reboot several times. Could it always be reproduced after that?
I can reproduce it after reboot my unagi
Driver retriage: Steve, can you work directly with Al to figure out how to reproduce this? If it's reproducible and still bad, please re-nominate for blocking.
blocking-basecamp: + → -
tracking-b2g18: --- → +
Currently, the only way to reproduce it is to reboot the machine and do the steps in description. It happens sometimes. We'll keep following the issues and try to give the steps for always reproduce it.
Duplicate of this bug: 805710
(In reply to Dietrich Ayala (:dietrich) from comment #13)
> Driver retriage: Steve, can you work directly with Al to figure out how to
> reproduce this? If it's reproducible and still bad, please re-nominate for
> blocking.

I can reproduce and the app seems broken when it happens. Nominating again.
blocking-basecamp: - → ?
(In reply to Vivien Nicolas (:vingtetun) from comment #16)
> 
> I can reproduce and the app seems broken when it happens. Nominating again.

Hi Vivien, May I know which build are you testing now?
I'm testing the latest b2g18-unagi_betatest(1/6), but it still works for me. Is the reproduce step as simple as Al said(just reboot the device) or need any other action to make it reproducible? And how the reproduce rate? Thanks.
blocking-basecamp: ? → +
tracking-b2g18: + → ---
Target Milestone: B2G C3 (12dec-1jan) → B2G C4 (2jan on)
I followed the steps to reproduce the problem, and the searching indicator is always shown, but the frequency is changed consistently.
Assignee: schung → pzhang
(In reply to Pin Zhang [:pzhang] from comment #18)
> I followed the steps to reproduce the problem, and the searching indicator
> is always shown, but the frequency is changed consistently.
I can't reproduce it now, @@
Hi Vivien, is it always producible on your device? And what's the commit numbers of both the Gecko and Gaia?
If I opened console to see log messages, i.e `adb logcat`, the problem can not be reproduced; and if I unplugged the USB cable, it's reproducible on Vivien's device.
It should be the time issue that we encountered before, and I think I need Steven's help.
(In reply to Pin Zhang [:pzhang] from comment #21)
> If I opened console to see log messages, i.e `adb logcat`, the problem can
> not be reproduced; and if I unplugged the USB cable, it's reproducible on
> Vivien's device.
> It should be the time issue that we encountered before, and I think I need
> Steven's help.

Hi Steven, if the problem happens, the seek complete event is not fired, that's why the searching indicator is always shown, can you take a look at thia?
Sounds like a driver bug.
Component: Gaia::FMRadio → DOM: Device Interfaces
OS: Mac OS X → Gonk (Firefox OS)
Product: Boot2Gecko → Core
QA Contact: jshih
Hardware: x86 → ARM
QA Contact: jhammink
(In reply to Pin Zhang [:pzhang] from comment #21)
> If I opened console to see log messages, i.e `adb logcat`, the problem can
> not be reproduced; and if I unplugged the USB cable, it's reproducible on
> Vivien's device.
> It should be the time issue that we encountered before, and I think I need
> Steven's help.
Actually, if I just plug the phone with the USB cable , no need to run `adb logcat` in the console, the problem won't happen.
The version of the Vivien's Device is :
   Linux version 3.0.8-perf (songsy@ubuntu-cdr) (gcc version 4.4.3 (GCC) ) #1 PREEMPT Tue Oct 16 07:34:52 PDT 2012

The kernel version is not the latest, and the problem can be always reproduced, and it also happens sometimes on the latest version, still don't know the pattern to reproduce it on the latest version.
I have noticed this for a long time, both happen on the new and old kernel
the only difference is that how hard it can be reproduced
talked to Thinker to take over the bug
Assignee: pzhang → tlee
I downgraded to kernel-update-3 and found that the STR is 
1. launch fm radio with headset inserted
2. seek to a station
3. unplug usb cable
4. press power key to enter sleep mode and wait several seconds
5. press power key again and go to FM radio app
6. seek

When the problem happens, I plug usb cable and check my log. I found the driver does not callback data anymore. I think it should be the driver's fault.
--
Attachment #699208 [details] [diff] - Attachment is obsolete: true
Attachment #699208 - Attachment is obsolete: true
(In reply to Thinker Li [:sinker] from comment #30)
> Created attachment 699214 [details] [diff] [review]
> restart ioctl with EINTR for FMRadio
> 
> --
> Attachment #699208 [details] [diff] [diff] - Attachment is obsolete: true

I tested the patch, it works fine now.
Attachment #699214 - Flags: review?(justin.lebar+bug)
tested with the patch also, it works fine.
Keywords: qawanted
Comment on attachment 699214 [details] [diff] [review]
restart ioctl with EINTR for FMRadio

Oh, I understand what this does!  :)
Attachment #699214 - Flags: review?(justin.lebar+bug) → review+
(In reply to Justin Lebar [:jlebar] from comment #33)
> Comment on attachment 699214 [details] [diff] [review]
> restart ioctl with EINTR for FMRadio
> 
> Oh, I understand what this does!  :)

cool!! And thank you!
--
Attachment #699214 [details] [diff] - Attachment is obsolete: true
Attachment #699214 - Attachment is obsolete: true
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.