Display auto-off (sometimes) not working as expected

[Florian79]

I am the developer of Score Track Pro and since I got some feedback concerning a bug in my app that I am not able to reproduce, I kindly ask for any help with regard to the following:

• As using setTimeout(callback, 1000) is no reliable way to simulate a stopwatch or timer I use the clock API with the granularity of a second. This works quite well as long as the screen is on. As soon as it turns off the ontick callback is not invoked anymore. This works as intended by the API, thus I disable the autoOff feature using the display API as soon as the timer starts and enable autoOff again when the timer has been stopped or paused.
• Some users report that though they use the very same firmware and app version, the display went off automatically and shortly after startíng the timer. Several other users haven't seen this behaviour and I am not able to reproduce it either.
• What I can reproduce is turning of the screen by covering the display as described in the manual. Though this results in the same bug, it is not what is described by the users having the problem.

With respect to the last point, I am going to add time handling when the display changes from/to on/off. But this is going to add some inaccuracy since the calculations of seconds between turning off and on again may include some rounding, resulting in a fraction of second that adds or is missing from the total time. Not a big deal either but by no means perfect. Maybe I am going to truncate the milliseconds.

Thus I would like to ask

• Has anyone seen a similar behaviour concerning the autoOff feature, though it has been disabled?
• Is there a way to disable the display off feature by covering the display?
• Is there any setting on the device that may interfer or disable setting the autoOff programmatically?

Any help is appreciated. Thanks a lot.

[Gondwana]

Yes!!! Thank you so much for posting!

I have an utterly trivial clockface in the app store, which has the purported ability to stay on as its only claim to fame. However, I've found that autoOff is not completely reliable.

I've spent many hours trying to diagnose this. It's hard/impossible/time-consuming to reproduce reliably, even with trivial code. Worse, when I put diagnostic code in (eg, to log display.on and autoOff at critical events) it seems to be completely reliable, as though the diagnostic code is changing the errant behaviour — Heisenberg's Uncertainty Principle at work 😉

The only glimmer of hope I ever had with debugging was from this:

display.autoOff = state.autoOff;
console.log("display.autoOff="+display.autoOff + "   state.autoOff="+state.autoOff);

...which printed false and true. That's pretty hard to explain.

Since I'm not the only one to have observed this, I'll change my diagnosis from personal insanity to a bug in an OS code path somewhere. I'm wondering whether it's a race condition of sorts, since it seems so infrequent and random.

[gyurma]

Hi Florian,

I'm a football ref (soccer) and started to use your app, I'd have some feedback, but don't know where to send it.

cheers,

Gyuri