Message app stops the clock?

The clock on my Bangle2 regularly stops when it it connected via Gadgetbridge. The watch still responds, but the displayed time is not updated. When i disconnect the phone, all is good. Does anyone else have the same issue?

Which clock app do you have?

Gadgetbridge updates the time on Bangle.js when it connects - I guess it's possible that when the time is updated the clock you're using gets confused and stops updating itself?

ContourClock, I am the author of that clock.
Seems to be a problem with the app, I'll have a closer look tomorrow.

It could be the same issue as described in http://forum.espruino.com/conversations/­372748/newest/

I played around with the time on my phone, but it didn´t stop the clock.
BTW: Why do all clocks seem to use timeouts instead of intervals to update? I just changed

function queueDraw() {
  if (drawTimeout) clearTimeout(drawTimeout);
  drawTimeout = setTimeout(function() {
    drawTimeout = undefined;
    draw();
    queueDraw();
  }, 60000 - (Date.now() % 60000));
}

to

setInterval(draw,60000);

, which seems to do exactly the same.

which seems to do exactly the same.

no, this is not synced to real time so you may draw next minute too late

Sure but in practice does anyone care if the clock face updates 1s too late once per minute. Maybe the actual difference is 100ms sometimes? Or are there scenarios that could mean a noticeable difference?

Well, it can be also 59 seconds too late, so why not schedule timeout to the first second of the minute?

Even if you would run the first setInterval(draw,60000); at the right time - first second of the minute I am not sure how accurate interval is over time. With setTimeout you can compensate for that and also when time changes.

Clocks showing seconds can to the same and schedule to first milisecond in a second instead of e.g. running setInterval every 500 or 250ms.

I changed the code to this:

setTimeout(function() {
  setInterval(draw,60000);
}, 60000 - Date.now() % 60000);

I also put this line in draw() to measure the timing error:

g.setFontAlign(0,1).drawString(parseInt(­((Date.now()+30000)%60000)-30000)/1000,g­.getWidth()/2,24+18);

So far it has never shown more than 0.01s, which is good enough for a clock that updates every minute.

That's great - but I feel like there shouldn't really be any issues with the 'old' way of doing it - unless for some reason the clock face caused an exception when drawing so execution never completed and queueDraw never got called.