amorelli

I noticed the same thing. I propagated my old server.properties file and things worked fine. I took a look at the server log and noted the warning that players would not be able to connect unless I change the config to nethernet. So I changed the config and restarted the server. Then I was not able to connect anymore. I changed it back to raknet and again it works fine. So the behavior I see is the exact opposite of what the TRANSPORT TYPE ERROR message says.

Here’s a further characterization of the problem. I noticed this in the article about the dungeons 2 cape promo for minecraft:

Make sure you use the same Microsoft account across all the games, whether you play solo on your own device or join a friend’s couch co-op session!  For pre-orders of physical copies of the game, see additional details below.*

People can’t actually follow that advice snice this bug prevents someone from using the same microsoft account when joining a friend's couch co-op session, instead adding them to the game as a guest/local user.

Still not working in 1.26.30. Connecting to BDS from switch, 2nd player doesn't log in to their normal account.

And, just to clarify about player data - when you put the world back onto the server and connect to it with your normal account, your position and inventory will be correct again. That information seems to be stored in the database rather than the level.dat file.

It seems like I’ve been able to resolve my problem. I believe that the key was refreshing level.dat. There are probably multiple ways to go about it but here’s what I did. I have a baremetal ubuntu 24 host (not docker or other container, or vm) hereafter referred to as BDS, and a separate windows machine I connect from to play minecraft, hereafter referred to as CLIENT.

1) On BDS, stop the server software, save off a copy of the world directory somewhere as a backup. Go into the world directory and zip everything into a file called myworld.mcworld:
$) cd world_dir
$) zip myworld.mcworld *
It’s important that the zip is created from inside world_dir so that the archived file paths are relative to that directory.

2) Move myworld.mcworld to CLIENT and double-click it to import it to minecraft.

3) Once imported, open the world. This step normalizes the level.dat file. You’ll notice that you’re not at your last x,y,z and your inventory is wrong, even if you’re logged into your normal minecraft account. That’s expected since you’re using local player data. Save and quit.

4) In the worlds menu in Minecraft, open the edit menu (pencil icon) on the world and export the world. This creates a new .mcworld file.

5) Move the newly exported .mcworld (which contains a normalized level.dat) to BDS

6) On BDS rename the file so it ends in .zip instead of .mcworld. Create the world directory that matches level-name in server.properties and unzip into there.

7) Start the server software.

Again, the high level goal is to sanitize any irregularity with the level.dat file. I also notice that now I get a ping measurement for my bds in the server list, which I did not before. This particular world was originally generated on a Switch, uploaded to Realms, downloaded and put onto a dedicated server. So, the level.dat file was perhaps already a bit traumatized though it was working before 26.30.

Good luck.

For me, Minecraft doesn't close. It times out trying to connect. Please notice BDS-23063

Which was resolved as a duplicate of this issue. It has more information.

Yeah, I just put in a new level name in server.properties causing it to create a new world, but I have the same problem.

I didn’t see Smity’s comments before making my last.
But, I don’t have any experiments or add-ons enabled for my world. I think the log corroborates this but please let me know if there’s something else specific I should check:

If I change transport=raknet to nethernet in server.properties it fails to connect more quickly with “Multiplayer Connection Failed” message:

With raknet the connection times out:

I’m experiencing the same issue trying to connect to my BDS from windows after updating to 26.30. Additionally, when I try to check the status of my BDS on https://mcsrvstat.us/bedrock it gives an error “Server didn’t return minimum required data.”

This is different from trying to check the status of a nonsense IP address, which gives no particular error.

This is consistent which what I’m seeing on Switch and Switch 2 trying to connect to my BDS. That is, that the split screen player is still not logging in correctly.

I’d be curious if anyone else on Nintendo is able to successfully connect two accounts to a Realm or BDS. I’m curious if the difference for me is trying to connect to a BDS or being on Nintendo. I tried Switch and Switch 2.

Awww. Not working on my BDS server from what I can tell. The split screen players still seem to connect as a temp/local accounts.
However, when I look at “Account” from the “Settings” menu the correct MCID does appear for the split screen player, which I’m pretty sure was not happening before. Their gamer tag is still absent though, their name appears in the server list as player1(1), and everything else indicates they are not logged into their account. For example, the split screen player should see the same game state as when they join the server as player 1.
I am curious if anything was intentionally done to fix this, or if we’re basically seeing jitter in functionality which isn’t validated.

It does seem plausible that there’s something different about a split screen login on Xbox vs. other consoles. Minecraft has to associate nintendo users with their minecraft login locally on the device, presumably in the user-specific save data, since there’s no external association between their nintendo account and minecraft account. In the case of Xbox, connecting to online services on the console might be the same thing as logging into their minecraft account. Maybe there’s a whole step for connecting split screen which is skipped in the Xbox case. If true, that seems like a reasonable first guess about where the bug is…

I’ll submit a world when I get the chance. I expect to find that a newly created world will reproduce the issue, which seems to have nothing to do with the actual world file. A new world file will hopefully be small.

To reiterate the problem, the Minecraft client fails to log in to a linked account when joining any world from split screen. It doesn’t seem to matter what world it is, or whether the world is local, an external BDS, or a realm.

Has anyone working on this tried joining a Realms world from a Nintendo (via split screen), with two different Minecraft accounts? Check the accounts section of the menu to verify MCID and gamertag for player 2. Any talk of “lost progress” or “inventory” would seem to be confusion about what’s actually happening, which is that players joining via split screen cannot log in.

I tried some troubleshooting to shed light on whether this is a problem with a local login token on the console, or a problem in the split screen login process.

I think I’ve ruled out any kind of problem with a local login token from save data.

I asked GPT a couple questions and it informed me that the Minecraft login info for a Switch user is stored as a token in the Minecraft save data, since there’s no Nintendo API for linking your Minecraft account. If that’s true, then it seems like either the Minecraft client introduced a bug with Chase the Skies that fails to use that token correctly in the split screen case, or some save data format change broke old tokens.

To rule out the latter, I logged out of my Minecraft account from the main Minecraft menu on my switch, then deleted my user’s Minecraft save data on the switch. When I started up Minecraft again, I confirmed that I wanted to create new save data instead of download my cloud data. I then had to re-link my Minecraft account using the QR code with my phone. This should create a new login token to store in the new save data. I then restarted Minecraft with a different Nintendo account and connected to our BDS, then tried joining that game via split screen from my account with its newly minted token. This did not work; I still got a local guest account. Perhaps this makes us more suspicious of the split screen login flow as opposed to some sort of stateful problem with a login token from the save data.

I’m still curious to know if anyone at mojang has been able to reproduce the issue, find the root cause, or identify a potential fix.

Sure. But, it should probably just be an option when you’re joining. If the Nintendo or Playstation account has an MCID login associated with it you get the option, i.e. “Sign in to <MCID> or guest?” If not then you’re just a guest.
It makes me curious about a couple things I might try later. I wonder if two people trying to join a featured server split screen can use both of their accounts? - I assume not from what we’ve seen.

Dane, if by self-hosting you mean administering your own BDS then I can tell you it won’t help with this problem.
Our normal mode of play for a long time was split screen from our Nintendo Switch to our Bedrock Dedicated Server. But the problem here is that someone who joins split screen simply cannot connect to their minecraft account, instead being joined as whatever local/temporary/guest account everyone has been trying to describe here.

Personally, I’m pretty skeptical that the actual problem statement is understood by the team when I’ve read Jay’s comments. I think the following very simple characterization could help:
Two different minecraft accounts cannot join a server via split screen.

If Jack spends some time playing on the server alone from the Nintendo then Jill spends some time playing on the server alone from the Nintendo then they decide to play together, they will find that they cannot get both of their accounts logged in via split screen. Only 1P’s account will be logged in.

This is my experience with our own BDS, and the problems people are describing with their paid realms are identical.

• We are using this bug to track reports of losing progress when playing on a Realm in split-screen, which is affecting some players

I think this is a strange characterization of the problem. As others have stated, a better description would be that multiple players cannot log into their individual accounts via split screen on Nintendo Switch or Playstation. Instead, they are logged in as a guest account. The progress made on that guest account is not lost across sessions. The problem is that the player should have been logged into their normal Minecraft account in the first place. Their Minecraft account is not lost in any way. If they connect as 1P or from a different device (and thus actually log into their account), the player state is all correct.

Sorry this isn’t new info, but Jay’s comment makes me feel the need to chime in on clarifying the problem.

Thanks so much for looking at this, the feature as it used to work adds a lot of value for me and my kids.

I’ve still got my fingers crossed that it’s been fixed in the next drop.
Though I can’t help but feel that the silence here says a lot.
If the ability for split screen players to log in was irreversibly removed either on purpose or accident, it probably makes more sense to leave a bug open and let people lose hope or forget than to announce the situation loudly.
Maybe that’s overly cynical or bleak but I just don’t understand the silence.