Clock Seconds Update

[critical58]

So there's this code from a youtube video I am following but the clock only updates every 3 seconds therefore making the clock half slow if you will! Do you think there is a way I could fix this?

Code: Select all

[Rainmeter]
Update=3000
AccurateText=1
DynamicWindowSize=1

[Variables]
Color=255,255,255
Scale=1


[MeasureTime]
Measure=Time
Format=%I:%M:%S %p

[MeasureDate]
Measure=Time
Format=%B %d, %Y
FormatLocale=Local

[MeasureWeekDay]
Measure=Time
Format=%A
FormatLocale=Local

[Time]
Meter=String
MeasureName=MeasureTime
FontColor=231, 189, 178
FontFace=Montserrat Light
FontSize=(23*#scale#)
StringCase=Upper
StringAlign=Center
AntiAlias=1
Y=(173*#scale#)
X=(495*#scale#)

[Date]
Meter=String
MeasureName=MeasureDate
FontColor=231, 189, 178
FontFace=Montserrat Regular
FontSize=(22*#scale#)
StringCase=Upper
StringAlign=Center
AntiAlias=1
Y=(9*#scale#)
X=(495*#scale#)

[WeekDay]
Meter=String
MeasureName=MeasureWeekDay
FontColor=#Color#
FontFace=Montserrat ExtraBold
FontSize=(100*#scale#)
StringCase=Upper
StringAlign=Center
InlineSetting=Shadow | (1*#Scale#) | (9*#Scale#) | (6*#Scale#)| 0, 0, 0, 150
AntiAlias=1
Y=(25*#scale#)
X=(500*#scale#)

[mak_kawa]

Hi critical58

Update=1000 in the [Rainmeter] section.

[critical58]

Oh wow! How embarrassing, thanks alot!

[balala]

How embarrassing,

No, it's not embarrassing at all. The Update option of the [Rainmeter] section controls how often things are updated into your skin. If you set this to Update=3000, means one update per three seconds (3000 milliseconds). So, the clock (all measures and meters) is updated only once per three seconds. With Update=1000, the updates are going on once per second (per 1000 milliseconds).
Not knowing how the skins are working, is not embarrassing, so don't worry. The essence of this forum is exactly to let you figure out these kind of details.

[Mor3bane]

I might sound like a 'rule breaker', but for clock skins, I have found Update=900 to be most effective in the clock keeping up with the windows clock.

There is some delay between rainmeter and windows, the Time function is based on windows time, so shortening the delay will have no effect other than reducing if not eliminating any delays.

Just my personal observations. I have not asked if this is wrong before so - I may be after all. But there you have it, my opinion.

[Yincognito]

I might sound like a 'rule breaker', but for clock skins, I have found Update=900 to be most effective in the clock keeping up with the windows clock.

There is some delay between rainmeter and windows, the Time function is based on windows time, so shortening the delay will have no effect other than reducing if not eliminating any delays.

Just my personal observations. I have not asked if this is wrong before so - I may be after all. But there you have it, my opinion.

Yeah, the thing is that no matter how one approaches this, there are going to be those "delays" that one cannot estimate precisely, and one just cannot do a perfectly accurate time skin in Rainmeter, simple because of how Rainmeter operates in the first place.

To illustrate what happens, let's suppose we set a 900 ms update in the skin to try to be precise and eliminate the delays. For computational sake, but also to show what happens if the delay is near 0 when the system is idle, let's also suppose that the delay of Rainmeter is constant and has a value of 0 ms (none of those assumptions are true in a dynamic computer environment, of course, but it just makes illustrating the outcome easier, without affecting the conclusion; you can have a different delay or a variable / dynamic delay as it actually happens, the only thing below that will be different will be the numbers, as the conclusion will remain the same, especially on significant delay variations). Let's also assume that at update 00 below (i.e. the skin update that happens on refreshing the skin), the computer time and the Rainmeter skin are "synchronized". The hour and minute are not relevant in this, so we'll only show the seconds.milliseconds part (as in 03.999) - Time means the real time, Skin means the time shown in the skin (actually, just the seconds, assuming a HH:MM:SS format) based on the update rate and delay:

- Update 00: Time = 00.000, Skin = 00.000 (synchronized)
- Update 01: Time = 00.900, Skin = 00.000 (synchronized, but duplicate of skin time above)
- Update 02: Time = 01.800, Skin = 01.000 (synchronized)
- Update 03: Time = 02.700, Skin = 02.000 (synchronized)
- Update 04: Time = 03.600, Skin = 03.000 (synchronized)
- Update 05: Time = 04.500, Skin = 04.000 (synchronized)
- Update 06: Time = 05.400, Skin = 05.000 (synchronized)
- Update 07: Time = 06.300, Skin = 06.000 (synchronized)
- Update 08: Time = 07.200, Skin = 07.000 (synchronized)
- Update 09: Time = 08.100, Skin = 08.000 (synchronized)
- Update 10: Time = 09.000, Skin = 09.000 (synchronized)
- Update 11: Time = 09.900, Skin = 09.000 (synchronized, but duplicate of skin time above)
- Update 12: Time = 10.800, Skin = 10.000 (synchronized)
- Update 13: Time = 11.700, Skin = 11.000 (synchronized)
- Update 14: Time = 12.600, Skin = 12.000 (synchronized)
- Update 15: Time = 13.500, Skin = 13.000 (synchronized)
- Update 16: Time = 14.400, Skin = 14.000 (synchronized)
- Update 17: Time = 15.300, Skin = 15.000 (synchronized)
- Update 18: Time = 16.200, Skin = 16.000 (synchronized)
- Update 19: Time = 17.100, Skin = 17.000 (synchronized)
- Update 20: Time = 18.000, Skin = 18.000 (synchronized)
- Update 21: Time = 18.900, Skin = 18.000 (synchronized, but duplicate of skin time above)
- Update 22: Time = 19.800, Skin = 19.000 (synchronized)
- ....................................................................

As you can see, we already have 3 instances when the time is shown the same in the skin compared to the previous skin update. This will happen irrespective of the update set in the Rainmeter skin, as can be seen below in my very light skin measuring time at 1000 ms update during a high CPU usage spike (time interval shown: 15:04:11 to 15:04:21; the lower CPU usage period, when everything is displayed properly, from 15:04:18 to 15:04:20):

ezgif.com-video-to-gif.gif

The underlying cause why these things happen is because it's not the time event that triggers Rainmeter into measuring it (i.e. on time change event), but Rainmeter which is measuring time irrespective of how much that time value is. In other words, there isn't an action option similar to the mouse actions (that react and are triggered immediately by mouse events) for the time measure, the process is actually the reverse, with Rainmeter triggering when the time is updated in the skin. Sure Rainmeter has its own internal counters, also based on time measurements, but those are subject to CPU usage variations, since it's not the (very slightly innacurate as well, as demonstrated when adjusting it from an atomic time server online) BIOS program we're talking about here. It's just how Rainmeter operates, like I said earlier.

[jsmorley]

It's like looking at any clock. The time on the clock is always accurate, but what time it shows depends on when you look at it. If you look at it twice in a second, it will have the same time twice. If you look away for 30 seconds, you won't see those 30 seconds in between.

How often you update a clock skin determines how often Rainmeter "looks at" the time.

If you are displaying a clock with the seconds, it's not a terrible idea to set Update to 900 or 800 or something, just to reduce (although you can't eliminate) some "same time twice" and / or "skipping a second" behavior.

Code: Select all

[Rainmeter]
Update=50
DynamicWindowSize=1
AccurateText=1
OnRefreshAction=[!SetVariable CurrentHours "[MeasureHours]"][!SetVariable CurrentMinutes "[MeasureMinutes]"][!SetVariable CurrentSeconds "[MeasureSeconds]"][!UpdateMeter *][!Redraw]

[Variables]
LinesColor=0,0,0,255
NumberColor=255,255,255,255
BackColor=19,43,77,255
CurrentHoursY=2
NewHoursY=-40
CurrentMinutesY=2
NewMinutesY=-40
CurrentSecondsY=2
NewSecondsY=-40
U=[!UpdateMeasureGroup Sliders][!UpdateMeterGroup Numbers][!Redraw]

; Measures

[MeasureHours]
Measure=Time
Format=%I
OnChangeAction=[!CommandMeasure HoursSlide "Execute 1"]

[MeasureMinutes]
Measure=Time
Format=%M
OnChangeAction=[!CommandMeasure MinutesSlide "Execute 1"]

[MeasureSeconds]
Measure=Time
Format=%S
OnChangeAction=[!CommandMeasure SecondsSlide "Execute 1"]

[HoursSlide]
Measure=Plugin
Plugin=ActionTimer
Group=Sliders
IgnoreWarnings=1
ActionList1=SetThem | Wait 1 | Repeat SlideThem, 20, 21 | Wait 1| SwapThem
SetThem=[!SetVariable CurrentHoursY "2"][!SetVariable NewHoursY "-40"]#U#
SlideThem=[!SetVariable CurrentHoursY "(Clamp(#CurrentHoursY#+2,2,45))"][!SetVariable NewHoursY "(Clamp(#NewHoursY#+2,-40,2))"]#U#
SwapThem=[!SetVariable CurrentHoursY "2"][!SetVariable NewHoursY "-40][!SetVariable CurrentHours "[MeasureHours]"]#U#
UpdateDivider=-1
DynamicVariables=1

[MinutesSlide]
Measure=Plugin
Plugin=ActionTimer
Group=Sliders
IgnoreWarnings=1
ActionList1=SetThem | Wait 1 | Repeat SlideThem, 20, 21 | Wait 1| SwapThem
SetThem=[!SetVariable CurrentMinutesY "2"][!SetVariable NewMinutesY "-40"]#U#
SlideThem=[!SetVariable CurrentMinutesY "(Clamp(#CurrentMinutesY#+2,2,45))"][!SetVariable NewMinutesY "(Clamp(#NewMinutesY#+2,-40,2))"]#U#
SwapThem=[!SetVariable CurrentMinutesY "2"][!SetVariable NewMinutesY "-40][!SetVariable CurrentMinutes "[MeasureMinutes]"]#U#
UpdateDivider=-1
DynamicVariables=1

[SecondsSlide]
Measure=Plugin
Plugin=ActionTimer
Group=Sliders
IgnoreWarnings=1
ActionList1=SetThem | Wait 1 | Repeat SlideThem, 20, 21 | Wait 1| SwapThem
SetThem=[!SetVariable CurrentSecondsY "2"][!SetVariable NewSecondsY "-40"]#U#
SlideThem=[!SetVariable CurrentSecondsY "(Clamp(#CurrentSecondsY#+2,2,45))"][!SetVariable NewSecondsY "(Clamp(#NewSecondsY#+2,-40,2))"]#U#
SwapThem=[!SetVariable CurrentSecondsY "2"][!SetVariable NewSecondsY "-40][!SetVariable CurrentSeconds "[MeasureSeconds]"]#U#
UpdateDivider=-1
DynamicVariables=1

; Meters

[MeterContainer]
Meter=Shape
Shape=Rectangle 1,1,126,43 | StrokeWidth 2
UpdateDivider=-1
LeftMouseUpAction=[!Toggle]

[MeterNewHours]
Meter=String
Group=Numbers
MeasureName=MeasureHours
W=30
H=32
X=22
Y=#NewHoursY#
StringAlign=Center
FontFace=Fira Sans
FontSize=20
FontColor=#NumberColor#
SolidColor=#BackColor#
Padding=5,5,5,5
AntiAlias=1
Container=MeterContainer
UpdateDivider=-1
DynamicVariables=1

[MeterCurrentHours]
Meter=String
Group=Numbers
W=30
H=32
X=22
Y=#CurrentHoursY#
StringAlign=Center
FontFace=Fira Sans
FontSize=20
FontColor=#NumberColor#
SolidColor=#BackColor#
Padding=5,5,5,5
AntiAlias=1
Text=#CurrentHours#
Container=MeterContainer
UpdateDivider=-1
DynamicVariables=1

[MeterNewMinutes]
Meter=String
Group=Numbers
MeasureName=MeasureMinutes
W=30
X=64
Y=#NewMinutesY#
H=32
StringAlign=Center
FontFace=Fira Sans
FontSize=20
FontColor=#NumberColor#
SolidColor=#BackColor#
Padding=5,5,5,5
AntiAlias=1
Container=MeterContainer
UpdateDivider=-1
DynamicVariables=1

[MeterCurrentMinutes]
Meter=String
Group=Numbers
MeasureName=MeasureMinutes
W=30
X=64
Y=#CurrentMinutesY#
H=32
StringAlign=Center
FontFace=Fira Sans
FontSize=20
FontColor=#NumberColor#
SolidColor=#BackColor#
Padding=5,5,5,5
AntiAlias=1
Text=#CurrentMinutes#
Container=MeterContainer
UpdateDivider=-1
DynamicVariables=1

[MeterNewSeconds]
Meter=String
Group=Numbers
MeasureName=MeasureSeconds
W=30
X=106
Y=#NewSecondsY#
H=32
StringAlign=Center
FontFace=Fira Sans
FontSize=20
FontColor=#NumberColor#
SolidColor=#BackColor#
Padding=5,5,5,5
AntiAlias=1
Container=MeterContainer
UpdateDivider=-1
DynamicVariables=1

[MeterCurrentSeconds]
Meter=String
Group=Numbers
W=30
X=106
Y=#CurrentSecondsY#
H=32
StringAlign=Center
FontFace=Fira Sans
FontSize=20
FontColor=#NumberColor#
SolidColor=#BackColor#
Padding=5,5,5,5
AntiAlias=1
Text=#CurrentSeconds#
Container=MeterContainer
UpdateDivider=-1
DynamicVariables=1

[MeterOutline]
Meter=Shape
Shape=Rectangle 1,1,126,43 | StrokeWidth 2 | Stroke Color #LinesColor# | Fill Color 0,0,0,0
Shape2=Line 43,2,43,43 | StrokeWidth 2 | Stroke Color #LinesColor#
Shape3=Line 85,2,85,43 | StrokeWidth 2 | Stroke Color #LinesColor#
UpdateDivider=-1

test1.gif

[Mor3bane]

...it's not a terrible idea to set Update to 900 or 800 or something, just to reduce (although you can't eliminate) some "same time twice" and / or "skipping a second" behavior.

That is all I was trying to illustrate - the visual skipping or repeating seconds - I AM a bit over analytical and hyper critical of certain things and seeing a clock skip seconds was just beyond annoying - the shorter update was my way around that visual paradigm.

[Yincognito]

If you are displaying a clock with the seconds, it's not a terrible idea to set Update to 900 or 800 or something, just to reduce (although you can't eliminate) some "same time twice" and / or "skipping a second" behavior.

So it's basically a matter of how much is the average CPU usage of the computer, isn't it? For example, set the update lower than 1000 ms if your CPU is mostly busy, set it to 1000 ms if your CPU is mostly idle.

Disregard, I'm just pointlessly stating the obvious here.

[balala]

I might sound like a 'rule breaker', but for clock skins, I have found Update=900 to be most effective in the clock keeping up with the windows clock.

Even if I'm a little bit late, I don't see the advantage of a such setting on a clock skin. Updating a clock once per second is perfectly right, since the shortest change of a clock is one second (supposing there are no animations or some kind of effect added). If the clock is updated at the beginning of a second or at the end of it (for instance at 1 millisecond or at 999), doesn't matter too much. But with Update=1000 between each to consecutive updates elapses 1 second, unless your computer is heavily loaded, in which case a shorter update might help.
My opinion...