The sum of all phase percentages is greater than 100%

Bug reports
1

Detailed description of the problem:

I would assume that the sum of all phases of a sleep record (awake, REM, light sleep and deep sleep) would be exactly 100%. However, there are some sleep records in which this value is significantly bigger than 100%. Here I’m showing two specific examples of this incorrect behaviour.

Note: I have not submitted this bug through the app because it is a bit difficult to explain, more so without images. I hope I can get feedback here and then attach this forum post to the in-app bug report.

Example 1: Sleep record corresponding to 2025-03-06

29% awake
30% deep sleep
19% REM
35 % light sleep
Total = 113%

Screenshot_20250317-171143_Sleep
Screenshot_20250317-171143_Sleep1080×2340 212 KB

Screenshot_20250317-171153_Sleep
Screenshot_20250317-171153_Sleep1080×2340 218 KB

Example 2: Sleep record corresponding to 2025-03-16

20% awake
41% deep sleep
14% REM
36 % light sleep
Total = 111%

Screenshot_20250317-171037_Sleep
Screenshot_20250317-171037_Sleep1080×2340 182 KB

Screenshot_20250317-171104_Sleep
Screenshot_20250317-171104_Sleep1080×2340 184 KB

Important remaks:

  • The records shown above DO NOT have periods of missing data (due to low battery or something). This can be confirmed in the detailed record screen of each example
  • A discrepancy of more than 10% between percentages and total percentage cannot reasonably be attributed to rounding errors.
  • In most other sleep records all percentages do sum up roughly to 100% (sometimes 101 or 102).

Steps to reproduce:

I am not sure how to reproduce this error. I only suspect the error may appear when there is a significant amount of time classified as AWAKE.

Version of Sleep as Android:

Version 20250220 (230654) Premium

2

Hi, this looks like the graph might have some broken values. Do you have this on all your graphs? If only on some, is there any pattern?

3

Hello Lenka: To answer your questions:

  • In most sleep records I have all percentages do sum up roughly to 100% (sometimes 101 or 102). This is expected because of rounding errors.
  • The only pattern I found is that the error may appear when there is a significant amount of time classified as AWAKE. However I have not tested this hypothesis properly yet. I would need to find more examples that confirm or refute this hypothesis.

Important caveat:

  • The records shown above DO NOT have periods of missing data (that might occur due to low battery or something else). This can be confirmed in the detailed record screen of each example
4

Hi, broken values and missing data are slightly different.
Both graphs have paused tracking (apart from other types of awakes) - is this also common for the graphs with incorrect sum?

5

Hello @davidpaez … I did prepare a fix for the issue. This issue only occurs in case there are some missing data in the graph… now this situation should be handled properly in latest BETA version 20250319 which you can find here:
https://sleep.urbandroid.org/wp-content/uploads/release/sleep-20250319-beta-release.apk

Can you please test the BETA and let me know if the issue is fixed for you?

6

Hello @petr-urbandroid and @lenka-urbandroid

Let me see if I understood correctly: did this error occured (at least in the two examples I showed) because of the missing data in the sleep record caused by the paused tracking?

Thank you for fixing it so quickly. I would like to test the BETA version, but I have two issues:

  • If I install the APK, does it create a conflict with the version of the app that is currently installed via Google Play?
  • I wonder if it is safe to install it in my main device. Is there a risk that my sleep history be deleted or corrupted? Would you recommend trying with a different device?

Thank you for your help!

7

Hi, the versions from our website are safe, they are the very same versions we upload on the Play Store. It is just a faster way to get the fix, because the Google verification process may take several days.
The apk installed from our web will not break the auto-update cycle on the Play Store. But it might take a week or so before the Play Store updates will catch up your version.

The gaps during the pauses are not considered as missing or broken, because the app was in direct control of pausing the tracking. The missing data usually indicate some hiccup on the sensorm sensor data reading. It is fine, if there are only a few missing values. If you would feel it is getting more common, check the system optimizations, they are typically behind this misbehaving (https://dontkillmyapp.com/).

8

Thank you @lenka-urbandroid and @petr-urbandroid

I have installed the beta version. I will test it to see if the issue is fixed and post my results here