I have same problem as @Isaiah7300. Specifically, any numerals typed in a page have a high chance of causing the entire page to be deleted on a subsequent opening of the book. Or, sometimes, the numbers are just turned to '#'s. Makes book/quill unusable.
Seems to have something to do with particular sequences of digits (e.g. it's almost always triggered by 3 digits, space/comma, 2 digits, space/comma, 2 digits, such as you may have in coordinates, but never triggered if you have all as 2 digits...). Though it's been hard to pin down the exact necessary/sufficient conditions...
Similar. Bedrock, Win10. My survival world (a Realm) that's only ~80MB is taking up dozens of _Giga_bytes in memory and takes forever to both load AND save on exit.
When I'm in the world there is significant lag; every couple of minutes, I have to wait 10-20 seconds for the last several actions to take effect.
This is true on RealmsANDlocally. I have gone through the Realms backup history, downloading the worlds and playing locally, and it is appears to be the 1.17.32 update. Every world through 1.17.31 is fine; the moment it goes to 1.17.32, they start having problems.
Notably, the memory leak/spike seems to get worse over time... the more times I load the world, the bigger the memory spike and the longer it takes to load.
Also, one of these backups that I downloaded has now ballooned to a file size (as displayed in the game menu) of 682.0MB, though not all of the files have had that effect. And worth noting that a couple of other local worlds that are <10MB, do not appear to have this problem. So far, it's just the 1.17.32 worlds I've downloaded from the Realm.
The log file at db\lost\025701.log accounts for essentially all of the uncompressed file size.
Only one of the .ldb files (db\025713.ldb) has a substantive discrepancy between compressed and uncompressed size...
So on a wild guess (and many other tests), I simply deleted both of those files, re-imported to Minecraft, and the world runs perfectly both locally and on Realms on both PC and Switch: no lag, no long load time, no memory spike, and all of the data is there so far as I can tell... (though presumably that filed contained some kind of relevant world data?)
I am still testing with multiple reloads of the world, and presumably if this issue happened once, it could certainly happen again... but the above still seemed useful diagnostically and as a short term fix.
Just an update: the PC workaround I posted above is still working. We've played many times on that Realm/world without issue (on both PC and Switch) since I implemented that fix. (Though never did figure out what the heck 025713.ldb corresponded to...)
I'd be curious if other PC users have attempted something similar (harder for console users); all you need is an archive viewer/editor. If you have tried it, did you also notice the log file was massive? Were you able to identify any unusual .ldb files?
@Mega_Spud
I have same problem as @Isaiah7300. Specifically, any numerals typed in a page have a high chance of causing the entire page to be deleted on a subsequent opening of the book. Or, sometimes, the numbers are just turned to '#'s. Makes book/quill unusable.
Seems to have something to do with particular sequences of digits (e.g. it's almost always triggered by 3 digits, space/comma, 2 digits, space/comma, 2 digits, such as you may have in coordinates, but never triggered if you have all as 2 digits...). Though it's been hard to pin down the exact necessary/sufficient conditions...
Here's a video: BookQuill-Bugs_5.mp4
Bedrock 1.17.0 Realms server. Also happened in 1.16.
Does not appear to happen in a local creative world.
Thanks in advance for any help.
-Chris
Similar. Bedrock, Win10. My survival world (a Realm) that's only ~80MB is taking up dozens of _Giga_bytes in memory and takes forever to both load AND save on exit.
When I'm in the world there is significant lag; every couple of minutes, I have to wait 10-20 seconds for the last several actions to take effect.
This is true on Realms AND locally. I have gone through the Realms backup history, downloading the worlds and playing locally, and it is appears to be the 1.17.32 update. Every world through 1.17.31 is fine; the moment it goes to 1.17.32, they start having problems.
Notably, the memory leak/spike seems to get worse over time... the more times I load the world, the bigger the memory spike and the longer it takes to load.
Also, one of these backups that I downloaded has now ballooned to a file size (as displayed in the game menu) of 682.0MB, though not all of the files have had that effect. And worth noting that a couple of other local worlds that are <10MB, do not appear to have this problem. So far, it's just the 1.17.32 worlds I've downloaded from the Realm.
Here's an example world affected by this problem: https://drive.google.com/file/d/1bXnMAFmXI74eYFcT2WWurFwDbVk2t1Cx/view?usp=sharing
However, couple things to note:
So on a wild guess (and many other tests), I simply deleted both of those files, re-imported to Minecraft, and the world runs perfectly both locally and on Realms on both PC and Switch: no lag, no long load time, no memory spike, and all of the data is there so far as I can tell... (though presumably that filed contained some kind of relevant world data?)
I am still testing with multiple reloads of the world, and presumably if this issue happened once, it could certainly happen again... but the above still seemed useful diagnostically and as a short term fix.
Just an update: the PC workaround I posted above is still working. We've played many times on that Realm/world without issue (on both PC and Switch) since I implemented that fix. (Though never did figure out what the heck 025713.ldb corresponded to...)
I'd be curious if other PC users have attempted something similar (harder for console users); all you need is an archive viewer/editor. If you have tried it, did you also notice the log file was massive? Were you able to identify any unusual .ldb files?
Just fyi, I also disabled a custom texture pack (https://bedrocktweaks.net/resource-packs/), but I'm doubtful that played a role...
(And here are specs, which I hadn't posted before...)