@luxe

thank you for looking into it. That's great, then i'm only burning som watts until i get non-lazy and fix my filenames or whatever.

with your miner things are going pretty fast, with 3 pc's i get through my 80TB in less than 30 seconds. And without windows acting up, which it did before. I'll probably show up in a better position in your pie charts when i have been running jminer for 50 days....

@luxe

It seems to work fine, but i have not checked if it misses out on the partly truncated files, or if it skips files after having stumbled upon a truncated one. Not sure how i should go about testing that. console output does not indicate any problems, and i do get blocks, but then i also have lots of terabytes of files that are in order.

The internal renaming scheme seems to be a viable solution that keeps the rest of the code as it is.
Perhaps make a file renaming tool that simply renamed plot files in current dir, to reflect their real size?

0.4.3 works fine on my 3 pcs, it seems to be about 50 to 100% faster than the POC java miner, and smoke stopped coming out of the cabinets...

i have a few suggestions :

• if a drive have plot files where the filename indicates a longer file than the actual file size, the console line
  read 'D:/plots' (8TB 87GB) in '23s 278ms' will show too many TB's - seems like the TB count is derived from filenames, not actual file size. I noticed bc i had a 4TB drive that was reported as 5TB, that confused me a bit.
  As plotting sometimes gets interrupted it is common (at least for me) to have a file where the filename indicates more nonces than it actually have.

• when showing the winner, show the human readable name also.
  not sure how to find it, perhaps the wallet knows,
  perhaps a file where the user can put in known names for burst addresses he knows.

• The FINISH line could print out the time version of the deadline too

Great miner! It works very efficiently and is super easy to set up, well documented too, in the properties file