Finetune face seems to have a mismatch between shown correction and stored correction

[Akrai]

So the two or three times I've been trying to do the finetune time correction, waiting several days to accumulate time differences to do good corrections, I've been running into a weird issue. It goes something like this: when I have enough delta of time, I go to set a correction, I hold alarm or light button to get a 250ms adjustment, and keep pressing buttons until I get the proper correction, but I decide to set it to zero to start again, without storing the correction, but when going back to zero, it seems to have an internal correction stored or something like that, like a mismatch between the correction on display and the actual running correction, as going back to displayed zero doesn't make the clock go back to the previous time shift it had before...

Hope it makes some sense. I've been reading the finetune_face.c code and there could be a weird logic between displayed variables and stored correction variables...

[neutralinsomniac]

Yeah I believe this is a known bug related to the clock briefly stopping whenever the correction value is incremented/decremented. I don't know if there's a way to fix it.

[Akrai]

I just reflashed installing less faces, less complications, as I was starting to have weird bugs in the watch (when using the timer face, after a timer has finished, it went to a random time and stopped there, instead of going back to the time it was initially set: if the timer was set for 2 minutes, after reaching 00:00 it went, for example, to 18:52, and stayed there waiting to be initialized again, and if I did so, timer started from 18:52... this number changed randomly even when not pressing any button, to other random numbers too), which I started to think it was related to some kind of variable overflow related to finetune...

So now, reflashed latest commit, with only

simple_clock_face,
timer_face,
stock_stopwatch_face,
alarm_face,
thermistor_readout_face,
finetune_face,
nanosec_face,
set_time_face,
preferences_face

all merged commits And finetune keeps doing that weird bug... I went to set the seconds offset to zero against time.is, first went to positive delta values but i realized I needed negative ones, and when went to zero I realized the initial seconds offset was no longer the same, now its 2 seconds instead of 1 second offset, even when finetune's delta is showing to be zero.... Has nothing to do with nanotune as nanotune's setting page has all values set to default ones for P3

[814d3]

I can confirm the above. But when I don't "scroll" from positive to negative values (or the other way around or from a value to zero again) and set it to the correct value on the right scale (positive or negative) it works pretty good.

[Akrai]

Since I avoid scrolling more than once per second (this is, I do not push alarm or light more than once per second, so I would go up or down in the adjustment step by step per second) I've had no issues so far, so seems it is related to the refresh rate or something

The first time what I did was press up or down several times per second to go faster to the adjustment point I desired