I am facing a problem, and as you easily guess it is on my save :tongue.gif:
After closing minecraft, it seemed to have crashed, nothing responding but no error message.
I thought its allright, game is still in beta, etc, but when i went to open my favourite world, it completes loading and then again it leads to a frozen save selection screen.
I really don't want to lose this world, i have been working on it for 4-5 days or so.
Don't know if it helps, but the world opens up just fine in MCedit.
EDIT: If you need a video, i would be happy to record one.
It behaves the same way on mine, crashing if I load the world before it actually finishes loading. I wonder if you have a mod installed? Did you at one point then remove it?
I can't fix it now, but when my utility comes online, I will be able to do much more for it. Until the, make a new save and have fun in that one.
The power went out last night, which caused the machine I had running a server to shut down unexpectedly. I had been backing up the level.dat file regularly, but haven't been backing up the Regions folder since I didn't know that was something I should be doing. When I went to restart the server with the backed-up version of level.dat, I got "Wrong Location!" errors spammed to the server. It appears to be only two locations, 1, -4 and 2, -6, but I can't figure out how to fix this problem. I have no save data from this world on my client machine (or it's hiding somewhere I can't find)
I am able to load the correct world as it was when I first started playing on it, but I can't seem to get it to load in all of the changes that have been made since then.
Is it possible to fix this from the back up of level.dat, the broken region folder, and the clean region folder?
Edit: I've narrowed the problem down to the r.0.-1.mcr file ...not sure if this is helpful or not :0\
I will be able to troubleshoot this properly when my save analyzer (whose name changes every post I make) is finished. It seems like there is a broken chunk somewhere in the region file, and when the game tries to load it, it shits itself.
My save is corrupt I believe. In a large area around the coordinates (-177, 59, 266) I will get stuck, with the screen shuttering and shaking. Animations don't work either in this state and its impossible to even write in the chat to teleport home with commands. The only way i found to get out is to use MCedit to move player location.
This one's easy to fix, i'll have it fully done in no time.
Done. Fully repaired. your map is one of the first that didn't have rampant corruption and chunk errors everywhere, and it still had the original map seed! very impressive. I took the liberty of backing it up for you, as backup.dat .
I sent you a pm and you fixed my save already and it works fine.
BUT when i break my sky castle and try to fill a giant hole i found in the ground WITHOUT editing(only seems to be breaking the castle that does it really) when i try to move in that area on the ground where the castle would of hovered I encounter the same freezing up problem as before.
I can play it without delting the castle or plugging the hole just. It's an eyesore to have the castle in the sky and stuff.
So you able to delete it fill the hole and delete the little staircase coming OFF my glass walkway in the sky and get it to run?
I still want my glass walkway just i got a staircase coming off it that leads to the castle that i want gone as well as the castle and the hole ot be plugged.
IF you don't feel it's worth trying to do I understand. I'll just play without it being deleted. I fyou say yes I'll upload the save.
Go ahead. what's another drop in the ocean :tongue.gif:
If I understand the MCR format correctly, if the (first) offset index sector is screwed, it would be very difficult to locate the chunk bouundaries in the file?
Fault tolerance could be improved by having a marker between chunks as well as the offset index...
The sectors are all a fixed size, so even if the sector index is totally trashed, you can recover most (maybe even all) intact chunks by trial and error. a sector is 4kB, and the first 2 sectors are taken up by the index and the timestamp. each subsequent sector contains chunks. just attempt to read a chunk every 4kB, you'll get most of them :smile.gif:
The sectors are all a fixed size, so even if the sector index is totally trashed, you can recover most (maybe even all) intact chunks by trial and error. a sector is 4kB, and the first 2 sectors are taken up by the index and the timestamp. each subsequent sector contains chunks. just attempt to read a chunk every 4kB, you'll get most of them :smile.gif:
But what I mean is, (automatically) there is no way to differenciate a sector containing (compressed) chunk data from sectors containing the chunk size and version number, if you don't know where to start (other than working right from the beginning I mean). I can see how you could reconstruct the initial index sector by inspection, provided the rest of the chunk size data is intact, but it could be mighty tedious.
But if you can get the location info from the chunk data, you could back-calculate the offset it should have, is that right?
-snipped a lengthy description of a server problem-
Link to megaupload (3 world files: corrupted file (17-3-2011), last working backup (15-3-2011) and a old file (december 2010) total 68MB): http://www.megaupload.com/?d=2D4OMKZT
Many Thanks for your help!
Matthijs
Ok, you have a sort of corruption which I used to see a lot, and it used to be quite easy to fix because of the rendering bugs it caused in mcedit, but since mcedit has updated, it seems much harder to track down. I think I managed to remove it from a localized area around the location you specified. You will probably find more laggy areas. I will look at the save again when I have finished my analysis tool.
also, in future, try mediafire. its much faster.
marked partially repaired.
eragon666w4.rar
edit - oops, I used rar instead of zip. you can open that, right?
I think I fixed it. That bit in the PM about 'chunk (x,y) located at (a,b)' was amazingly useful. I didn't even need to try to run it, I knew exactly where to look.
For the record, this is one of the things that my save analyzer will check an automatically repair.
marked as completely fixed, unless it still doesn't work.
GENERAL ANNOUNCEMENT
My fixed saves directory is nearing 500MB in size. When it reaches 1GB, I will begin deleting the oldest saves. I'm not made out of hard drives (no matter how much I wish I was :tongue.gif:)
But what I mean is, (automatically) there is no way to differenciate a sector containing (compressed) chunk data from sectors containing the chunk size and version number, if you don't know where to start (other than working right from the beginning I mean). I can see how you could reconstruct the initial index sector by inspection, provided the rest of the chunk size data is intact, but it could be mighty tedious.
But if you can get the location info from the chunk data, you could back-calculate the offset it should have, is that right?
yes. the metadata indexes in the beginning of the region files are ordered in ascending x and ascending y. the first index corresponds to that region's (0,0) chunk. The second, the (1,0) chunk. The 32nd, the (0,1) chunk. There are 1024 indexes, and each index is 4 bytes, 1024 * 4 = 4096, exactly 1 sector.
basically, if you had a region file with a trashed index sector, you could attempt to read data from every sector, and from the ones that you got chunks from, you could rebuild the index by filling in the position and size of the chunk to the index entry at the location specified by the chunk's internal position.
Computers exist to do mighty tedious things for us. It might take at most a few seconds on a reasonable machine to rebuild the entire index of a fully loaded region file.
Also, the actual position of the chunks in the region file is determined only by where there's room. the system will save chunks to the first available unclaimed group of unclaimed sectors large enough to hold the entire compressed chunk.
Also, in addition to the chunk, each sector contains a small header detailing the length of the compressed data and the compression method used to compress it. Finally, sectors that have no chunks are typically zeroed out (and can be detected as continuous regions of zeroes)
Hey dude, got an real problem i really tried everything but nothing helps i hope u can help me :smile.gif:
EDIT: sorry i fix the problem, i update mc edit and just movemy player and save the chunks
Did you get stuck, unable to move or place blocks, but free to rotate and break them? if so, post the link again, and go back to where it happened so I can find it easier.
EDIT-
WHEW OH MY GOD THAT TOOK SO LONG
24 separate posts, with a maximum of 12 consecutive posts.
I DODECAPOSTED.
I found this one in the forum list so I thought I'd give it a try. The error occurs just in front of where I've saved the game (between x: 143 and 144, y: 65, z: -156) and it appears to be the entire chunk there. I've uploaded the save to mediafire:
I think I fixed it. That bit in the PM about 'chunk (x,y) located at (a,b)' was amazingly useful. I didn't even need to try to run it, I knew exactly where to look.
For the record, this is one of the things that my save analyzer will check an automatically repair.
marked as completely fixed, unless it still doesn't work.
GENERAL ANNOUNCEMENT
My fixed saves directory is nearing 500MB in size. When it reaches 1GB, I will begin deleting the oldest saves. I'm not made out of hard drives (no matter how much I wish I was :tongue.gif:)
Aww its still giving me a ton of errors that seem to repeat, there is none at astart up just when i join. here is the log file. its a messss http://dl.dropbox.com/u/22659347/server.log
The local power utility decided to cut the power right in the middle of a critical construction project in our world. When the power came back on two hours later, the world folder could no longer be found by the game. I made the change to rename level.dat_old as suggested, but no success. I hope you can help, and I really look forward to the tool you are creating to help world-builders fix their own problems.
Specs: Gateway PC with Intel i7 (870 @ 2.93GHz 2.93GHz); 8 GB RAM; 64 bit OS; Windows 7; NVIDIA GeForce GT330; Java ver 6.0_24 (both 32 and 64 bit versions); browser IE-8
I'm quite confident that I have a corrupted chunk, but because I've largely built vertically rather than horizontally, I'm not sure where it is. I know it's very close to my spawn point, but beyond that I'm just not sure. Very often, when I get a bit north of my spawn point, Minecraft will slow down to about 1 frame per second, max. RAM usage stays around 18%; CPU usage doesn't seem to crack 45%. This behavior does not begin on other saves, but once it has triggered on this save (my main one), it will persist across worlds.
I've tried using tools to locate the corrupted chunk, but the ones I could find are either not updated for the new save system or, with Minetographer, simply not working.
Computer is a Latitude D630 with 2 GB of RAM, 2.4 GHz Core 2 Duo, Intel GMA 965 Integrated Graphics. Java version is Version 6, Update 24; the auto-updater tells me that it's the latest version.
I already posted about this in the Server Administration forum, somehow I didn't see this thread before! Here's the link to the other thread I made: viewtopic.php?f=10&t=230971
Save: http://www.ericolsen.us/FalconV.zip
It's a 54MB file, if it would help I know the region file where the problem is and have duplicated the problem with just it and tiny regenerated nearby regions, that would cut it down to about 5MB. Let me know.
Edit: here's the smaller one - http://www.ericolsen.us/FalconV_small.zip
System specs:
Server: tried on multiple servers:
Server1: VMware ESX Virtual Machine
OS: MineOS x86 (MicroCore Linux)
RAM: 4GB (2GB for Minecraft)
CPU: 2 virtual CPUs (host has 4x2GHz CPUs -2xdual core)
Java: OpenJDK Runtime Environment (build 1.7.0)
Server2: on the same ESX host
OS: Ubuntu Linux x64
RAM: 4GB (1GB for Minecraft)
CPU: 2 virtual CPUs
Java: Java SE Runtime Environment (build 1.6.0_24-b07) 64-bit
Server3: My game box
OS: Windows 7 Pro x64
RAM: 8GB (just ran the .exe, so whatever that dedicates for Minecraft...)
CPU: 3GHz dual core
Java: Java SE Runtime Environment (build 1.6.0_24-b07) 32-bit
This seems to be a corrupt chunk(s). It is inside the r.-1.0.mcr region, but not the entire region. I don't know the exact area that is affected. as it almost seems to fluctuate a little sometimes, but maybe that's just me losing my mind? I specifically test at x:-149 y:75 z:32, and x:-144 y:102 z:84. I know it spreads further than those two, but doesn't affect much of the rest of the region so far as I can tell.
This issue only occurs in SMP, SSP seems to work fine as far as I can tell. If a player places a block, a couple seconds later it will disappear, then a few seconds after that (or so) the block will reappear and stay indefinitely. If a player breaks a block, it doesn't immediately drop an item, instead a couple seconds later the block will reappear. A few seconds later, usually more like 10 or so, the block will re-disappear and the item will appear. It may take seconds or more to pick up the item. As far as I can tell, everything lags. Chatting does, as well as any commands. Again, only for that user, anyone outside the region is lag-free. Server and client CPU/RAM usage appears normal, the F3 latency display goes nuts. It seems to jump up a bit right away when I get near/in the area, and then steadily grows.
I have backups as old as 5 days ago, but this has been happening for more than 5 days. I didn't know it has been happening for days until just recently a player reported it to me saying it's been this way for a little while, but hasn't always been this way. I think at first she thought it was just really bad lag, but later realized that nobody else had this problem, and then found out she didn't when she left her area, and I did when I entered her area. I do have the original 1.2_02 chunk files, but I tried to use that to generate a new r.-1.0.mcr, it generated a new world (with the same seed) instead of converting the chunks it seems.
I renamed r.-1.0.mcr and let it regenerate that region, and it's perfectly lag-free, but that region contains a lot that we'd rather not lose! I don't mind if some chunks have to be regenerated, just hoping to avoid losing the whole region. I tried to replace a group of chunks that seems to be the worst of it by opening up the world in MCEdit with the regenerated/clean region, exporting the group of chunks, then opening up the world with the corrupt region in MCEdit, deleting those chunks (or I may have "replaced with air" or something...), then importing the clean mountain. Unfortunately this didn't fix the lag issue.
I think it's on or around my giant hole the castle is in the sky clearly visible and the hole i was taking about is behind the castle.
And just to remind you. I just want the glass stairs going up from the glasswalkway gone(not the glass walkway itself)
Hope you can do it, thanks!
This server file is rather large, it was an SMP server with about 15+ people on it. After migrating to a new server we decided to start with a new map and the admin was supposed to re-enable the backup system, but that apparently never happened, as we discovered when a power outage shut down the server that there was no rollback. These are the only files to work with, so no backup files.
I am very realistic about what the chances of recovery are in this situation (slim). While I'm not sure what to look for to check for corrupted metadata, it may have survived. Only one player was online at the time of the crash. Three chunks near the spawn area are definitely corrupted. Spawn is in the area X-92, Y-65, Z-9. One particular chunk near the area of 38,63,8 can be deleted but when I try to repair it nothing works.
If any data retention of any form is plausible that would be the optimal solution, no matter what state the world file ends in (including chunks that have to be deleted and filled or regenerated). If nothing can be done we'll simple start on a new map an make sure backup protocols are in place this time.
I've been using both NBTedit and MCEdit and they seem incredibly straight-forward programs. I would love to know any other diagnostic programs or resources to learn more about the mapping data and what to look for in these situations.
It behaves the same way on mine, crashing if I load the world before it actually finishes loading. I wonder if you have a mod installed? Did you at one point then remove it?
I can't fix it now, but when my utility comes online, I will be able to do much more for it. Until the, make a new save and have fun in that one.
marked as come-back-to-later
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
I will be able to troubleshoot this properly when my save analyzer (whose name changes every post I make) is finished. It seems like there is a broken chunk somewhere in the region file, and when the game tries to load it, it shits itself.
marks as come-back-to-later
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
This one's easy to fix, i'll have it fully done in no time.
Done. Fully repaired. your map is one of the first that didn't have rampant corruption and chunk errors everywhere, and it still had the original map seed! very impressive. I took the liberty of backing it up for you, as backup.dat .
marked as fully repaired
akblabla-newworld.zip
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
Go ahead. what's another drop in the ocean :tongue.gif:
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
Debatably. but it gets far more attention here. which is the point. people with beta issues, in the beta board, see this thread. about beta saves.
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
http://dl.dropbox.com/u/22659347/Progre ... -Hopey.zip
The sectors are all a fixed size, so even if the sector index is totally trashed, you can recover most (maybe even all) intact chunks by trial and error. a sector is 4kB, and the first 2 sectors are taken up by the index and the timestamp. each subsequent sector contains chunks. just attempt to read a chunk every 4kB, you'll get most of them :smile.gif:
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
But what I mean is, (automatically) there is no way to differenciate a sector containing (compressed) chunk data from sectors containing the chunk size and version number, if you don't know where to start (other than working right from the beginning I mean). I can see how you could reconstruct the initial index sector by inspection, provided the rest of the chunk size data is intact, but it could be mighty tedious.
But if you can get the location info from the chunk data, you could back-calculate the offset it should have, is that right?
Ok, you have a sort of corruption which I used to see a lot, and it used to be quite easy to fix because of the rendering bugs it caused in mcedit, but since mcedit has updated, it seems much harder to track down. I think I managed to remove it from a localized area around the location you specified. You will probably find more laggy areas. I will look at the save again when I have finished my analysis tool.
also, in future, try mediafire. its much faster.
marked partially repaired.
eragon666w4.rar
edit - oops, I used rar instead of zip. you can open that, right?
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
I think I fixed it. That bit in the PM about 'chunk (x,y) located at (a,b)' was amazingly useful. I didn't even need to try to run it, I knew exactly where to look.
For the record, this is one of the things that my save analyzer will check an automatically repair.
world-hopey.zip
marked as completely fixed, unless it still doesn't work.
GENERAL ANNOUNCEMENT
My fixed saves directory is nearing 500MB in size. When it reaches 1GB, I will begin deleting the oldest saves. I'm not made out of hard drives (no matter how much I wish I was :tongue.gif:)
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
yes. the metadata indexes in the beginning of the region files are ordered in ascending x and ascending y. the first index corresponds to that region's (0,0) chunk. The second, the (1,0) chunk. The 32nd, the (0,1) chunk. There are 1024 indexes, and each index is 4 bytes, 1024 * 4 = 4096, exactly 1 sector.
basically, if you had a region file with a trashed index sector, you could attempt to read data from every sector, and from the ones that you got chunks from, you could rebuild the index by filling in the position and size of the chunk to the index entry at the location specified by the chunk's internal position.
Computers exist to do mighty tedious things for us. It might take at most a few seconds on a reasonable machine to rebuild the entire index of a fully loaded region file.
Also, the actual position of the chunks in the region file is determined only by where there's room. the system will save chunks to the first available unclaimed group of unclaimed sectors large enough to hold the entire compressed chunk.
Also, in addition to the chunk, each sector contains a small header detailing the length of the compressed data and the compression method used to compress it. Finally, sectors that have no chunks are typically zeroed out (and can be detected as continuous regions of zeroes)
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
Did you get stuck, unable to move or place blocks, but free to rotate and break them? if so, post the link again, and go back to where it happened so I can find it easier.
EDIT-
WHEW OH MY GOD THAT TOOK SO LONG
24 separate posts, with a maximum of 12 consecutive posts.
I DODECAPOSTED.
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
Absolutely beautiful, I can't thank you enough!
GENERATION 17: The first time you see this, copy it into your sig on any forum and add 1 to the generation. Social experiment.
Aww its still giving me a ton of errors that seem to repeat, there is none at astart up just when i join. here is the log file. its a messss
http://dl.dropbox.com/u/22659347/server.log
Thanks a ton :biggrin.gif:
Specs: Gateway PC with Intel i7 (870 @ 2.93GHz 2.93GHz); 8 GB RAM; 64 bit OS; Windows 7; NVIDIA GeForce GT330; Java ver 6.0_24 (both 32 and 64 bit versions); browser IE-8
Save file location: http://www.megaupload.com/?d=AAG70RCJ
Many thanks
I've tried using tools to locate the corrupted chunk, but the ones I could find are either not updated for the new save system or, with Minetographer, simply not working.
The file is http://www.mediafire.com/file/a86ztkrtvt424tb/captainktainerworld1.rar .
Computer is a Latitude D630 with 2 GB of RAM, 2.4 GHz Core 2 Duo, Intel GMA 965 Integrated Graphics. Java version is Version 6, Update 24; the auto-updater tells me that it's the latest version.
I already posted about this in the Server Administration forum, somehow I didn't see this thread before! Here's the link to the other thread I made: viewtopic.php?f=10&t=230971
Save: http://www.ericolsen.us/FalconV.zip
It's a 54MB file, if it would help I know the region file where the problem is and have duplicated the problem with just it and tiny regenerated nearby regions, that would cut it down to about 5MB. Let me know.
Edit: here's the smaller one - http://www.ericolsen.us/FalconV_small.zip
System specs:
Server: tried on multiple servers:
Server1: VMware ESX Virtual Machine
OS: MineOS x86 (MicroCore Linux)
RAM: 4GB (2GB for Minecraft)
CPU: 2 virtual CPUs (host has 4x2GHz CPUs -2xdual core)
Java: OpenJDK Runtime Environment (build 1.7.0)
Server2: on the same ESX host
OS: Ubuntu Linux x64
RAM: 4GB (1GB for Minecraft)
CPU: 2 virtual CPUs
Java: Java SE Runtime Environment (build 1.6.0_24-b07) 64-bit
Server3: My game box
OS: Windows 7 Pro x64
RAM: 8GB (just ran the .exe, so whatever that dedicates for Minecraft...)
CPU: 3GHz dual core
Java: Java SE Runtime Environment (build 1.6.0_24-b07) 32-bit
This seems to be a corrupt chunk(s). It is inside the r.-1.0.mcr region, but not the entire region. I don't know the exact area that is affected. as it almost seems to fluctuate a little sometimes, but maybe that's just me losing my mind? I specifically test at x:-149 y:75 z:32, and x:-144 y:102 z:84. I know it spreads further than those two, but doesn't affect much of the rest of the region so far as I can tell.
This issue only occurs in SMP, SSP seems to work fine as far as I can tell. If a player places a block, a couple seconds later it will disappear, then a few seconds after that (or so) the block will reappear and stay indefinitely. If a player breaks a block, it doesn't immediately drop an item, instead a couple seconds later the block will reappear. A few seconds later, usually more like 10 or so, the block will re-disappear and the item will appear. It may take seconds or more to pick up the item. As far as I can tell, everything lags. Chatting does, as well as any commands. Again, only for that user, anyone outside the region is lag-free. Server and client CPU/RAM usage appears normal, the F3 latency display goes nuts. It seems to jump up a bit right away when I get near/in the area, and then steadily grows.
I have backups as old as 5 days ago, but this has been happening for more than 5 days. I didn't know it has been happening for days until just recently a player reported it to me saying it's been this way for a little while, but hasn't always been this way. I think at first she thought it was just really bad lag, but later realized that nobody else had this problem, and then found out she didn't when she left her area, and I did when I entered her area. I do have the original 1.2_02 chunk files, but I tried to use that to generate a new r.-1.0.mcr, it generated a new world (with the same seed) instead of converting the chunks it seems.
I renamed r.-1.0.mcr and let it regenerate that region, and it's perfectly lag-free, but that region contains a lot that we'd rather not lose! I don't mind if some chunks have to be regenerated, just hoping to avoid losing the whole region. I tried to replace a group of chunks that seems to be the worst of it by opening up the world in MCEdit with the regenerated/clean region, exporting the group of chunks, then opening up the world with the corrupt region in MCEdit, deleting those chunks (or I may have "replaced with air" or something...), then importing the clean mountain. Unfortunately this didn't fix the lag issue.
Here's the link.
http://www.megaupload.com/?d=KIUJ0BSW
I think it's on or around my giant hole the castle is in the sky clearly visible and the hole i was taking about is behind the castle.
And just to remind you. I just want the glass stairs going up from the glasswalkway gone(not the glass walkway itself)
Hope you can do it, thanks!
I am very realistic about what the chances of recovery are in this situation (slim). While I'm not sure what to look for to check for corrupted metadata, it may have survived. Only one player was online at the time of the crash. Three chunks near the spawn area are definitely corrupted. Spawn is in the area X-92, Y-65, Z-9. One particular chunk near the area of 38,63,8 can be deleted but when I try to repair it nothing works.
If any data retention of any form is plausible that would be the optimal solution, no matter what state the world file ends in (including chunks that have to be deleted and filled or regenerated). If nothing can be done we'll simple start on a new map an make sure backup protocols are in place this time.
I've been using both NBTedit and MCEdit and they seem incredibly straight-forward programs. I would love to know any other diagnostic programs or resources to learn more about the mapping data and what to look for in these situations.