[BUG] Scroll count calculates wrong time, its a 0.5 more time

[chertvl]

Bug report

Describe the bug

Hi, Lubeda, firstly thank you for great project!

There is some strange bug ive notice:
Somewhy when I call any HA-service to display my long text on Ulanzi, the time of scrolling line calculates wrong.
Line is showing fully, then a little blank space at the end, and then showing one first word of my text again (i think its 24px, not a just first word).
It looks like:

"[Icon] Some text here, long text i think (blank space)"
"[Icon] Some tex"
*Returns to main screen (clock).

What I need to do to display my long-text notification 1 time only (not 1.5) ?

In my esphome config i have:
scroll_count: 1
With scroll cound 2 i have 2.5 times of running long text.

Additional information

• used Hardware:
  • Ulanzi TС001

To Reproduce

Steps to reproduce the behavior:
Just a call icon_text or alarm as me, for 1 scroll count, for 1 screen time.

Services calls

service: esphome.ulanzi_alert_screen
data:
  icon_name: spotify
  text: >-
    {{state_attr('media_player.zenbook','media_artist') + ' - ' +
    state_attr('media_player.zenbook','media_title') }}
  screen_time: 1
  default_font: true
  r: 255
  g: 255
  b: 255

There is a little video ive recorded for you.
https://drive.google.com/file/d/1VUK-n22frwMrHPKhwonuQXQiwJ0iN8Mt/view?usp=sharing

[lubeda]

i will investigate

[andrewjswan]

@lubeda , I was thinking, maybe we should add the ability to display it at once to all screens?
Those if specified a lifetime of 0, and specified a screen display time of 10 seconds, then the lifetime automatically takes the value of 10 seconds.

    screen->calc_scroll_time(text, screen_time);
    screen->endtime = this->clock->now().timestamp + (lifetime > 0 ? lifetime * 60 : screen->screen_time_ + 1);

[andrewjswan]

In calc_scroll_time - https://github.com/lubeda/EspHoMaTriXv2/blob/2023.9.1/components/ehmtxv2/EHMTX_queue.cpp#L703
i change:

max_steps = (EHMTXv2_SCROLL_COUNT + 1) * (width - startx) + EHMTXv2_SCROLL_COUNT * this->pixels_;

to

max_steps = EHMTXv2_SCROLL_COUNT * (width - startx) + EHMTXv2_SCROLL_COUNT * this->pixels_;

It has gotten better, but there is still a small tail.

[andrewjswan]

max_steps = EHMTXv2_SCROLL_COUNT * (width - startx) + EHMTXv2_SCROLL_COUNT * this->pixels_;

Gives these results:

Most likely the problem is rounding to the top, you should try it or normal math rounding.

[lubeda]

That's the fact, the "next_screen" ist evaluated with a resolution of one second. So the desired effect iss there, but only solvable with a more or less redesign.

[andrewjswan]

So the desired effect iss there, but only solvable with a more or less redesign.

We can try switching from timestamp to millis(). That should solve the problem, I think.

[lubeda]

thats a "dirty" solution mills() is relative to the time of boot now() is absolut and precise. A better solution would be the number of ticks eg. via counting down

[andrewjswan]

mills() is analogous to timestamp but in milliseconds, in terms of functionality nothing should change, but the transition accuracy will be higher ...

[andrewjswan]

Yes, millis() will not work for us, it is limited to about 50 days, then it will start from 0.
And recalculating all screens when resetting to zero is a bad idea in my opinion.

[andrewjswan]

We can use gettimeofday, get seconds and milliseconds, subtract the start time, and get the real operating time in milliseconds, but most likely they will have to be stored in double.

time_t start_time = now().timestamp();

and

struct timeval tv;
gettimeofday(&tv, NULL);
return (double) ((tv.tv_sec - start_time) * 1000 + tv.tv_usec / 1000);

[andrewjswan]

Max float value: 3.402823466 E + 38 if we imagine that these are milliseconds, then we will get in years, maximum:
3.402823466E+38/1000/60/60/24/365 = 1.0790282e+28 and this is approximately equivalent 7720 years, looks good.
uint64_t - 18446744073709551615/1000/60/60/24/365 = 584942417.355 years
float is cheaper...

[andrewjswan]

Strange error on ESP8266, no error on ESP32.

error: \'CLOCK_MONOTONIC\' was not declared in this scope; did you mean \'CLOCK_MONOTONIC_RAW\'?     clock_gettime(CLOCK_MONOTONIC, &spec);

But the same code is used in the ESPHome source code https://github.com/esphome/esphome/blob/dev/esphome/components/host/core.cpp#L17

[andrewjswan]

Looks like I did, not sure about working on the 8266 (I can't test) but on the Esp32 (Ulanzi TC001) it works. Not much time has passed, but I have tested almost all modes.

@chertvl Can you check? Has your problem been fixed?

[chertvl]

@chertvl Can you check? Has your problem been fixed?

It seems work flawlessly. Indeed what I expected!
Thank you for your work ;)

[chertvl]

@andrewjswan did it in #131
thanks!