1. Title : Device is becoming very slow if the Usage app is in background and use the Youtube app for 2 to 3 hours 2. Precondition : Usage->Configure the Usage FTE->Leave it in background 3. Tester's Action : Youtube app->Play the Youtube videos for 2 to 3 hours continuously. 4. Detailed Symptom (ENG.) :Device is becoming very slow after using the Youtube app more than 2 to 3hours continously and opening any app is taking long time. 6.Reproducibility: Y 1)Frequency Rate : 100%\ 7.Gaia Master/v1-train : Reproduced 8.Gaia Revision: 0d5a9a7577f16b6a72a982148c6f509ee1714ea2(Gecko-499c1f8ea7ad0cdaa7086214278e2944b8a2ea33) 9.Personal email id: firstname.lastname@example.org
Hi Salva, Please find the below analysis for this issue. ->After browsing YouTube app 2 to 3 hours(Once the device becomes slow) the CPU utilization of "b2g" is going above 80%,but the Usage app is always shows below 10 to 15%.Please ref the attached screenshot. -->Then i removed the application.zip from the costcontrol.gaiamobile.org and used the YouTube app for 2 to 3 hours and the device is not becoming slow and its working fine.(May be i am not sure about this step,removing only application.zip from costcontrol) -->This issue can be reproduced easily with mobile data network.(Wi-Fi also it reproduces)
Created attachment 785005 [details] Crash_CC.txt After browing with Youtube app about 4 to 5 hours with costcontrol app in background,crash was observed and attached the crash report.
Are you configuring an usage alarm in costcontrol app? Where is the youtube app? Do you mean the link in everything.me? Opening the video in the browser?
Yes by default it will be configured for 1GB.I kept as it is. Youtube is the separate app which will launch video.
Probably, this is related with how we "count" data in order to trigger the alarm once data limit is reached. As v1.1 has not support for BE usage watching the widget is listening each data transmitted event but I don't imagine why this slows the whole system. Here is the part: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/cost_control.js#L64
Assignee: nobody → acperez
I tried to reproduce it in unagi device. After 30/60 minutes Usage app in background is killed, maybe because device ran out of memory. What device are you using?
Hi Albert, I am using Leo device and recently Costcontrol Widget Memory Shrink patch was added. Please check this https://bugzilla.mozilla.org/show_bug.cgi?id=896755. In Leo device this patch is present.
Tried to reproduce applying patch of bug 896755, but costcontrol killed and can't reproduce. QA team is trying to reproduce.
I put in my LG device these commits and I can not activate data network to test the bug. Any solution?
What version of LG build are you using?
Build Identifier: 20130803175729
Hi Albert, This bug might be related to Bug https://bugzilla.mozilla.org/show_bug.cgi?id=901416
The above comment 12 is wrong. Please find the below one: Build Identifier: 20130802112417
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 901416
While analyzing this issue the gone through below scenarios. 1.After applying the Bug-901416 patch,The Usage Widget data updation rate is nearly 1.3min delay observed.Means The data is updated after every 1.3mins(without mozvisibilitychange event).This is due to below code in system app ACTIVITY_THRESHOLD = 250? Here is the part: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/cost_control.js#L63 2.The Usage widget will show only Mobile data,but even though if the user is browsing with the Wi-Fi we are updating Usage widget.Here we can avoid the usage widget updation?(Stop calling UpdateUI())
I'm not familiar with costcontrol gaia's code, I worked in NetworkStats API at gecko level. If it is not critical we can wait to Salva, he comes back from vacations next Monday. Is it ok?
Its ok Albert.Thank You so much..Once Salva is back i will ping him about this.
Maybe we can low the threshold. Some in field tests could determine what is the best threshold. I ignore if these events are dispatched at some specific rate. I think no or at least, this information is not part of the event so the threshold value can not be adjusted in a very accurate way.
You need to log in before you can comment on or make changes to this bug.