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

[BarsMonster]

but I decide to set it to zero to start again, without storing the correction

This is the core of the issue. Unfortunately, hardware subsecond counter is not accessible from the software at all.
When you finetune the clock by 50ms - it is achieved by stopping clock by ether 50ms or 950ms. There is no other way to adjust subsecond counter.

I.e. there is no good way to exit without saving subsecond counter. Subsecond counter is always adjusted and there is no going back.

The only choice you have is whether you are applying new clock frequency correction or not (first parameter - FC). If you did multiple adjustments or exited without saving - calculated clock adjustment will be incorrect this time. So your only option in this case is finetune clock to match time.is, DO NOT save correction value, wait few days and only then do finetune & save. It is most time efficient to perform finetune when you have 0.5-1 second of error. I.e. if you have initially 4 second of error per day - you can finetune already after 6 hours.