I’m in the states so no recommendations but surprised there are not more specialists in the finance center of the world.
I found them years ago, the first year we had crypto regs and theyve been a pita ever since.
I’m sure it’s different today, but till they sort back issues I can’t move on.
Remove config yamyl then restart pc then add folders back in gui/config yamyl.
I think this may actually solve this issue. Last night I did this by accident and it’s been running for the last 14 hours problem free.
If this is the case then my hunch of a chia software issue is correct.
When I originally installed the external hard drives they were given a drive Letter and I also mounted them as a folder. When they were full of plots I would delete the drive Letter and point chia towards the folder I had mounted the drive in. Ensuring that the config yamyl is up to date and pointing to the correct location.
Recently I’ve given half of my drives letters so that I could convert them to NFT plots. So these letters will almost certainly be different from the original letter assigned to it the first time it was plugged in. Last night I deleted all of the drive letters and just left the folder address. Then re added the folder location back into the gui/config yamyl.
Either way deleting the config yamyl, and re adding the plot folder seems to have solved the issue.
I’m not saying 100% yet as it’s only been 14 hours, but that’s the longest it’s gone without issue for weeks and weeks.
1 Like
Still going strong! Can’t belive it could be something so simple!!
I also have trouble thinking it could be something so simple.
So I’ll wait and see how you go on.
I could go 18 hrs without issue before.
Hope you fixed it, but I have reservations.
If I look at my config.yaml it lists the drives exactly as I’ve added them in gui, with no other extra drives there.
Let me know how things continue.
So since I messed with mine, it’s been 16 hrs.
I had a batch of 3 lines that were @ just over 5 sec, then a batch of 9 just over 7 sec.
I doubt those would lose me a block, and nothing on the 49 sec range that I had previously hit.
I will do. Before i was getting errors within an hour. Now nothing since 18.00 yesterday.
All my drives are now just mounted as folders and that’s all chia and all of the forks i farm are looking at.
I think that if i change a drive to have a letter assigned to it as well the chia gui then shows it as the letter rather than the folder? I may be wrong. Which would indicate it is maybe looking in two places for a plot?
Anyway, I shall keep testing and let you know.
I haave changed cables, usb hubs even added an additional USB pcie card. And it could just be a software issue.
Good luck
Afaik assigning letter is done by the pc.
The gui / config.yaml only holds a list of places to look ( addresses).
So once you / the pc changes an address the old one is completely useless.
Even if chia tried to look there, it should just return a folder not found error / warning.
Sorry if this is not helping, but I have one more potential explanation.
There is a distinction between on-error and error-manifestation conditions. The first occurs when the actual error happens, the second when an operation related to such error fails. In this case, it looks like that 153 error is where OS is realizing that there is something wrong with one USB drive (yes, that entry in the Event Viewer is the first manifestation of that issue). And that message in the Chia log is when Chia hits such drive and OS is not cooperating (this is the second manifestation that is pertinent to Chia software, and therefore may be interpreted as Chia is causing that error).
Also, when you shared the info about how you connect your drives (mix of drive letters and mount points), I also realized that my errors with drives going offline happened when I was also mixing those (I killed those mount points, but didn’t connect that to potentially fixing the problem). I don’t think this is the error, but rather it may be a precondition to have the error happen. As OS is stating that there are two paths to those drives, maybe somehow OS gets confused, and sees such drives briefly through both mount points and drive letters (thus preventing access to them to mitigate file corruption)? I am not saying that you do have those drives attached through both, rather that somehow USB hub had a hiccup, and HD that is using a mount point briefly lost it and requested a letter for whatever reason.
I don’t think that it explains the error at all (first if that is the case, the second what triggered it), but maybe that mix of mount points and letters is really needed to have this problem being triggered?
We will see, I didn’t get to run my test long enough, as my last drive I was plotting filled, and adding that today, even though I’d removed the drive letter before even adding it to the system still crashed all the 5 bay docks on that hub.
Good explanation, it is definitely pointing towards this issue.
I am now well over 24 hours and no issues at all.
Glad to report I’ve also passed 24 hrs without issue.
While looking at devices and printers I’ve seen the clock appear on some of my docks, but they haven’t thrown a fit, before when that happened is when the exclamation mark used to pop up.
Well, that’s some BS, need to not use crystal disk, they don’t play nicely together.
Was having the periodic lookup fails as you guys. Tried the delete config.yaml and adding back drives. Still getting the issue. I had hope ):
Happens all at once for a very short time, less than a minute, on random drives (changes next time). All other times are generally between .5-.25 seconds. Then great for a couple hours. Then again. I don’t think it matters big picture, but still why?
2021-10-04T11:38:55.575 harvester chia.harvester.harvester: WARNING Looking up qualities on O:\plot-k32-2021-08-24-16-31-…plot took: 16.89141082763672. This should be below 5 seconds to minimize risk of losing rewards.
2021-10-04T11:38:55.584 harvester chia.harvester.harvester: WARNING Looking up qualities on F:\plot-k32-2021-06-13-07-19-…plot took: 5.628051042556763. This should be below 5 seconds to minimize risk of losing rewards.
2021-10-04T11:38:55.587 harvester chia.harvester.harvester: WARNING Looking up qualities on V:\plot-k32-2021-08-30-23-53-…plot took: 5.631054878234863. This should be below 5 seconds to minimize risk of losing rewards.
2021-10-04T11:38:55.597 harvester chia.harvester.harvester: WARNING Looking up qualities on O:\plot-k32-2021-08-24-16-01-…plot took: 5.64070725440979. This should be below 5 seconds to minimize risk of losing rewards.
2021-10-04T11:38:55.649 harvester chia.harvester.harvester: WARNING Looking up qualities on E:\plot-k32-2021-08-17-01-01-…plot took: 5.692751169204712. This should be below 5 seconds to minimize risk of losing rewards.
2021-10-04T11:38:55.766 harvester chia.harvester.harvester: WARNING Looking up qualities on M:\plot-k32-2021-06-11-00-54-…plot took: 5.810096263885498. This should be below 5 seconds to minimize risk of losing rewards.
2021-10-04T11:38:55.780 harvester chia.harvester.harvester: WARNING Looking up qualities on L:\plot-k32-2021-07-14-22-53-…plot took: 5.823573589324951. This should be below 5 seconds to minimize risk of losing rewards.
This sounds the exact same issue.
Are you using external USB hubs / multi drive containers or docks?
Do you have a mix ntfs mounts and drive letters for your plots.?
Individual USB 3.0 / USB 2.0 connections from the MB direct to drive, x4 USB 3.0 AIC direct to drive, and one of these.
Oh yeah, E: and O: are hard drives! And all Drive letters.
Hmm.
I must be honest I’m not even 100% I’ve sorted mine yet.
Your not using ntfs mounts, but all drive letters, which I was fairly sure is what caused my issues. By me using both.
So in your case I can only really recommend trying to update drivers.
I used snappy driver installer from source forge, as Windows can be a pita to update drivers at times.
And look at event viewer to see what errors / warnings that’s recording.
Also making sure drives and hubs are not sleeping.
I posted a guide in this thread for that.
As my drives were set to not sleep, but my hubs / 5 bay docks could.
I was looking at getting one of those 3.2 gen 1 hubs, but after reading somewhere apparently they don’t always play nicely if using non USB c ports.
Bit long but I’ll link article as it could help someone.
( not sure relevant to you )
Certainly not fixed for me, just had a run of 8 all just over 5 sec.
But, no log errors/ warnings so the new drivers have helped.
You know that with a number of us seeing this, it’s likely not an individual driver, bad disk, or some things one of us can find and point to. It’s very much seems more generic, so systemic to chia sw. We’re talking programming here. Points to he chia sw is producing this, not any of us particularly, so a likely conflict/programing or compatibility issue.
Wonder if it has been submitted?
I’ve looked through Google, few ppl having the issue, on github it’s just being fobbed of as user hardware as far as I can tell.
I’ve not taken it to keybase, wanted to be sure I’d done my checks first.
I read a post on here saying to up plot check times from 120 sec to a rather large number, cured it for them, but when I do that, it still searches every 120 seconds…
Yeah, that is another problem. Which variable did you change in your config.yaml? Starting with v1.2.6 or a bit lower, they changed it. However, during the update, they don’t check the original value that you had in config, and to do you a favor, they don’t include the new variable in config.
Found it, here is the link:
Search for “plots_refresh_parameter:”
IMO, those parameters are basically a function of your box capabilities and the number of drives / plots. As such, it should be easy for Chia software to give a ball-park value for them or dynamically change them as the system is up and running, not ask people to try something that they don’t really understand.
That’s the reason for the config.yaml init (delete). The init gives the new setting as i understood. I had manually edited mine, but this caused me to try the redo init., with hopes to solve this.