Linux Bedrock Server Rubberbanding issue

Update: The issue is still present. I have made sure everything is up to date. I have tried adjusting values in server properties with no luck. It happens on 2 different servers running on the same machine. This machine was fine before the update. It is Hardwired using Gigabit Ethernet. It seems to happen more when more people are joined. Again, this issue was not present before the most recent Minecraft Update.

The next things I am going to try are installing the server on Ubuntu 24.04 on the same machine. I am going to put a different NVMe drive in when I do this.

Update Update: I lied about being up to date. just saw the patch notes from yesterday. There are ones that identify the issue I was having. Will test now. I also just switched the server to Ubuntu. If I don’t respond then my issue is resolved.

Update Update Update: The extreme rewinding is no longer present, but there is a “everything freezes for 5-10 seconds and then the world catches up” issue. I am not being rewound, but previous action are happening very fast to catch up. The frequency seems to be about the same.

This is still happening unfortunatley. I believe it’s related to the change to server-authoritative movement being removed and forced into “rewind”.

Example - a stack of logs.

- If I hold down the place button and move, I get about 3 placed before rewinding.
- if I spam the place button while moving, I get 4 or 5 before rewinding.
- if I move, stop, place, move, stop, place, then I don’t get any rewinding.

I may try changing the value of “player-position-acceptance-threshold=0.8" to something higher. I currently have it at one, I wonder what would happen at values like 2, 5, or 10?

Changing the value I listed above changed nothing that I can tell.

I have this issue too on linux bedrock server 1.21.73.01. My server is a year old or so, fairly big survival world. Hopelessly unplayable for several weeks now, due to rubber banding, block placement getting out of sync between server and client. We have to restart the client every 3-5 minutes basically if we want to play which is getting very tiresome.

So, anyway I did suspect that I need to look closely at server.properties. I downloaded a fresh version of linux bedrock server and check those defaults in server.properties. There are many new settings and many that are removed that relate to client and server auth…

I applied the defaults and still broken unfortunately. 3-5 minutes of vigorous survival building and thebn then the client/server start to disagree on which blocks are broken and which position the client is in… and rubber banding during boat travel.

I may have found a fix for myself. After making sure my server properties file had the most up to date settings options (they have changed over major updates), I played with the settings.

I found that changing the compression threshold to 1 and changing the compression mode to “snappy”. fixed all issues for me.

I will say that compression threshold may have to be adjusted from server to server and I assume that it goes in multiples of bits (1, 2, 4, 8, 16, 32, 64, 128, etc.) I tested all the way up to 512 and found no difference on my end, however changing from zlib to snappy fixed my issues (for now).

Following my last post, I’ve now played around with the newly added settings in server.properties. I’m able to get pretty stable performance for a LAN linux server with the modified settings shown below.

Overall,

• we were able to stay connected and play continuously for around 90 minutes. previously, we had to restart every 5 minutes or so as the client and server would eventually disagree on this blocks were broken

• Previously, I had assumed that I wanted the server to be less strict and more forgiving of client discrepencies. HOWEVER, it turns out that making the server very strict and unforgiving of client discrepencies is the best outcome (and introduces no noticeable lag for my setup)

Since changing the settings, players on the server have noticed:

• block breaking is 99% accurate and solid. there was an instance of one broken block showing broken on the client but the vines

• the client/server synchronisation of position appears to be 100% solid. There are no more instances of bumping into free air as the client and server seem to agree on the state of blocks and the clients location.

• latency with the server is not noticeable at all. However, I need to test this with a remote connection when there is a longer ping… will need to get back on this.

• fast boat travel is pretty good. As usual (for the last 3+ years) chunks can be slow to load when you are travelling 5000 blocks in a few minutes. However, there was a little bit of rubber banding at one point, but it resolved itself within a few seconds and didn’t require any restart. So, I would consider this a non-issue, from what I’ve seen

We’ll keep playing and will report back if we notice any further glitches

these are the settings changes that worked well:

server-authoritative-movement-strict=true
# Set at true to be more strict toward the Player position and be less permissive in accepting the client info.
# This means clients will receive more position corrections. This will impact Player around moving block if there is high latency

server-authoritative-dismount-strict=true
# Set at true to be more strict toward the Player dismount position.
# This means clients will receive a correction on their dismount position in higher latency situation

server-authoritative-entity-interactions-strict=true
# Set at true to be more strict toward the Entity interactions.
# This means clients will be more strict towards Entity interactions. This will impact Players interacting with each other in higher latency situations.

player-position-acceptance-threshold=0
# This is the tolerance of discrepancies between the Client and Server Player position. This helps prevent sending corrections too frequently
# for non-cheating players in cases where the server and client have different perceptions about when a motion started. For example damage knockback or being pushed by pistons.
# The higher the number, the more tolerant the server will be before asking for a correction. Values beyond 1.0 have increased chances of allowing cheating.

player-movement-action-direction-threshold=0
# The amount that the player's attack direction and look direction can differ.
# Allowed values: Any value in the range of [0, 1] where 1 means that the
# direction of the players view and the direction the player is attacking
# must match exactly and a value of 0 means that the two directions can
# differ by up to and including 90 degrees.

Oh, I just noticed this setting I used in my ‘worked well’ settings from previous post…

player-movement-action-direction-threshold=0

this property is the only one that is “not” strict…

• 0 = very lenient

• 1 = very strict

Anyway, “0” is the setting we have now and it seems stable (I have no reason to change it, since it’s working)…

fyi, our server is having issues again… rubber banding. Which is very weird because it was working much better. I’m going to try different settings and will report back..

The rubber-banding issue still exists for us unfortunately.

I’ve tried a lot of settings and sometimes it settles down for a while, but only in the short term. Players are back to restarting their client

Ultimately, the client (iPad) is regularly getting out of sync with the server and from that point they never reconcile the issue so a restart of the client is required.

eg. block placement, block breaking and player position.

While the issue is less aggressive than it was before, it is still an issue I face. At this point it does not rubberband back to a previous state. However, now actions and NPCs freeze for about 5 second then move super fast to catch up ticks. This is normally better than the rubberbanding issue, however this can result in multiple enemy hits after a freeze.