You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 18, 2023. It is now read-only.
During analysis of the battery sensor data we have noticed that data in the battery_charges and battery_discharges tables isn't accurate in certain situations. We have identified some events that would cause the sensor to record an incorrect battery_end and double_end_timestamp and thus give an inaccurate entry in the respective tables:
The app crashes or is force closed by the user and the user restarts it some time later. The time before the app stopped should be considered the end of the last charging/discharging period and a new period should be started from the time that the app restarted. For example if the battery was in a discharging period before the app stopped working and the user charges the phone before restarting the app the battery_end could be higher than the battery_start and the double_end_timestamp could be hours or days after the starting timestamp. This would give an extremely inaccurate discharge rate.
The user or OS shuts down/restarts the phone. The next time the app starts should be the beginning of a new charge or discharge period and the most recent recording should be the end of the last period.
Basically we want to avoid an incorrect delta battery level or an incorrect delta time.
The same issue is present on the iOS client and has been reported to Yuuki.
The text was updated successfully, but these errors were encountered:
During analysis of the battery sensor data we have noticed that data in the battery_charges and battery_discharges tables isn't accurate in certain situations. We have identified some events that would cause the sensor to record an incorrect battery_end and double_end_timestamp and thus give an inaccurate entry in the respective tables:
The app crashes or is force closed by the user and the user restarts it some time later. The time before the app stopped should be considered the end of the last charging/discharging period and a new period should be started from the time that the app restarted. For example if the battery was in a discharging period before the app stopped working and the user charges the phone before restarting the app the battery_end could be higher than the battery_start and the double_end_timestamp could be hours or days after the starting timestamp. This would give an extremely inaccurate discharge rate.
The user or OS shuts down/restarts the phone. The next time the app starts should be the beginning of a new charge or discharge period and the most recent recording should be the end of the last period.
Basically we want to avoid an incorrect delta battery level or an incorrect delta time.
The same issue is present on the iOS client and has been reported to Yuuki.
The text was updated successfully, but these errors were encountered: