CM

I was able to play it for another hour just now.

I think I might have figured it out... I was thinking about what's in common between all of the systems I've tried this on and been able to reproduce it with. All of them were running the onboard intel graphics. To try to test that theory, I purchased a Radeon Pro 2100 card for my computer, and was able to play MC successfully without issues for over two hours straight just now – the longest by far that I've been able to play in almost two years. Will see how things work when I try to play it again with my son later this week, but as of right now, it's looking like that's a direction to dig at least.

I hadn't tried playing since June due to the issues, and had a bit of time to myself this evening, so I thought I'd give it another go. I just upgraded to 1.20.4 and am still experiencing the issue, unfortunately.

If there's anything I can do to help troubleshoot the issue, just let me know.

Something that's odd though, that I'm hitting now (but haven't seen before.) I'm currently in a new area underground that I haven't explored before (a giant cave system.) In the area that's not rendering correctly, object interactions aren't being displayed. But when I turn around in an area that I explored previously, destroying a block causes the block to disappear correctly.

The odd rendering is more curious as well; eg. I'm seeing grass render on top of nothing.

Are there any troubleshooting steps I can run through to try to figure out what's going on? I miss being able to play Minecraft with my son.

I upgraded to Debian 12 and am still experiencing the same issue.

I just found out about the F3+A to force a reload of all chunks. When the game is "ok" (not glitching) this works fine. When the game is glitching, it causes MC to lock up, forcing me to switch to a different terminal and kill the process.

 I just upgraded to 1.19.4 this morning, and the issue still happens.

I was able to find the logs in ~/.minecraft/logs, but there's nothing particularly useful that I can see in there (no real errors, etc.)

:~/.minecraft/logs$ cat latest.log | grep -v INFO
[13:30:33] [Render thread/WARN]: Missing sound for event: minecraft:item.goat_horn.play
[13:30:33] [Render thread/WARN]: Missing sound for event: minecraft:entity.goat.screaming.horn_break
[13:30:35] [Render thread/WARN]: Shader rendertype_entity_translucent_emissive could not find sampler named Sampler2 in the specified shader program.

I don't think it's an issue of "too old". My current machine has an Intel J5005 CPU, which was first released in 2017.

My wife's Windows machine (which doesn't have this issue) has the exact same motherboard and i5 CPU as my previous computer which also experienced the issue.

Is there any way to get logging enabled on the loader to try to get it to provide error logs, etc.?

Something that I just tested; going into creative mode and using an egg will render the object correctly. Placing/removing blocks, interacting with objects, etc. still doesn't work correctly.

One more screenshot where I'm breaking the invisible dirt block; you can see the break lines, just not the block itself.

Attached a third screenshot where I'm standing on top of the invisible block, from a different camera PoV.

Attached a second screenshot (also with the F3 screen displayed) where I'd filled in the hole and stacked a block on top of the ground. You can see the wireframe surrounding where the block should be rendered, but nothing is displayed other than the wireframe.

Screenshot attached; recticle is pointed at the hole at the time; if I was to walk into the dirt block I'd fall into the hole. Other players would see this as a hole as well, including if I sign out and back into the game. At this point I'd been signed into the world for less than 5 minutes. Sometimes (like yesterday afternoon,) the issue can take half an hour or more to happen. On one occasion, the issue temporarily resolved itself for 10 minutes or so; at the time I was beyond the rendered edge of the world, and all of the sudden the missing blocks were displayed, and worked correctly for another 10 minutes or so.

My current computer is running a Pentium Silver J5005 quad-core processor with 8GB of memory, but other computers also exhibiting the issue are more powerful (but less energy efficient) i5 machines.

I'll add as well – you can't just remove the .class file from the log4j jar, because it detects that you modified the jar, and re-extracts it >.<

Expected file libraries/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.jar to have hash ade7402a70667a727635d5c4c29495f4ff96f061f12539763f6f123973b465b0, but got dd6b13ef700b6efff3dbb268a3cd4592f7f2ed4617a6a86e5f4ec988bb500d05

Unpacking org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.jar (libraries:org.apache.logging.log4j:log4j-core:2.14.1) to libraries/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.jar

@tryashtar, any way to get this reopened?

Hopefully this is actually resolved soon...Nessus flags this every time it runs against my (personal) MC server. I'd think that it'd be straightforward to follow Apache's guidance and move up to 2.17.1, as they say that every version older than that has issues.

https://logging.apache.org/log4j/2.x/

My Debian 11 install had been working since an upgrade a few weeks ago, but this morning it's back to the error again :/

I completely rebuilt my computer with a fresh Debian 11 installation, and still experience the issue.

I'm still getting the error tonight on Debian 11. It did download a new version of the launcher, but the error/experience is still the same.