v 3.0.4 countdown skips the first second

[craigreilly]

When starting a countdown, it seems to skip the first second, ie 10:00 to 9:58.

[lukestein]

Replication:

Screen.Recording.2024-05-31.at.12.21.44.PM.mov

[cpvalente]

Thank you @lukestein and @craigreilly

I believe this was introduced in our recent attempts to make the timer more accurate. I am not immune to the irony here...

I will take a look at improving this, meanwhile:
Ontime updates at a minimum rate of 32ms (when nothing is happening), then we go through a bunch of filter to decide when to notify the views. We dont want to do this too much so try and minimise it to once a second.

What is likely happening is that we got some overzealous filter for the first update, should be a simple fix.
However, I believe this does not have any implications to the usage of the app, just looks strange..

[cpvalente]

Hi @craigreilly , the new release v3.1.0 includes changes to address this issue.
Do you mind having a look so we can close the ticket?

[craigreilly]

It does fix the previous error, though introduces a smaller concern.
If I am in an "event" and it is running and I click "Next", it almost skips the first second of the next timer.
ie: 10:00 and a 20:00 event.
Start running the 10.
Click "Next"
Display shows 20:00 for a millisecond before showing 19:59.

I am not sure this is really a problem. More cosmetic perhaps. I do not think anyone will notice except maybe the Op sitting in front of the laptop.

[cpvalente]

Hi @craigreilly , we actually had a long-ish chat about the subject

when you start a timer of 20 minutes 20:00 something like the following will happen

• Immediate trigger update - current clock 00:20:00.000 - we show 20:00
• First update (roughly 32ms later) - current clock 00:19:59.968 - we show: 19:59
• Nth update (every 32ms later) - current clock 00:19:x - we do not update the UI
• Nth update - current clock 00:19:58:968 - we show: 19:58
• Nth update - current clock 00:00:00:968 - we show: 00:00
• Nth update - current clock -00:00:00:032 - we show: -00:01

The gist of it is that what you see in the UI is a truncated, low resolution version of the time 00:19:59.968 -> 19:59.
Keep in mind that this is only pertaining to the UI updates and all integrations are as accurate as possible.

I honestly cant recall why we chose to do it this way, it was one of the first decisions in Ontime when we started 4 years ago.
What I am trying to explain is that this is the expected behaviour with the way we have chosen our app to work.
From our last conversation, we still believe this to be the correct behaviour.

However, I fear that this is not particularly explicit to users and may break the users confidence in the app. I see a few ways forward

For editor / director / show runner
In some views, like the editor, we could increase the timer resolution to show the milliseconds.
On seeing 00:20:00.000 and 00:19:59.900 I believe users would understand the way that we are counting.
However this comes with the side effect that Ontime pushes more data. This is undesirable for people in devices with slow or metered networks, as well as integrations (such as companion) that subscribe to the updates in Ontime

For time consumers, ie: presenter / speaker / talent
When presenting times in presenter view we could round up, so that in our example:

• Immediate trigger update - current clock 00:20:00.000 - we show 20:00
• First update (roughly 32ms later) - current clock 00:19:59.968 - we show: 20:00
• Nth update - current clock 00:19:58:968 - we show: 19:59
  ...
• Nth update - current clock 00:00:00:968 - we show: 00:01
• Nth update - current clock -00:00:00:032 - we show: -00:00
• Nth update - current clock -00:00:01:032 - we show: -00:01

In my opinion, the choice made in Ontime is solid, and not particularly better or worse than the opposite. From a quick look online, it seems that we can find both scenarios. However I am 100% on board that users should not be surprised by the timer output in a time application

Look forwards to hearing your thoughts.
@lukestein , would you mind sharing some thoughts too?

[craigreilly]

This is a solid write up.I was ok with the fix today... but thought I should bring up the behavior just in case.

[lukestein]

I think underlying design choice sounds solid and would not show subsecond frequencies anywhere.

Even if it's what's used internally, I think we don't want to give users the impression that they should be able to expect high-frequency accuracy (or even enter partial-second timers). And I wouldn't suggest increasing network traffic for this, either.

[cpvalente]

Thank you both @craigreilly and @lukestein for your help and for your comments.

@craigreilly , could we close this ticket?

[craigreilly]

Please do…

…

On Thu, Jun 6, 2024 at 1:01 PM Carlos Valente ***@***.***> wrote: Thank you both @craigreilly <https://github.com/craigreilly> and @lukestein <https://github.com/lukestein> for your help and for your comments. @craigreilly <https://github.com/craigreilly> , could we close this ticket? — Reply to this email directly, view it on GitHub <#1025 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7B7P255KI4GNCWEU7NDTLZGC5YNAVCNFSM6AAAAABITC6SIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJTGMYTAOJSGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>