Distant Horizons LOD data is sometimes not backed up / restored properly

[floral-qua-floral]

The Distant Horizons mod creates LOD data of the world to allow for much higher render distances than can be achieved with normal chunk rendering. The LOD data is saved within its world's directory in a .sqlite file, at data/DistantHorizons.sqlite. It seems that this file sometimes becomes damaged during the process of backing up or restoring it, which causes the LOD data to permanently fail to load upon re-entering the world after it has been restored from a backup. Of note is the fact that this file is exceptionally large compared to any other individual file I've seen in a Minecraft world, which may be why Textile Backup has problems handling it. The issue doesn't seem to always occur but it does seem fairly consistent; I've tested probably at least 6 times and I was only able to restore a world without damaging its LOD data in a single test.

I was also able to confirm that manually backing up the world with copy-paste never causes LOD data to be damaged; the error only occurs when doing it through the mod.

Versions:

• Minecraft 1.20.2
• Fabric Loader 0.15.3
• Fabric API 0.91.2
• Textile Backup 3.1.2-1.20
• Distant Horizons 2.0.1-a-1.20.2

Steps to reproduce:

1. Create a world and wait a few minutes in it for a fairly wide region around spawn to get LOD data built. (I would suggest going into Distant Horizons's options menu and setting its CPU impact to Balanced; it defaults to Low Impact which generates LOD data very slowly.)
2. Run /backup start to create a backup of the world.
3. Once it's finished, run /backup restore latest to restore that backup.
4. Once the world has shut down and the backup has finished being restored, re-enter the world. If the issue has occurred, some distant terrain may load, but eventually it will stop before all the distant terrain has been filled in. The amount of distant terrain that appears can range from almost none to almost all of it. From this point onwards, moving around won't cause low-detail terrain to fill in the chunks the player unloads, and the log will print errors every tick.

Here is a log file in which I follow a slightly modified version of that procedure, in which I:

1. Enter a world I have already created and allowed LOD data to fill in,
2. Run /backup list to double-check that no backups of the world exist already,
3. Run /backup start to create a backup,
4. Use /fill to place a large number of blocks, so that I will be able to visually confirm that the world has been rolled back after restoring the backup,
5. Run /backup restore latest to restore the backup,
6. Re-enter the world and confirm that the world has been rolled back and the LOD data has been damaged.

Prior to these tests, I disabled shutdownBackup & backupOldWorlds and enabled deleteOldBackupAfterRestore, so that I could more easily manage the backup files. However, I was able to confirm that the issue still occurs with the default configuration.

I am able to provide three world files from the same test that produced that log file:

1. A manually-created copy of the world file from my test, created before Step 1 using copy-paste in my file manager.
2. The world file from after the test.
3. The backup file from the .minecraft/backup folder (still available after restoration due to deleteOldBackupAfterRestore being disabled).

However, they are all above the maximum file size that Github will allow me to upload (25 MB), so attaching them to the issue report is challenging. The bulk of their size is from the LOD data files, which are the most relevant part, so those cannot be omitted, and they are too large to send even in isolation. If it would be helpful, I can probably stick the worlds or LOD files into Google Drive or something and provide a sharing link.

[Szum123321]

I don't think I can do anything about this. There would need to be some way to let HD know to properly close the sqlite database.

[DuendeInexistente]

The file is huge, and unnecessary on a backup because it's just a cache that's rehenes automatically. I'd much rather it be omitted by default.