WebParser URL=file measure, how to reliably overwrite/update the local file in the background?

[emp00]

Dear Team, in this project I still have sometimes a small glitch - I was hoping that you "know the answer"? I know that there's a solution but after a few days of try+error I'm lost. It's not a show-stopper, but I know it's possible to fix this.

• I'm using a WebParser measure to regex out a few strings from a local file "PVMetrics-Webparser.txt", see code below
• Note hat the UpdateRate is 1 hour
• Every 15 minutes I run an AHK script triggered by a Plugin=RunCommand measure in the skin, which updates the "PVMetrics-Webparser.txt" file in the background
• In detail, as final step in the AHK script, I'm copying an updated temp.txt file over the existing "PVMetrics-Webparser.txt" via FileCopy("temp.txt", "PVMetrics-Webparser.txt", 1) - Note: "1" option means overwrite-mode Here's the docs for AHK's FileCopy in case I overlooked something...

Here's the problem: Not every time, but maybe 20% of the time the FileCopy fails with this AHK error:
Error: (32) The process cannot access the file because it is being used by another process.

Suspicion is, that it's the Rainmeter WebParser URL=file accessing the file every second (Update=1000) despite the 1 hour UpdateRate??! Is it true, that the WebParser measure is locking the file every time it's looking into it?

Now the million-dollar-question: How can I reliably overwrite the WebParser local file in the background with the running Rainmeter WebParser measure/skin? Honestly, I'm not 100% sure that Rainmeter is the problem, but as of now this is my best lead... Any ideas, hints, much appreciated.

Code: Select all

[PVParser1]
Measure=WebParser
; UdateRate=1 hour --> we will trigger WebParser execution always with above FinishAction=[!CommandMeasure PVParser1 "Update"] after the AHK script providing an updated file "Metrics-Webparser.txt" has finished execution!
UpdateRate=3600

URL=file://#CURRENTPATH#PVMetrics-Webparser.txt
CodePage=1200
RegExp=(?siU)LastRunTimeStamp=(.*)\RLastRunTimeStampUTC=(.*)\R.*ParseString_NOMATCH_Counter=(.*)\R.*LastUpdatedAgo_minutes=(.*)\RCurrentBatteryCharge=(.*)\REnergyIndependence=(.*)\R.*Imported_kWh=(.*)\RProduced_kWh=(.*)\RDischarged_kWh=(.*)\RConsumed_kWh=(.*)\RExported_kWh=(.*)\RNetExported_kWh=(.*)\RCharged_kWh=(.*)\RMetricTrend_ScaleMAXkW=(.*)\R

FinishAction=[!EnableMeasureGroup WaitForPVParser1][!ShowMeterGroup MeterWaitForPVParser1][!Log " OK, PV update cycle done."]
OnConnectErrorAction=[!Log "!WebParser PVParser1 update ERROR!"]

[balala]

Now the million-dollar-question: How can I reliably overwrite the WebParser local file in the background with the running Rainmeter WebParser measure/skin?

The linked project is extremely hard to follow, because lot of things have been altered. However to copy a file, I probably would try to use a RunCommand plugin measure, which has to be run at the proper moments. I think to something like this:

Code: Select all

[MeasureRun]
Measure=Plugin
Plugin=RunCommand
Parameter=copy "temp.txt", "PVMetrics-Webparser.txt" /y
State=Hide

Hope the following things are obvious:

• In the Parameter option I posted only the names of the source and destination files (temp.txt and PVMetrics-Webparser.txt). Most probably you have to use the full path, but you probably know better this detail.
• Note the /y parameter of the same Parameter option: it is used to overwrite the file with no question. Most probably this is your intention, but make sure this is right.
• This measure has to be run in order to get it executed. Add the [!CommandMeasure "MeasureRun" "Run"] bang to the option you want to use to copy the file. I'm not sure where this should be added, because I can't really follow your code, but hope you'll know where to add it. If you don't know, please see below.

If you can't apply what has been described above, please pack the config you have in its current form and upload the package here.

[emp00]

If you can't apply what has been described above, please pack the config you have in its current form and upload the package here.

Thank you balala, I 100% understand your approach: It's "pulling" the file within Rainmeter rather than "pushing" it from my AHK script. In case the file is then not locked (any more) it will most probably work!

Can you still try to explain the problem behind, a little bit? I would like to understand if it's really Rainmeter locking the Webparser local file every second as decribed above? Is this the reason why I sometimes cannot overwrite my Webparser file while the skin is running?

[balala]

Thank you balala, I 100% understand your approach: It's "pulling" the file within Rainmeter rather than "pushing" it from my AHK script. In case the file is then not locked (any more) it will most probably work!

You have to try this.

Can you still try to explain the problem behind, a little bit?

Sorry, but no, unfortunately I can't.

I would like to understand if it's really Rainmeter locking the Webparser local file every second as decribed above? Is this the reason why I sometimes cannot overwrite my Webparser file while the skin is running?

I doubt it is, but you have to try this out. If you don't really know how to do this (what I also doubt, to be honest, but who knows), please let me know, for further help.

[Yincognito]

Can you still try to explain the problem behind, a little bit? I would like to understand if it's really Rainmeter locking the Webparser local file every second as decribed above? Is this the reason why I sometimes cannot overwrite my Webparser file while the skin is running?

I somehow doubt that WebParser is the cause for that, partly because of your UpdateRate and partly since it should normally access the file in "read mode", which, unlike some "write modes", is typically not locking the file for anything, it just loads the file contents in some "memory buffer" for reading it afterwards.

Not sure how AHK's FileCopy works internally (a quick look at its source code should reveal that), but as potential causes:
- some bug in AHK, though less likely
- a process other than AHK or Rainmeter interfering (AV, Windows Search Indexer, etc.)
- the file(s) being copied from / to not being closed properly
- access to the file is not done in "share read" / "share write" modes, if that's even needed or possible
- full path to files is not specified (just a guess here)
- potential AHK variables representing the files or the copy process / result still in use at the time of the attempt (seems not to be the case here though, as per your description)
- others I didn't think of

As for how to reliable doing it, normally it should work without any "special measures". If you really think it's WebParser, you could:
- use an UpdateRate of -1 and trigger its access update from the OnUpdateAction of another 15 minute updated measure via [!CommandMeasure PVParser1 "Update"]
- disable the WebParser when / if needed
- use a force reload flag in WebParser to prevent caching
- try to use a [!CommandMeasure PVParser1 "Reset"] before the access update

That being said, for the one time when the AHK and WebParser could "coincide", i.e. once every hour, there might be some possible timing issue when AHK is trying to write to the destination file at roughly the same time when WebParser is attempting to read the file, and that approximates the 20% you mentioned (possibly being 25% of the cases), so a small "delay" between writing to the file and reading it with WebParser might help...

P.S. All that Update=1000 should do to WebParser is to update the value of its options (and unrelated, redraw the skin), plus playing a part in the Update × UpdateDivider × UpdateRate retrieval frequency from the "URL" resource. The measure won't read or access the file every second, given that the said product is way larger than 1000 as per your code.

[emp00]

- use an UpdateRate of -1 and trigger its access update from the OnUpdateAction of another 15 minute updated measure via [!CommandMeasure PVParser1 "Update"]

Many thanks for the explanations and tons of suggestions (also thanks to balala) - I will test them step-by-step, starting with the easiest one (see above). The CommandMeasure "Update" I'm anyway already using to trigger the WebParser after the AHK-script has run ("FinishAction"). I have added a log function to my AHK script to detect failed FileCopy commands and together with your tipps I should be able to find the root cause (over time).

Muchas gracias, merci beaucoup & double thumbs up!

[Yincognito]

Many thanks for the explanations and tons of suggestions (also thanks to balala) - I will test them step-by-step, starting with the easiest one (see above). The CommandMeasure "Update" I'm anyway already using to trigger the WebParser after the AHK-script has run ("FinishAction"). I have added a log function to my AHK script to detect failed FileCopy commands and together with your tipps I should be able to find the root cause (over time).

Muchas gracias, merci beaucoup & double thumbs up!

[emp00]

Guess what ... UpdateRate=-1 seems to have done the trick?! No more errors the whole day, today. First time!
Too good to be true? Well, I won't complain if it's indeed true Fingers crossed to the bone.

[Yincognito]

Guess what ... UpdateRate=-1 seems to have done the trick?! No more errors the whole day, today. First time!
Too good to be true? Well, I won't complain if it's indeed true Fingers crossed to the bone.

Well, let's hope that does the trick.

[balala]

Guess what ... UpdateRate=-1 seems to have done the trick?! No more errors the whole day, today. First time!
Too good to be true? Well, I won't complain if it's indeed true Fingers crossed to the bone.

When parsing a local file, normally this is a good approach (normally means the file is not extremely large - this is true in most cases). Just make sure not to apply it for online resources. But for local files, it's perfectly alright, as you figured it out.