UPDATE and UPDATEDIVIDER behaviour needs improvement. Can't run first time and then delay?

[NeilFawcett]

With the following:-
UPDATE=1000
UPDATEDIVIDER=30

The meter or measure will run once every 30 seconds, BUT the problem is it will not be initially displayed for 30 seconds which nine times out of ten is probably undesired behaviour!

I would expect the UPDATEDIVIDER to work after the first initial display so the meter/measure is run the first time through and then only every X times.

Can we have a setting to force a meter/measure to run the first time throught and then abide by the UPDATEDIVIDER either by a new setting? eg: UPDATEDIVIDERINITIAL=1?

ie: So:-
UPDATE=1000
UPDATEDIVIDER=30
UPDATEDIVIDER=1

...so this will result in the meter/measure running first time through, and then every X times.

OR, EVER BETTER, a negative value less than -1:-
UPDATE=1000
UPDATEDIVIDER=-30

So that would run the meter/measure the first time thought, and then again every 30 times (ie: every 30s).

WORSE CASE
A new setting to simply force all meters and measure to display first time through irrespective of their UPDATEDIVIDER settings.

NOTE
With some of my scripts reducing the frequency they are process can significantly reduce the processing usage of Rainmeter, so being able to delay some meters/measures to run say once every 60 times, would have a noticable performace improvement. But I wouldn't want to wait for example 60 seconds for them to initially display.

[Jeff]

OnRefreshAction=[!Update]

[balala]

The meter or measure will run once every 30 seconds, BUT the problem is it will not be initially displayed for 30 seconds which nine times out of ten is probably undesired behaviour!

I would expect the UPDATEDIVIDER to work after the first initial display so the meter/measure is run the first time through and then only every X times.

This is exactly what is going on, no need to complicate things. When you refresh / activate a skin, its meters are immediately displayed (unless they are hidden through a Hidden=1 option or any other way), no matter of their UpdateDivider. After this, the meters are updated accordingly to the set UpdateDivider, but at the very first moment they are updated once and displayed.
Could you please post the code you have problems with, please?

[NeilFawcett]

I've tried this on two different scripts, and if I set UPDATE=10000, then the first display of the meter readings/values is not done for 10 seconds.

I've also tried UPDATE=1000 with UPDATEDIVIDER=10, and the same happens.


eg.. This doesn't display the values until 10s. They should ideally display immediately and then every 10s:-

Code: Select all

; Lines starting ; (semicolons) are commented out.
; That is, they do not affect the code and are here for demonstration purposes only.
; ----------------------------------

[Rainmeter]
; This section contains general settings that can be used to change how Rainmeter behaves.
Update=10000
Background=#@#Background.png
; #@# is equal to Rainmeter\Skins\illustro\@Resources
BackgroundMode=3
BackgroundMargins=0,34,0,14

[Metadata]
; Contains basic information of the skin.
Name=Network
Author=poiru
Information=Shows your IP address and network activity.
License=Creative Commons BY-NC-SA 3.0
Version=1.0.0

[Variables]
fontName=Trebuchet MS
textSize=8
colorText=255,255,255,205
; Set maxDownload and maxUpload to your maximum download and upload speed in bits.
; To convert kilobits, megabits, kilobytes, and megabytes into bits, go to www.google.com
; and search for something like "10 megabytes in bits".
spacing=12r

; ----------------------------------
; MEASURES return some kind of value
; ----------------------------------

[MeasureHighestUsedRAM1]
Measure=Plugin
Plugin=UsageMonitor
Alias=RAM
Index=1

[MeasureRAMforScaling1]
Measure=Calc
Formula=MeasureHighestUsedRAM1

[MeasureHighestUsedRAM2]
Measure=Plugin
Plugin=UsageMonitor
Alias=RAM
Index=2

[MeasureRAMforScaling2]
Measure=Calc
Formula=MeasureHighestUsedRAM2

[MeasureHighestUsedRAM3]
Measure=Plugin
Plugin=UsageMonitor
Alias=RAM
Index=3

[MeasureRAMforScaling3]
Measure=Calc
Formula=MeasureHighestUsedRAM3

[MeasureHighestUsedRAM3]
Measure=Plugin
Plugin=UsageMonitor
Alias=RAM
Index=3

[MeasureRAMforScaling3]
Measure=Calc
Formula=MeasureHighestUsedRAM3

[MeasureHighestUsedRAM4]
Measure=Plugin
Plugin=UsageMonitor
Alias=RAM
Index=4

[MeasureRAMforScaling4]
Measure=Calc
Formula=MeasureHighestUsedRAM4

[MeasureHighestUsedCPU1]
Measure=Plugin
Plugin=UsageMonitor
Alias=CPU
Index=1

[MeasureCPUforScaling1]
Measure=Calc
Formula=MeasureHighestUsedCPU1

[MeasureHighestUsedCPU2]
Measure=Plugin
Plugin=UsageMonitor
Alias=CPU
Index=2

[MeasureCPUforScaling2]
Measure=Calc
Formula=MeasureHighestUsedCPU2

[MeasureHighestUsedCPU3]
Measure=Plugin
Plugin=UsageMonitor
Alias=CPU
Index=3

[MeasureCPUforScaling3]
Measure=Calc
Formula=MeasureHighestUsedCPU3

[MeasureHighestUsedCPU4]
Measure=Plugin
Plugin=UsageMonitor
Alias=CPU
Index=4

[MeasureCPUforScaling4]
Measure=Calc
Formula=MeasureHighestUsedCPU4

; ----------------------------------
; STYLES are used to "centralize" options
; ----------------------------------

[styleTitle]
StringAlign=Center
StringStyle=Bold
;StringEffect=Shadow
;FontEffectColor=0,0,0,200	; 0,0,0,50
FontColor=#colorText#
FontFace=#fontName#
FontSize=10
AntiAlias=1
ClipString=1

[styleLeftText]
StringAlign=Left
; Meters using styleLeftText will be left-aligned.
StringCase=None
;StringStyle=Bold
StringEffect=Shadow
FontEffectColor=0,0,0,200	; 0,0,0,20
FontColor=#colorText#
FontFace=#fontName#
FontSize=#textSize#
AntiAlias=1
ClipString=1

[styleRightText]
StringAlign=Right
StringCase=None
;StringStyle=Bold
StringEffect=Shadow
FontEffectColor=0,0,0,200	; 0,0,0,20
FontColor=#colorText#
FontFace=#fontName#
FontSize=#textSize#
AntiAlias=1
ClipString=1

[styleSeperator]
SolidColor=255,255,255,15

; ----------------------------------
; METERS display images, text, bars, etc.
; ----------------------------------

[meterTitle]
Meter=String
MeterStyle=styleTitle
; Using MeterStyle=styleTitle will basically "copy" the
; contents of the [styleTitle] section here during runtime.
X=100
Y=12
W=190
H=18
Text=PROCESSES

[MeterHighestUsedRAM1L]
Meter=String
MeterStyle=styleLeftText
X=10
Y=40
W=140
H=12
AntiAlias=1
ClipString=1
MeasureName=MeasureHighestUsedRAM1

[MeterHighestUsedRAM1R]
Meter=String
MeterStyle=styleRightText
X=200
Y=0r
; r stands for relative. In this case, the Y postition of meterValueCPU is 0 pixels
; below the Y value of the previous meter (i.e it's the same as in meterLabelCPU).
H=12
AntiAlias=1
MeasureName=MeasureRAMforScaling1
AutoScale=1
NumOfDecimals=1
DynamicVariables=1
Text=%1B

[MeterHighestUsedRAM2L]
Meter=String
MeterStyle=styleLeftText
X=10
Y=#spacing#
W=140
H=12
AntiAlias=1
ClipString=1
MeasureName=MeasureHighestUsedRAM2

[MeterHighestUsedRAM2R]
Meter=String
MeterStyle=styleRightText
X=200
Y=0r
W=190
H=12
AntiAlias=1
MeasureName=MeasureRAMforScaling2
AutoScale=1
NumOfDecimals=1
DynamicVariables=1
Text=%1B

[MeterHighestUsedRAM3L]
Meter=String
MeterStyle=styleLeftText
X=10
Y=#spacing#
W=140
H=12
AntiAlias=1
ClipString=1
MeasureName=MeasureHighestUsedRAM3

[MeterHighestUsedRAM3R]
Meter=String
MeterStyle=styleRightText
X=200
Y=0r
W=190
H=12
AntiAlias=1

MeasureName=MeasureRAMforScaling3
AutoScale=1
NumOfDecimals=1
DynamicVariables=1
Text=%1B

[MeterHighestUsedRAM4L]
Meter=String
MeterStyle=styleLeftText
X=10
Y=#spacing#
W=140
H=12
AntiAlias=1
ClipString=1
MeasureName=MeasureHighestUsedRAM4

[MeterHighestUsedRAM4R]
Meter=String
MeterStyle=styleRightText
X=200
Y=0r
W=190
H=12
AntiAlias=1
MeasureName=MeasureRAMforScaling4
AutoScale=1
NumOfDecimals=1
DynamicVariables=1
Text=%1B

[MeterHighestUsedCPU1L]
Meter=String
MeterStyle=styleLeftText
X=10
Y=19r
W=140
H=12
AntiAlias=1
ClipString=1
MeasureName=MeasureHighestUsedCPU1

[MeterHighestUsedCPU1R]
Meter=String
MeterStyle=styleRightText
X=200
Y=0r
W=190
H=12
AntiAlias=1
MeasureName=MeasureCPUforScaling1
AutoScale=1
NumOfDecimals=1
DynamicVariables=1
Text=%1%

[MeterHighestUsedCPU2L]
Meter=String
MeterStyle=styleLeftText
X=10
Y=#spacing#
W=140
H=12
AntiAlias=1
ClipString=1
MeasureName=MeasureHighestUsedCPU2

[MeterHighestUsedCPU2R]
Meter=String
MeterStyle=styleRightText
X=200
Y=0r
W=190
H=12
AntiAlias=1
MeasureName=MeasureCPUforScaling2
AutoScale=1
NumOfDecimals=1
DynamicVariables=1
Text=%1%

[MeterHighestUsedCPU3L]
Meter=String
MeterStyle=styleLeftText
X=10
Y=#spacing#
W=140
H=12
AntiAlias=1
ClipString=1
MeasureName=MeasureHighestUsedCPU3

[MeterHighestUsedCPU3R]
Meter=String
MeterStyle=styleRightText
X=200
Y=0r
W=190
H=12
AntiAlias=1
MeasureName=MeasureCPUforScaling3
AutoScale=1
NumOfDecimals=1
DynamicVariables=1
Text=%1%

[MeterHighestUsedCPU4L]
Meter=String
MeterStyle=styleLeftText
X=10
Y=#spacing#
W=140
H=12
AntiAlias=1
ClipString=1
MeasureName=MeasureHighestUsedCPU4

[MeterHighestUsedCPU4R]
Meter=String
MeterStyle=styleRightText
X=200
Y=0r
W=190
H=12
AntiAlias=1
MeasureName=MeasureCPUforScaling4
AutoScale=1
NumOfDecimals=1
DynamicVariables=1
Text=%1%

[NeilFawcett]

OnRefreshAction=[!Update]

What is that suppose to do? It doesn't seem to solve my problem?

[Jeff]

What is that suppose to do? It doesn't seem to solve my problem?

I posted it assuming it was a case of measures that reference the next measure in the file and to fix them from showing 0 you would just do a sneaky !Update only once when the skin it's loaded that

That's not the problem though, it's just performance regarding UsageMonitor, for me, all UsageMonitor skins exhibit the problem described, photo for reference with the example skin provided on the page, which takes a few seconds to load (since it's probably creating the individual processes for each Counter, it's really independent on when those processes end being created)

[NeilFawcett]

I posted it assuming it was a case of measures that reference the next measure in the file and to fix them from showing 0 you would just do a sneaky !Update only once when the skin it's loaded that

That's not the problem though, it's just performance regarding UsageMonitor, for me, all UsageMonitor skins exhibit the problem described, photo for reference with the example skin provided on the page, which takes a few seconds to load (since it's probably creating the individual processes for each Counter, it's really independent on when those processes end being created)

For me on the intial load up and a REFRESH of that skin and many others do not display any values/meters until the update time. In the case of the example given, it takes 10 seconds before any (proper) values are shown in the list. And this is true of many skins I try. eg: If I set my copy of "Weather Station HD" to DISPLAY=10000, then on initial load up or a REFRESH, it will be 10 seconds before any weather information is display.

I can see no way to perform in the logical fashion of running (all) meters/values immediately on the inital run/loadup or a REFRESH, and then delay as specified by UPDATE or UPDATEDIVIDER.





EDIT:

Changing this simple one from UPDATE=1000 to UPDATE=10000, and it DOES display its values immediate, unlike other examples I have... WHY?

Code: Select all

; Lines starting ; (semicolons) are commented out.
; That is, they do not affect the code and are here for demonstration purposes only.
; ----------------------------------

[Rainmeter]
; This section contains general settings that can be used to change how Rainmeter behaves.
Update=10000
Background=#@#Background.png
; #@# is equal to Rainmeter\Skins\illustro\@Resources
BackgroundMode=3
BackgroundMargins=0,34,0,14

[Metadata]
; Contains basic information of the skin.
Name=Clock
Author=poiru
Information=Displays the current date and time.
License=Creative Commons BY-NC-SA 3.0
Version=1.0.0

[Variables]
; Variables declared here can be used later on between two # characters (e.g. #MyVariable#).
fontName=Trebuchet MS
textSize=8
colorText=255,255,255,235
spacing=17r

; ----------------------------------
; MEASURES return some kind of value
; ----------------------------------

[measureTime]
; This measure returns the time in a 24-hour format (i.e. HH:MM).
Measure=Time
Format=%H:%M:%S
; For a 12-hour clock, change the Format option above to: %I:%M %p
; Refer to the Rainmeter manual for other format codes.

[measureDate]
; Returns the date as DD.MM.YYYY
Measure=Time
Format=%d/%m/%Y

[measureDay]
; Returns the current day
Measure=Time
Format=%A

; ----------------------------------
; STYLES are used to "centralize" options
; ----------------------------------

[styleTitle]
StringAlign=Center
StringStyle=Bold
;StringEffect=Shadow
;FontEffectColor=0,0,0,200	; 0,0,0,50
FontColor=#colorText#
FontFace=#fontName#
FontSize=10
AntiAlias=1
ClipString=1

[styleLeftText]
StringAlign=Left
; Meters using styleLeftText will be left-aligned.
StringCase=None
;StringStyle=Bold
StringEffect=Shadow
FontEffectColor=0,0,0,200	; 0,0,0,20
FontColor=#colorText#
FontFace=#fontName#
FontSize=#textSize#
AntiAlias=1

[styleRightText]
StringAlign=Right
StringCase=None
;StringStyle=Bold
StringEffect=Shadow
FontEffectColor=0,0,0,200	; 0,0,0,20
FontColor=#colorText#
FontFace=#fontName#
FontSize=#textSize#
AntiAlias=1

[styleSeperator]
SolidColor=255,255,255,15

; ----------------------------------
; METERS display images, text, bars, etc.
; ----------------------------------

[meterTitle]
Meter=String
MeterStyle=styleTitle
; Using MeterStyle=styleTitle will basically "copy" the
; contents of the [styleTitle] section here during runtime.
MeasureName=measureTime
X=100
Y=12
;W=190
H=18
Text=TIME %1

[meterDateTitle]
Meter=String
MeterStyle=styleLeftText
X=10
Y=40
;W=190
H=14
Text=Date

[meterDate]
Meter=String
MeterStyle=styleRightText
MeasureName=measureDay
MeasureName2=measureDate
X=200
Y=0r
;W=190
H=14
Text=%1 %2
UpdateDivider=60

[MeasureUptime]
Measure=Uptime
Substitute=":":"h "

[UptimeTitle]
Meter=String
MeterStyle=styleLeftText
X=10
Y=#spacing#
;W=190
H=14
Text=Uptime

[Uptime]
Meter=String
MeterStyle=styleRightText
X=200
Y=0r
W=190
H=14
MeasureName=MeasureUptime
Text=%1m
UpdateDivider=60[/quote]

[balala]

I've tried this on two different scripts, and if I set UPDATE=10000, then the first display of the meter readings/values is not done for 10 seconds.

I've also tried UPDATE=1000 with UPDATEDIVIDER=10, and the same happens.

The UsageMonitor plugin measures seem to be a little bit different then other types of measures. Probably these measures need a little while it takes the appropriate values from the Windows Performance Monitor. If the skin has the Update set to Update=10000 or if it's set to the default Update=1000 along with UpdateDivider=10 on all measures and meters, when the skin is refreshed it can1t take the values yet, but the next time when it can show the values, is after 10 seconds.
The solution is the one presented by Jeff above, but with a small modification. Instead of adding the OnRefreshAction option as suggested by him, you can add the following one: OnRefreshAction=[!Delay "1000"][!UpdateMeasure *][!UpdateMeter *][!Redraw]. As you can see with this option, when the skin is refreshed an 1 second delay starts. After this amount of time all measures and meters are updated (by the [!UpdateMeasure *] and [!UpdateMeter *] bangs), then skin is redrawn (by the [!Redraw] bang), which leads to taking the result in the skin.
If it doesn't work or doesn't work properly, you can try increasing the delay in the fist bang of the option. But I think the 1 second delay (given by the [!Delay "1000"] option) should be enough.

Changing this simple one from UPDATE=1000 to UPDATE=10000, and it DOES display its values immediate, unlike other examples I have... WHY?

No, it doesn't, if you would use the same measures. But in this case you did use Time measures, which don't have the problems stated above. So the answer is in the differences of the two codes.

[NeilFawcett]

Yes, that's helped!

So in the case of the "WEATHER HD" skin, UPDATE=60000 means it does not display any weather info for 60 seconds.

However, introducing your:-
Update=60000
OnRefreshAction=[!Delay "1000"][!UpdateMeasure *][!UpdateMeter *][!Redraw]

Means it appears basically straight away, and then I assume then only updates every 60 seconds.


Most importantly, the CPU usage seems to reflect this. ie: If I run it with the default UPDATE=1000, I can see more CPU usage by rainmeter!



Are you able to explain what that command is specifying to do?
OnRefreshAction=[!Delay "1000"][!UpdateMeasure *][!UpdateMeter *][!Redraw]



QUESTION: Is the syntax for "UPDATEDIVIDER" case sensitive? Must it be "UpdateDivider"?

[balala]

Yes, that's helped!

So in the case of the "WEATHER HD" skin, UPDATE=60000 means it does not display any weather info for 60 seconds.

However, introducing your:-
Update=60000
OnRefreshAction=[!Delay "1000"][!UpdateMeasure *][!UpdateMeter *][!Redraw]

Means it appears basically straight away, and then I assume then only updates every 60 seconds.

Weather skins are using WebParser measures. For skins working with this type of measures it is almost basic that have to use the default Update=1000. Not that they couldn't work with other Update value, but it's most convenient. They can work even with no update (so with Update=-1, in which case the skin is never updated, excepting the very first moment, when it's activated or refreshed), but it's better to be use with Update=1000. For many of these skins it is extremely important to have a very well controlled amount of time when the parent WebParser measure is going out to the internet to parse the information. It is easiest to do this if the Update is set to the default value.
So not recommending to set the Update=60000. Not even on any kind of skins, and especially not on those using WebParser measures.
However it is not impossible either...

Most importantly, the CPU usage seems to reflect this. ie: If I run it with the default UPDATE=1000, I can see more CPU usage by rainmeter!

On quite modern and not too (extremely) old computers Rainmeter shouldn1t have too much impact on the performances.

Are you able to explain what that command is specifying to do?
OnRefreshAction=[!Delay "1000"][!UpdateMeasure *][!UpdateMeter *][!Redraw]

I think I did this in my previous reply:

you can add the following one: OnRefreshAction=[!Delay "1000"][!UpdateMeasure *][!UpdateMeter *][!Redraw]. As you can see with this option, when the skin is refreshed an 1 second delay starts. After this amount of time all measures and meters are updated (by the [!UpdateMeasure *] and [!UpdateMeter *] bangs), then skin is redrawn (by the [!Redraw] bang), which leads to taking the result in the skin.

QUESTION: Is the syntax for "UPDATEDIVIDER" case sensitive? Must it be "UpdateDivider"?

In Rainmeter nothing is not case sensitive. UPDATEDIVIDER work same way as does UpdateDivider, updatedivider, Updatedivider, updateDivider, or even uPdAtEdIvIdEr. Doesn't matter which one do you use.
Lua is case sensitive for instance, but Rainmeter isn't.