Minecraft Version

1.19.x

Version

v1.102.2

Details

When playing on a raspberry pi model 4b with 8gb ram in a multiplayer server (switchcraft), some monitors but not all of them produce garbled output or even the output of another monitor in the vicinity. This happens with all monitor renderers in the config file

Examples are:

I'm not umnikos, so it was clearly picking up another monitor.

Soon after all monitors became like this

Not all monitors are affected by this issue, but I'm too smooth brained to realize what they've got in common. My own inventory system(artist) also becomes like that every now and then.

In regards to logs there's not much of note, most I get is some amount of this and I'm not even sure it refers to the monitors:
[Render thread/WARN]: Received passengers for unknown entity

Can you attach a screenshot of F3 and your logs please.

It might also be worth changing your config to use the VBO monitor backend and seeing if that helps at all.

I'm afraid this is unlikely to be fixed though. This sort of bug is incredibly difficult to debug without access to the hardware at hand - you're probably in the best place to do so.

It's worth noting that this one seems correct to me. I've seen the same in-game shop and I think it's supposed to look like that.
https://user-images.githubusercontent.com/7207103/219225631-b9083111-7122-4d78-8fcf-ca6653d5d353.png

It's worth noting that this one seems correct to me. I've seen the same in-game shop and I think it's supposed to look like that. https://user-images.githubusercontent.com/7207103/219225631-b9083111-7122-4d78-8fcf-ca6653d5d353.png

you see, it's umnikos shop on my shop. as you can see it doesn't share it's decoration

It might also be worth changing your config to use the VBO monitor backend and seeing if that helps at all.

I'm afraid this is unlikely to be fixed though. This sort of bug is incredibly difficult to debug without access to the hardware at hand - you're probably in the best place to do so.

I have attempted all monitor renderers, they work all out the same, I don't mind giving out ssh with X11 redirection, it's slow, but it shows all issues as-is

Can you attach a screenshot of F3 and your logs please.

https://mclo.gs/iJrQhWH

This could either be an issue with the Raspberry Pi's GPU or an issue with the Arm64 architecture in general. What OS are you using?

This could either be an issue with the Raspberry Pi's GPU or an issue with the Arm64 architecture in general. What OS are you using?

Latest Raspberry Pi OS (formerly known as raspbian) with everything up to date.
I could consider it to be a GPU issue if there were monitors that didn't have it at all, but some are completely fine

I have attempted all monitor renderers, they work all out the same,

Was the corruption under the VBO renderer the same as under the TBO one (and just to confirm, you did close the game between changing config options? I'm not sure if reloading works right now)?

That's very odd, that almost suggests the monitor data itself is garbled. I guess it might be worth trying to reproduce this in a more minimal environment (i.e. a single player world) and taking a heap dump with VisualVM (though possibly email it to me, don't post that publicly!).

I can probably have a go at running the pack on my Odroid, at least to rule this out as an AArch64 issue.

I have attempted all monitor renderers, they work all out the same,

Was the corruption under the VBO renderer the same as under the TBO one (and just to confirm, you did close the game between changing config options? I'm not sure if reloading works right now)?

That's very odd, that almost suggests the monitor data itself is garbled. I guess it might be worth trying to reproduce this in a more minimal environment (i.e. a single player world) and taking a heap dump with VisualVM (though possibly email it to me, don't post that publicly!).

I can probably have a go at running the pack on my Odroid, at least to rule this out as an AArch64 issue.

Correct, I agree it has something to do with monitor data being garbled itself as I've attempted both with a restart in between changes. I'm working with wireless speed link and a pretty high packet loss according to mtr(least I could achieve was 20-30% at second hop)

I will need to learn how to use VisualVM, but once I do I'll send one, any suggestion on a program I could run to benchmark it?

I can probably have a go at running the pack on my Odroid, at least to rule this out as an AArch64 issue.

Alas, it's stuck on an ancient version of OpenGL, so I cannot even get Minecraft to boot.

I will need to learn how to use VisualVM

When you launch VisualVM, you should get a list of current Java programs on the left hand side. Find the Minecraft one, and double click it.

Then navigate to the "Monitor" tab - you should see something like this:

Press the heap dump button. This will take a few seconds, but should open the heap dump on a new tab. You can then right click it on the left and press "Save as".

You can actually switch to the "Objects" option on the heapview and then search for Terminal objects (and then look at the child TextBuffer objects). There will be a lot, so being able to reproduce with fewer monitors would be helpful!

I'm apparently unable to replicate this in singleplayer and whenever ping is lower(either that or some factor changed which I'm not aware of), which adds to the belief that this is a network issue rather than a graphical one.
Could you pass me your email so I can send the dump of a multiplayer session when the bug appears again?

[email protected]

Any update on this @dimaguy?

Unable to reproduce this further, I've also gotten my laptop back and now use it for gaming. Now that I know which steps I need for debugging, Ill close this for now and reopen it if I find the issue later on

Good to know, thanks! :)