Terry Petersen

This appears to have fixed issues with maps and movement, however new issues resulting in lag have appeared with regards to the crafting changes (also dragging items across crafting table slots).

Also an issue that was not as prominent before was placing torches while mining. If placed quickly enough it would take a torch from your inventory placing it for a split second before vanishing, since joining the BETA program this is much easier to encounter and also seems to occur when moving and placing torches.

I have also encountered a minor inventory glitch where shift clicking 6 brown mushrooms into a chest with 44 mushrooms, left a "ghost" item in my character inventory and did not update the chest inventory.
This took some persistence to remedy manually dragging the stack from the chest into my inventory until it finally updated the stack, then logging out and back in before moving it back into the chest, to get the correct item count of 50 brown mushrooms I had to repeat the logout/login step again.

The main thing is that the map glitches now appear to be corrected.

Unfortunately I cannot do justice to the explanation of how LevelDB works nor it's use in Minecraft.

What I do know is that it's not at all surprising to me to see hiccups like this when reading and writing millions of records concurrently.

I mean lets assume your render distance is 16, this would create a grid 32 (+1) chunks squared the +1 is due to the fact that chunks are rendered based on what blocks should be visible not just when you enter/exit a chunk.
Oh and each chunk, that's a 16*16*256 set of blocks 16*16 square that is 256 blocks high for a total of 65,536 blocks.

Every time you move, that 32 (+1) squared set of chunks gets moved.

Doing the math on this 32 (+ 1) squared grid results in 67,108,864 to 71,368,704 blocks being loaded in memory at any given moment.

If you only move in one direction, let's say North, you'll be generating 2,162,688 (a row of 32 (+1) chunks) new blocks 15 chunks North of you all while saving changes to the 2,162,688 blocks that are no longer needed in memory 16 blocks South of you.
Want to move diagonally? That'll be 4,128,768 to 4,259,840 new blocks in your given direction and the same again needing to be saved in the opposite direction.

To make matters worse, all these blocks are relative so they have to take into consideration the neighbouring chunk's blocks to complete cave systems and alike.
Add on top of this mobs and items and your looking at some serious data.

I'll be pleasantly surprised if in fact Mojang does find a working solution to avoid corruption using the same database format.

The issue is caused by a number of known faults in the leveldb file system, Minecraft PE/Win 10/Console uses this to store game data with, one of the most common of these faults is reading/writing to RAM too quickly for the filesystem. Now while leveldb a very fast and exceptionally lightweight database structure it is seriously prone to corruption, Mojang has created their own version of this database for Minecraft but they have clearly not been able to resolve the issues which lead to corruption.

In theory one way to correct a damaged database would be to re-write the files however this would result in more lost data due to corrupted segments needing to be ignored entirely, re-written data would therefore be incomplete and need to be regenerated which would probably cause chunks to be completely different, in other words you house might end up being half destroyed and replaced with a random tree.

Things you can try to mitigate database corruption are:

1. Avoid traveling at any speed other than normal walking, the faster you move the more the game has to generate and save to disk.

2. Take regular "breaks" while traveling (don't just go in one directory for a solid hour, stop every 10 minutes or so to ensure the game has time to process).

3. Avoid making large and quick, consecutive changes to the map such as mining a 1x1 column to bedrock and filling it with TNT.

4. Decrease your render distance.

It is worth remembering that Minecraft both reads and writes to the map files at the same time, the larger your render distance the more chunks needs to be loaded and unloaded while you move, this is just added stress to the database which we now know is not reliable enough to handle these changes.

Start making backups of your worlds, currently there is no known way to revert the damage to your world files without Mojangs developers creating a fix.
At least if you take a backup you can salvage some playability.

I can now confirm beyond much doubt that hardware has little to no effect on this issue. I upgraded my hardware a couple of days ago and there has been no noticeable reduction of CPU consumption on my Minecraft world.

However, unlike before decreasing render distance to 5 does (sometimes) impact how long the CPU spikes last.
Same story though, moving any distance causes CPU usage to spike to 100% for approx 15 seconds (With render distance 5) and using portals to the nether has a 50/50 chance of crashing the game.

Unfortunately if you are now experiencing CPU spikes like this when standing still there is no current way to repair you map files.
If you have a backup of that map the best you can do is restore it and avoid long distance and fast traveling.

If you get the occasional CPU spike when moving to a new area stop everything and just wait for it to pass, this appears to mitigate the currently irreversible damage to map files.
It would be wise to export a copy of your world if you are not currently experiencing non-stop latency.

Your graphical settings will have no effect on this.

This may have something to do with how fast the player moves in a given direction, when my world was corrupted I had been riding a horse, I restored that world from a backup, climbed on a new horse and am now experiencing this issue again.

My best bet is that the speed of player movement may cause too many updates in quick succession for the database/storage device to handle potentially resulting in "fragmentation" of database files, especially when traversing new areas where chunks have not yet been generated, as I was.

If this is the case a method be added to the world settings to "defragment" or sanity check the '*.ldb' files in the same way you can run a compact and repair on an Access database to free the deleted records and correct varying levels of fragmentation/corruption may help the user mitigate the issues this causes as not everyone has access to backups or is willing to loose a "days work".