Description: Usage Reset doesn't seem to work properly. It requires to tap Reset button a few times to clear off data usage. After tapping Reset button for the first time the usage number actually increases, tapping it again will eventually set usage to 0.00. Repro Steps: 1) Updated Buri to BuildID: 20131127040203 2) Set up the Usage app to track data 3) Browse YouTube or any website and then close browser app 4) Open Usage app and note the usage number (5.28MB) 5) Open Usage settings and tap Reset button Actual: Usage number jumps up (36.34MB), the user has to tap Reset button a few times to set data usage to 0.00 Expected: Usage number drops off to 0.00 (or at least gets down in case if there is still some browser activity in the background) Environmental Variables: Device: Buri v1.3 M-C Mozilla RIL BuildID: 20131127040203 Gaia: d4b9a3d271f0451b4d903a03c2b931b8cc092041 Gecko: 6ecf0c4dfcbe Version: 28.0a1 Firmware Version: v1.2_20131115 Repro frequency: 80%, 3/3 devices See attached logcat
looks like we're getting intermittenant working and not working: bug 938946 Looks like a real API was needed : bug 937247 at the same time bug 937240 landed 11/22. Should be in the 11/23 build. Please check the 11/23 build and the 11/22 build to see this might be the regression range.
.:First Broken Build:. Environmental Variables: Device: Buri 1.3 mozRIL BuildID: 20131121040202 Gaia: 71063dd91bc8cbb15ba335236ed67a1c5058bd58 Gecko: cf378dddfac8 Version: 28.0a1 Firmware Version: 20131115 .:Last Working Build:. Environmental Variables: Device: Buri 1.3 mozRIL BuildID: 20131120040202 Gaia: c26480b22ce28c812c347290dd4bad090d83db6f Gecko: 4f993fa378eb Version: 28.0a1 Firmware Version: 20131115 I also checked 11/23 and 11/22, both builds repro this issue. Super close guess Naoki.
Probably related to the same problems talked about in https://bugzilla.mozilla.org/show_bug.cgi?id=942060#c10.
Let me check if this is a back-end or front-end problem.
It seems to be a back-end bug. This is the first time we use the real `reset` of the API. The lack of multi-sim support in the former API prevent us to loose the historical data so, instead, we were only saving fixing values. I'm removing the regression keyword because it is not a regression. Moving to new Network Statistics API involves to use the real reset functionality which was never used before. If this is not affordable, we have the know-how to provide a Gaia workaround but the solution will be suboptimal. The provided STR is enough. This is happening on master, latest Gecko.
triage: 1.3+ broken feature
blocking-b2g: 1.3? → 1.3+
(In reply to Salvador de la Puente González [:salva] from comment #6) > It seems to be a back-end bug. This is the first time we use the real > `reset` of the API. The lack of multi-sim support in the former API prevent > us to loose the historical data so, instead, we were only saving fixing > values. > > I'm removing the regression keyword because it is not a regression. Moving > to new Network Statistics API involves to use the real reset functionality > which was never used before. If this is not affordable, we have the know-how > to provide a Gaia workaround but the solution will be suboptimal. Switching to a new API backend in which old functionality no longer works still counts as a regression. It just means the new API backend isn't meeting quality requirements of the old API setup. There's a window to prove that. Re-adding keyword.
Ok. Understood. Sorry for the misinterpretation.
There is a problem after cleaning the database when setting the first value for a given interface in order to keep the track of the netd rx/tx values. Currently it is considered the last value before cleaning as the new reference value, but this is wrong because now we have perapp stats stored with the global ones and sometimes the value taken for reference is one with appId != 0 and it makes the wrong behavior. The patch checks the appId to ensure we are taking the correct reference value.
Attachment #8340240 - Flags: review?(gene.lian)
Comment on attachment 8340240 [details] [diff] [review] Patch Review of attachment 8340240 [details] [diff] [review]: ----------------------------------------------------------------- Nice! Thank you for catching this. Please go ahead to land. :) r=gene
Attachment #8340240 - Flags: review?(gene.lian) → review+
Hi John, please take a look at this bug and think about if we'd have any other side-effect like this after introducing the per-app metering.
Nice catch, Albert! It has no affect for per-app part and fixes the bug clearly :)
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.3 Sprint 6 - 12/6
You need to log in before you can comment on or make changes to this bug.