To understand what’s going on, you need to see error message. I used stotkis build before and some scripts out of the box copy stdout to file for logging. Unfortunately it suppresses stderr stream.
To work around this, run the chia_plot.exe with only necessary parameters and direct stderr into stdout like so:
command 2>&1
If you discover an error saying something like “core dumped”, you are out of memory and script crashes
I saw stuff like this happen frequently in Windows, I switched to Linux and it happened less but still occurred a few times.
One thing that seemed to help (no clue why) was to not use the “finaldir” arg for mad max, and just use a separate background rsync script to move the plot at the end to the final location.
my suspicion for this kind of stuff is generally a hardware failure somewhere but without error messages its not really easy to know for sure. But in general, after I found something like this had happened, if I poked around and investigated the temp1/temp2 drives, I would find that one or both of them had gone unresponsive, would vanish from disk manager and/or File Explorer, etc., basically needed a reboot (sometimes two) to get things to start working again.
it happened a lot less for me in Ubuntu so maybe consider trying that as well
My friend has the same CPU as me, but he is also using a RAM disk.
He has been using the same command line as above with (32 threads) over 10.000 plots without any problem.
I think it’s because of my D:\ NVME (2 TB) or F:\ SATA (16 TB) drive.
They are also a lot slower than my E:\ NVMe (4 TB) and G:\ SATA (16 TB)
When I plot in the Chia GUI. 7 plots (2 TB NVMe) and 8 plots (4 TB NVMe) at the same time.
My 4 TB NVMe is always faster, where it takes a lot of time at 100% for my 2 TB NVMe to be finish.
From alot of what I’ve seen mm can stop for a cpl of reasons.
Commonly nvme temps or bad ram.
Even if you test the ram and it passes, it can still cause issues.