[B2G][Flame]Volume level is very low at max setting

VERIFIED FIXED in Firefox OS v2.1

Status

Firefox OS
AudioChannel
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: bkerensa, Assigned: gerard)

Tracking

({dogfood, regression})

unspecified
2.1 S5 (26sep)
ARM
Gonk (Firefox OS)
dogfood, regression
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.1+, b2g-v2.1 verified, b2g-v2.2 verified)

Details

(Whiteboard: [2.1-flame-test-run-2][fullflash-smoketest])

Attachments

(3 attachments)

(Reporter)

Description

3 years ago
When making calls the volume level at max is very low and it is much harder to hear calls then on other platforms. Tested with nightly on a Flame handset.
(Reporter)

Comment 1

3 years ago
Version: 2.1.0.0-prerelease
Platform: 34.0a1
Build: 20140805040204
Component: General → AudioChannel
Summary: Volume level is very low → [b2g] Volume level is very low at max setting
(Reporter)

Comment 2

3 years ago
[Blocking Requested - why for this release]:
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Summary: [b2g] Volume level is very low at max setting → [B2G][Flame]Volume level is very low at max setting
(Reporter)

Comment 3

3 years ago
[Blocking Requested - why for this release]: Call volume is too loud on max setting to the point user cannot hear other caller.
blocking-b2g: --- → 2.1?
Paul: do you know who could help us with this?
Flags: needinfo?(paul)
(Reporter)

Comment 5

3 years ago
I just tested the volume again and I put it at one bar and the volume level seems identical and when I increased it to max during the call there was no noticeable change in volume. Mind you I noticed someone on Twitter said the lowest volume setting is too loud on the Flame.
302 mwu, this is out of my area of expertise.
Flags: needinfo?(paul) → needinfo?(mwu)
Requesting qawanted for branch checks.

Not only is the volume far too low, the volume controls do not change the volume. It's the same level of too-quiet whether the controls are at the highest or lowest point.
Keywords: qawanted, regression, regressionwindow-wanted
Dietrich - are you sure this is a regression already? I've only seen info for it occurring on 2.1 and no evidence of anyone checking 2.0 or 1.4 yet.
Flags: needinfo?(dietrich)
Hm, I'm not sure. I seem to remember it being louder before. But human senses and memory are a lie.
Flags: needinfo?(dietrich)
Hah. Fair enough. Branch checks are under-way.
Can you please provide the base version you were using?  I was unable to repro on the same nightly build nor on today's engineering builds for 2.1 or 2.0.

2.1 nightly
BuildID: 20140805040204
Gaia: 19bf9795263e2ccc15d824a52ebf23c2670fa9b9
Gecko: 7f81be7db528
Platform Version: 34.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

2.1 engineering
BuildID: 20140814004506
Gaia: 5e074831f9ddacdf6f622a6dffaecb626f740be8
Gecko: de1d3c229e5a
Platform Version: 34.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

2.0 engineering
BuildID: 20140814024604
Gaia: d889984833025f208cfd3f3c2c37c87940a529dc
Gecko: abdb13f41d68
Platform Version: 32.0
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Flags: needinfo?(bkerensa)
(Reporter)

Comment 12

3 years ago
2.1 User
BuildID: 20140814040202
Platform: 34.0a1

Not sure how to grab the Firmware or Gaia info. But Dietrich and others have been able to reproduce on their own hardware too.
Flags: needinfo?(bkerensa)
Unable to reproduce this issue on the build the user provided with either V122 or v123 bases for flame. Was always able to adjust the volume higher on the DuT during a call. Adjusted all volumes in settings to both extremes with no problems seen. In comment 11 branch checks were done without success and I was just trying to get the bug on an original build with various base firmwares.

Environmental Variables: Nightly build
Device: Flame Master
BuildID: 20140805040204
Gaia: 19bf9795263e2ccc15d824a52ebf23c2670fa9b9
Gecko: 7f81be7db528
Version: 34.0a1 (Master) 
Firmware Version: v122
-----------------------------------------------
Environmental Variables: Nightly build
Device: Flame Master
BuildID: 20140805040204
Gaia: 19bf9795263e2ccc15d824a52ebf23c2670fa9b9
Gecko: 7f81be7db528
Version: 34.0a1 (Master) 
Firmware Version: v123
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
I'm using the OTAs on Nightly channel. Maybe you have better hearing than I do. I went to a lot of super loud shows when I was young.
Cody can you try flashing to yesterdays 2.1 and do an OTA and then attempt to reproduce, perhaps that's the difference we need?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga) → needinfo?(croesch)
Sorry.........no luck there either.

Flashing Nightly 2.1 to 8/14 build then OTAing to today's 8/15 build does not cause an issue with calls being too quiet and not being able to adjust volume.

Environmental Variables: Nightly Build
Device: Flame Master
Build ID: 20140815040204
Gaia: 9979fccc6321be72cd17370f3a20c65bc376af33
Gecko: c9f8cc9ce89c
Version: 34.0a1 (Master)
Firmware Version: v123
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(croesch) → needinfo?(pbylenga)
(Reporter)

Comment 17

3 years ago
Is there anything else myself or Dietrich can offer to help isolate this?
Maybe the firmware used will reveal something? Run the following command
adb shell getprop t2m.sw.version

First 3 of the last 4 digits is the Firmware, mine ends in '1230' and is v123.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(bkerensa)
(Reporter)

Comment 19

3 years ago
Created attachment 8474702 [details]
Results

That command generates no return for me but other adb commands work fine.
Flags: needinfo?(bkerensa)
(Reporter)

Comment 20

3 years ago
Dietrich, can you run Th above since mine is not outputting anything useful?
Flags: needinfo?(dietrich)
Three people on our test team have taken a shot at this bug to reproduce, but we've had no success at reproducing this. As a result, I'm going to have to remove QA keywords for now, since there's it doesn't look like we're going to be able to help here unless we get better clarification on STR.
Keywords: qawanted, regressionwindow-wanted

Updated

3 years ago
Keywords: dogfood
(Reporter)

Comment 22

3 years ago
(In reply to Jason Smith [:jsmith] from comment #21)
> Three people on our test team have taken a shot at this bug to reproduce,
> but we've had no success at reproducing this. As a result, I'm going to have
> to remove QA keywords for now, since there's it doesn't look like we're
> going to be able to help here unless we get better clarification on STR.

STR are:
1. Make a call with volume set to lowest setting 
2. Listen to call volume
3. Increase call volume to max and notice no distinguishable change
4. Decrease volume back to low while still on call notice no change
QA-Wanted to attempt Repro with the updated STR (comment 22). If we get a Repro, please do a branch check.
Keywords: qawanted

Updated

3 years ago
QA Whiteboard: [QAnalyst-Triage+]
(In reply to Benjamin Kerensa [:bkerensa] from comment #19)
> Created attachment 8474702 [details]
> Results
> 
> That command generates no return for me but other adb commands work fine.

Ditto. This command executes successfully, and returns nothing.
Flags: needinfo?(dietrich)
(Reporter)

Comment 25

3 years ago
Any reason why this command would not be working? Were hoping to provide info so this can be isolated.
Flags: needinfo?(pbylenga)
The command is working. You just don't have a t2m.sw.version property set in your build. Which build is that exactly?
(Reporter)

Comment 27

3 years ago
(In reply to Fabrice Desré [:fabrice] from comment #26)
> The command is working. You just don't have a t2m.sw.version property set in
> your build. Which build is that exactly?

The nightly build and now OTA's Mozilla is providing for the flames?
What did you use as the base for the phone?  Or more specifically, have you ever flashed an OEM base image to your device?
Flags: needinfo?(pbylenga)
Flags: needinfo?(dietrich)
Flags: needinfo?(bkerensa)
PVT build of master + m-c via the scripts at https://github.com/Mozilla-TWQA/B2G-flash-tool. Switched to channel "nightly", also via the scripts there.
Flags: needinfo?(dietrich)
(Reporter)

Comment 30

3 years ago
(In reply to Peter Bylenga [:PBylenga] from comment #28)
> What did you use as the base for the phone?  Or more specifically, have you
> ever flashed an OEM base image to your device?

As far as it was explained to me the Flame's came pre-flashed with the 123 base image and that once we then flashed the nightly https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame using shallow flash we were good to go?
Flags: needinfo?(bkerensa)
Oops, I missed that part of the question.

My device's current state is

* flashed base image
* flashed latest build via the QA scripts
* OTAs via nightly channel
Thanks for the information Dietrich and Benjamin!  I think the full flash may be the culprit as it changes more than just a gecko/gaia flash.

Okay, adding qawanted to try the following:

* flash base v123
* full flash with B2G-flash-Tool to yesterday's build
* OTA to today's nightly

attempt STRs provided in Comment 22.
Duplicate of this bug: 1055832
(Reporter)

Comment 34

3 years ago
Just to confirm I flashed v123 today then used shallow to upgrade to nightly then checked for OTA and am on today's nightly OTA and still same volume issues.
Using the steps from comment 32 and comment 22 I was unable to reproduce this issue.  The volume difference between maximum and minimum volume is not very large, but it is noticeable and I was always able to understand the other caller even at minimum volume.

Environmental Variables: (after updating)
Device: Flame Master
BuildID: 20140828040204
Gaia: 3a838afca295c9db32e1a3ec76d49fb7fe7fd2d2
Gecko: 3be45b58fc47
Version: 34.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
(Reporter)

Comment 36

3 years ago
(In reply to Jayme Mercado [:JMercado] from comment #35)
> Using the steps from comment 32 and comment 22 I was unable to reproduce
> this issue.  The volume difference between maximum and minimum volume is not
> very large, but it is noticeable and I was always able to understand the
> other caller even at minimum volume.
> 
> Environmental Variables: (after updating)
> Device: Flame Master
> BuildID: 20140828040204
> Gaia: 3a838afca295c9db32e1a3ec76d49fb7fe7fd2d2
> Gecko: 3be45b58fc47
> Version: 34.0a1 (Master) 
> Firmware Version: v123
> User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

So you agree its not very large but would you be able to take a call on a city street at max volume? I know I cannot and others have experienced same. If indeed there is an increase in volume I would highly suggest we increase the max volume and create a larger gap. With this current volume situation I cannot dogfood.

Comment 37

3 years ago
I'm gonna assume we all make calls in different settings and we all have differently shaped faces and ears and different hearing abilities so there are many ways this could fail for people. 

I agree that the range between low and high volume is not enough.  The full loud setting should make me want to pull the phone away from my ear and it does not.  I've compared with a couple of other devices and we are quieter at the high end for sure. 

Let's increase the range.  Where does this code live? Can we tune in Gecko/Gaia or do we need more from the manufacturer?

Comment 38

3 years ago
Alex, have you seen this? I'm wondering if we're hitting a difference between the vendor's audio policy and ours, or some other difference in binary blobs..
Flags: needinfo?(mwu) → needinfo?(lissyx+mozillians)
(Assignee)

Comment 39

3 years ago
(In reply to Michael Wu [:mwu] from comment #38)
> Alex, have you seen this? I'm wondering if we're hitting a difference
> between the vendor's audio policy and ours, or some other difference in
> binary blobs..

I remember seeing commits related to this, but I can't remember in which repo.
Flags: needinfo?(lissyx+mozillians)
(Assignee)

Comment 40

3 years ago
> adb shell dumpsys media.audio_policy

I don't see any change at all in volume on my Kitkat build :(
Flags: needinfo?(bkerensa)
(Assignee)

Comment 41

3 years ago
I just checked on a JB build on Etienne's phone. 

Running:
> adb shell dumpsys media.audio_policy

Shows that we are changing stream 0 volume properly, but I don't hear any change :(
(Assignee)

Comment 42

3 years ago
I do reproduce this on my own Flame JB full flash.
(Assignee)

Comment 43

3 years ago
We will need help from T2M to know where and when they fixed this.
Flags: needinfo?(bkerensa) → needinfo?(vchen)
(Assignee)

Comment 44

3 years ago
Okay, even pushing /system/lib/ from v123 base image has no impact :(
See Also: → bug 1062554

Updated

3 years ago
Duplicate of this bug: 1063785
Duplicate of this bug: 1065099
(In reply to Benjamin Kerensa [:bkerensa] from comment #0)
> When making calls the volume level at max is very low and it is much harder
> to hear calls then on other platforms. Tested with nightly on a Flame
> handset.

Hi Benjamin,

could you describe what output did you use? speaker or receiver?

Updated

3 years ago
Flags: needinfo?(bkerensa)
(Reporter)

Comment 48

3 years ago
(In reply to Wayne Chen [:xwaynec] from comment #47)
> (In reply to Benjamin Kerensa [:bkerensa] from comment #0)
> > When making calls the volume level at max is very low and it is much harder
> > to hear calls then on other platforms. Tested with nightly on a Flame
> > handset.
> 
> Hi Benjamin,
> 
> could you describe what output did you use? speaker or receiver?

I tried both Speaker and Receiver while Speaker was slightly louder the difference was not much (not compared to other mobile platforms or even my expectations as a user)

Receiver was the worst definitely
Flags: needinfo?(bkerensa)

Updated

3 years ago
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(pbylenga)
Keywords: smoketest
For clarification, we are not seeing this issue to the same extent with the shallow flash as we are with the full flash. When using the full flash method we cannot hear either phone's audio and changes to the devices volume levels are not being reflected.
Not a smoketest blocker. This issue has been present for multiple months, which does not make this a blocker.
Keywords: smoketest
status-b2g-v2.1: --- → affected
Flags: needinfo?(ktucker)
Whiteboard: [2.1-flame-test-run-2]

Updated

3 years ago
Whiteboard: [2.1-flame-test-run-2] → [2.1-flame-test-run-2][fullflash-smoketest]
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(pbylenga)
Flags: needinfo?(ktucker)
In case dupe bug 1055832 has been missed, I have the same issue (using a v2.0 build). While the volume is loud enough in a quiet room, it's not as soon as the environment is noisy (in a street, when there is some wind or passing cars).

I didn't have this issue with other FxOS phones I used in the past.
Reviewed in triage - regression, and maybe uncovering issues with full vs shallow flash, so blocking+.
blocking-b2g: 2.1? → 2.1+
(Assignee)

Comment 53

3 years ago
(In reply to Dietrich Ayala (:dietrich) from comment #52)
> Reviewed in triage - regression, and maybe uncovering issues with full vs
> shallow flash, so blocking+.

Dietrich, while I agree with you, I could not find from where this discrepency comes from. My latest tries in comment 43 suggests it is not related to the /system/lib/ we are building.
(Assignee)

Updated

3 years ago
Depends on: 1068587
(Assignee)

Updated

3 years ago
Assignee: nobody → lissyx+mozillians
(Assignee)

Comment 54

3 years ago
Maybe related to bug 1068587.
(Assignee)

Comment 55

3 years ago
Current status when volume buttons looks to be ineffective:
 - dialpad tones
 - in call without speaker mode
 - in call with speaker mode
(Assignee)

Comment 56

3 years ago
(In reply to Alexandre LISSY :gerard-majax from comment #55)
> Current status when volume buttons looks to be ineffective:
>  - dialpad tones
>  - in call without speaker mode
>  - in call with speaker mode

Pushing those files:
> adb push backup-flame/system/etc/Bluetooth_cal.acdb /system/etc/Bluetooth_cal.acdb
> adb push backup-flame/system/etc/General_cal.acdb /system/etc/General_cal.acdb
> adb push backup-flame/system/etc/Global_cal.acdb /system/etc/Global_cal.acdb
> adb push backup-flame/system/etc/Handset_cal.acdb /system/etc/Handset_cal.acdb
> adb push backup-flame/system/etc/Hdmi_cal.acdb /system/etc/Hdmi_cal.acdb
> adb push backup-flame/system/etc/Headset_cal.acdb /system/etc/Headset_cal.acdb
> adb push backup-flame/system/etc/Speaker_cal.acdb /system/etc/Speaker_cal.acdb

does not improve the situation
(Assignee)

Comment 57

3 years ago
(In reply to Alexandre LISSY :gerard-majax from comment #55)
> Current status when volume buttons looks to be ineffective:
>  - dialpad tones
>  - in call without speaker mode
>  - in call with speaker mode

Puhsing:

> adb push backup-flame/system/etc/snd_soc_msm/ /system/etc/snd_soc_msm/

does not improve the situation
(Assignee)

Comment 58

3 years ago
(In reply to Alexandre LISSY :gerard-majax from comment #55)
> Current status when volume buttons looks to be ineffective:
>  - dialpad tones
>  - in call without speaker mode
>  - in call with speaker mode

Pushing both:
> adb push backup-flame/system/etc/snd_soc_msm/ /system/etc/snd_soc_msm/
+
> adb push backup-flame/system/etc/Bluetooth_cal.acdb /system/etc/Bluetooth_cal.acdb
> adb push backup-flame/system/etc/General_cal.acdb /system/etc/General_cal.acdb
> adb push backup-flame/system/etc/Global_cal.acdb /system/etc/Global_cal.acdb
> adb push backup-flame/system/etc/Handset_cal.acdb /system/etc/Handset_cal.acdb
> adb push backup-flame/system/etc/Hdmi_cal.acdb /system/etc/Hdmi_cal.acdb
> adb push backup-flame/system/etc/Headset_cal.acdb /system/etc/Headset_cal.acdb
> adb push backup-flame/system/etc/Speaker_cal.acdb /system/etc/Speaker_cal.acdb

I get this situation:
 - volume change can be heard in call, with and without speaker mode.
(Assignee)

Comment 59

3 years ago
Created attachment 8490756 [details] [review]
JB Device PR

Michael, please find attached a PR that fixes the issue for JB images.
Attachment #8490756 - Flags: review?(mwu)
Note - we're going to need a patch here for KK too, as our one-off fullflash smoketest of Flame KK showed that this is happening on Flame KK 2.1 as well.
(Assignee)

Comment 61

3 years ago
(In reply to Jason Smith [:jsmith] from comment #60)
> Note - we're going to need a patch here for KK too, as our one-off fullflash
> smoketest of Flame KK showed that this is happening on Flame KK 2.1 as well.

Thanks for bringing this: I could not find any trace of those files on my KK backup-flame (made out of v166 base image), so I assumed this one was not faulty. I'll check the status on Kitkat then.
I can confirm that the files from comment 58 fixed the issue for me (jb build).
(Assignee)

Comment 63

3 years ago
On kitkat, having pulled files from v166 base image I see that they are now within /system/etc/acdbdata/
(Assignee)

Comment 64

3 years ago
Created attachment 8491515 [details] [review]
KK Device PR

Path have changed a bit, and it seems we do not have any snd_soc_msm on KK. As far as I could test, it fixes the issue on KK as well this way.
Attachment #8491515 - Flags: review?(mwu)

Updated

3 years ago
Attachment #8491515 - Flags: review?(mwu) → review+

Comment 65

3 years ago
Comment on attachment 8490756 [details] [review]
JB Device PR

Review comment on PR.
Attachment #8490756 - Flags: review?(mwu)
(Assignee)

Comment 66

3 years ago
(In reply to Michael Wu [:mwu] from comment #65)
> Comment on attachment 8490756 [details] [review]
> JB Device PR
> 
> Review comment on PR.

Thanks, I just replied :)
Flags: needinfo?(mwu)

Comment 67

3 years ago
Do these files live in our code or do we need new base images from partner to fix this for our contributors who don't compile themselves?
The base images are fine. The issue is that we don't properly reuse the files from the backup-flame directory (pulled from a device flashed with a base image) when we generate our own images.
(Assignee)

Comment 69

3 years ago
Merged for kitkat: https://github.com/mozilla-b2g/device-flame/commit/960533f716ce31dfad357e87fa2f1d9ee5e94674
(Assignee)

Comment 70

3 years ago
Comment on attachment 8490756 [details] [review]
JB Device PR

Updated PR: after discussing with mwu, let's use from repo.
Attachment #8490756 - Flags: review?(mwu)

Updated

3 years ago
Attachment #8490756 - Flags: review?(mwu) → review+
Flags: needinfo?(mwu)
(Assignee)

Updated

3 years ago
Flags: needinfo?(vchen)
(Assignee)

Comment 71

3 years ago
https://github.com/mozilla-b2g/device-flame/commit/b04c1a7d96f01a743f23a544870cd5be2c8d172e
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Does this need approval requests for branches still?
status-b2g-v2.2: --- → fixed
Flags: needinfo?(lissyx+mozillians)
Target Milestone: --- → 2.1 S5 (26sep)
(Assignee)

Comment 73

3 years ago
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #72)
> Does this need approval requests for branches still?

I'm not sure, it's already on the proper branches.
Flags: needinfo?(lissyx+mozillians)
please full flash a KK tinderbox 2.1 build and verify its fixed on 2.1 branch.  thanks.
Keywords: verifyme
I tested this on Flame 2.1 and Flame 2.2 Full Flash with the KK Base.
On both branches, the volume seemed to work properly across the following areas of the device:

-Ringtone volume when receiving a call could be set appropriately loud and quiet.

-In-Call volume could be set appropriately loud and quiet.

-Dialer Touch Tone Keypad tones could be set appropriately loud and quiet (note, this required the user to change the Media volume, which must be done outside the Dialer app).

-Radio media volume could be set appropriately loud and quiet.

-YouTube media volume could be set appropriately loud and quiet (the volume range seemed a bit small when listening with headphones, but was still good when using the system speaker).

-Alarm volume could be set appropriately loud and quiet.


Environmental Variables:
Device: Flame 2.1
BuildID: 20140923003005
Gaia: 3a2947df41a480de1457a6dcdbf46ad0af70d8e0
Gecko: df42b05782aa
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Flame 2.2 (Master)
BuildID: 20140922193018
Gaia: fe92ddd450e03b38edb2d465de7897971d68ac68
Gecko: 790f41c631cc
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(pbylenga)
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
status-b2g-v2.1: affected → verified
status-b2g-v2.2: fixed → verified
Flags: needinfo?(pbylenga)
Keywords: verifyme

Updated

3 years ago
Blocks: 1062554

Updated

3 years ago
See Also: bug 1062554
You need to log in before you can comment on or make changes to this bug.