Well the world compressed is 6GB, so I think that would be too much, and the funny thing is, your program fixed everything, So I had to search through the backups to find the bad stuff. lol
So I got you all the bad or wrong regions which were only 6 region files. And some other data files.
I have a suggestion, when I run the fixer with -v it prints out a line for every region file checked, and out of 2800 only 12 had problems,
is it possible to only print a line with just the bad regions listed ? It has always listed so much output, that I never really checked to see how many regions files were bad.
Something like this would have helped
unk problems:
-------------------------------------------------------------------
| Problem | Corrupted Wrong l. Etities Shared o. Total chunks |
-------------------------------------------------------------------
| Counts | 1201 3211 0 0 2805964 |
-------------------------------------------------------------------
Sorry for the delay, I had car problems I had to take care of.
So, I ran the beta-2-1 and it fixed the problems, but it had a few problems.
First I ran a check on the world, it checked 140 map.dat files and after 139 it paused for a long time, it did 139 in seconds, and 5 to 10 minutes on the last one but it eventually continued on to the region files.
When checking 2800 region files it would get to the last one and crash, I had it send several crashes to the ftp site. I believe it fixes the last chunk, and then tries to print the report and thats where it might be crashing.
Then I did the --delete-corrupt and that fixed the chunks, but and it would get to the last one, pause for a while and then crash again.
Fixing all the chunks took about two hours, but that was alot faster then running it seven hours and hardly putting a dent in the broken ones.
Thanks, for helping get our chunks fixed. I'm willing to do any testing or give you and data/region files that you might need to help you get the program working. Just let me know what you need and I'll get it for you.
I even copied the file to ram and it still runs slow.
I also download the windows version and tried to run it but I got an error.
elcome to Region Fixer!
(version: 0.1.3)
############################################################
############## Scanning separate region files ##############
############################################################
********** 0 / 1 0% [ ] ETA: --:--:--
*** Error while scanning:
*** r.23.-17.mca
**********
*** Printing the child's Traceback:
*** Exception: <type 'exceptions.OverflowError'> Python int too large to convert
**********
*** File scan.pyc, line 194, in scan_region_file
*** None
**********
*** File scan.pyc, line 278, in scan_chunk
*** None
**********
*** File nbt\region.pyc, line 539, in get_chunk
*** None
**********
*** File nbt\region.pyc, line 520, in get_nbt
*** None
**********
*** File nbt\region.pyc, line 486, in get_blockdata
*** None
**********
Traceback (most recent call last):
File "region-fixer.py", line 304, in <module>
File "region-fixer.py", line 201, in main
File "scan.pyc", line 402, in scan_regionset
scan.ChildProcessException
Hopefully you can learn something from the region file.
I also tried the qui, it looks really nice +10
It lacks one thing, I couldn't figure out how to check just one region file. It seems to just want to check a whole world directory.
I'm currently working to fix a really huge world that has many many corrupt chunks, and in trying to fix them I think I found a flaw with your program.
Its running on a Centos 6 Linux with 16G Memory and 6 core AMD processor
I am not a python coder so I am probably wrong, but I'll explain.
We have 2800 region files, and a scan says 2600 have problems, we are trying to fix as much as possible to copy peoples schematics for the new clean world.
When I run the region fixer on just one region that has 444 corrupt chunks, it takes 2 hours. So I started looking at the code.
From looking at it I think as you loop through a region file you read each chunk, if you get an error reading that chunk, the you call the zip routine to delete the chunk. This is where I think the problem is. When you delete a chunk the zip routine rewrites the entire region file skipping the bad chunk.
This means deleting 444 bad chunks will cause that region file to be rewritten 444 times.
If this not what is happening, then why does it take 2 hours to fix 1 region file that is only 4MB
If I am correct, then I think a better way would be to extract all the chunks from the region file skipping the bad ones or replacing them and then to reassemble them all back into a copy region and then rename the region.
I think this would run much faster than single deletes over and over.
But you know your program better, so maybe you can help our slowness problem.
2 other quick questions, your documentation shows a .0.2.0 version, but I cant find that or the qui version, were they ever released ?
and during the del-corrupt process, is it possible to be a little more verbose so we can tell what is happening.
Either way, your program has helped lots of times, so BIG THANKS.
0
So I got you all the bad or wrong regions which were only 6 region files. And some other data files.
Here is the link http://cardinalcraft.net/drop/world.tar.gz
I have a suggestion, when I run the fixer with -v it prints out a line for every region file checked, and out of 2800 only 12 had problems,
is it possible to only print a line with just the bad regions listed ? It has always listed so much output, that I never really checked to see how many regions files were bad.
Something like this would have helped
Happy hunting
Thanks
0
So, I ran the beta-2-1 and it fixed the problems, but it had a few problems.
First I ran a check on the world, it checked 140 map.dat files and after 139 it paused for a long time, it did 139 in seconds, and 5 to 10 minutes on the last one but it eventually continued on to the region files.
When checking 2800 region files it would get to the last one and crash, I had it send several crashes to the ftp site. I believe it fixes the last chunk, and then tries to print the report and thats where it might be crashing.
Then I did the --delete-corrupt and that fixed the chunks, but and it would get to the last one, pause for a while and then crash again.
Fixing all the chunks took about two hours, but that was alot faster then running it seven hours and hardly putting a dent in the broken ones.
Thanks, for helping get our chunks fixed. I'm willing to do any testing or give you and data/region files that you might need to help you get the program working. Just let me know what you need and I'll get it for you.
Thanks
0
Here is the region file http://cardinalcraft.net/drop/r.23.-17.mca
it has 782 corrupted chunks out of 1024
No luck on beta-2, it still runs real slow.
I even copied the file to ram and it still runs slow.
I also download the windows version and tried to run it but I got an error.
Hopefully you can learn something from the region file.
I also tried the qui, it looks really nice +10
It lacks one thing, I couldn't figure out how to check just one region file. It seems to just want to check a whole world directory.
Thanks
0
I'm currently working to fix a really huge world that has many many corrupt chunks, and in trying to fix them I think I found a flaw with your program.
Its running on a Centos 6 Linux with 16G Memory and 6 core AMD processor
I am not a python coder so I am probably wrong, but I'll explain.
We have 2800 region files, and a scan says 2600 have problems, we are trying to fix as much as possible to copy peoples schematics for the new clean world.
When I run the region fixer on just one region that has 444 corrupt chunks, it takes 2 hours. So I started looking at the code.
From looking at it I think as you loop through a region file you read each chunk, if you get an error reading that chunk, the you call the zip routine to delete the chunk. This is where I think the problem is. When you delete a chunk the zip routine rewrites the entire region file skipping the bad chunk.
This means deleting 444 bad chunks will cause that region file to be rewritten 444 times.
If this not what is happening, then why does it take 2 hours to fix 1 region file that is only 4MB
If I am correct, then I think a better way would be to extract all the chunks from the region file skipping the bad ones or replacing them and then to reassemble them all back into a copy region and then rename the region.
I think this would run much faster than single deletes over and over.
But you know your program better, so maybe you can help our slowness problem.
2 other quick questions, your documentation shows a .0.2.0 version, but I cant find that or the qui version, were they ever released ?
and during the del-corrupt process, is it possible to be a little more verbose so we can tell what is happening.
Either way, your program has helped lots of times, so BIG THANKS.