Cannot log in with microsoft on the latest supported version. #709
Comments
|
try deleting your cache that fixed mine |
|
I am seeing this problem too - but on latest version as speaking now 1.19.51.01. I did clear all the mpelauncher files and data and start over, the Microsoft Log In button is still not working. |
That's a different problem, see here for a workaround flathub/io.mrarm.mcpelauncher#90 (comment) The problem with xbox login on 1.19.51.01, will be fixed in the next update (no eta) |
Thank you so much!! Appreciate your hard work. I was able to use the workaround for now. |
I can't sign in with Microsoft account only when I use certain wifi, but I use another wifi I can |
|
I have the same problem I am in the version: 1.20.32.03 |
|
Same problem with 1.20.41.02 on a Raspberry Pi IV using Bookworm, mcpelauncher 0.11.4, Bookworm and Jammy debs tested, exact same behavior. |
The microsoft servers are at least in Germany working, even with this launcher. I can login on ubuntu 22.04 on my intel gen8 laptop. This launcher doesn't use the same code for the full login flow than actual Android devices. All the Java Code is replaced by c++, some of them are using java cryptography replaced by hopefully equivalent c++ and openssl calls.
Clear your gamedata and only keep your worlds and avoid switching a lot between major releases of the game. I think a mod to mirror the external server entries to your lan play tab should be possible, this would bypass the silly login requirement. (All the local network traffic goes throw this launcher c and fake java wrappers). If your problem is not mcpelauncher-webview, like you described in a far far away issue then your issue is very complex.
I had to try sign in 3 times (hey, I don't like to touch this xbox live shit as long it works for me)
Yeah this launcher is buggy as a hell, but all alternatives are too slow / hard to setup on my weak hardware |
@pigong That's easier than telling you to debug the launcher, because I cannot reproduce your xbox problems. This c++ snipped ( #include <sys/socket.h>
#include <netinet/udp.h>
#include <sys/types.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <netdb.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <unistd.h>
#include <string.h>
#include <thread>
#include <iostream>
int main(int argc, char**argv) {
if(argc != 3) {
std::cout << "Usage: " << argv[0] << " <ipv4 server addr> <port>\n";
return 1;
}
int sock = socket(AF_INET, SOCK_DGRAM, 0);
sockaddr_in addr;
auto ad = inet_addr("127.0.0.1");
addr.sin_family = PF_INET;
memcpy(&addr.sin_addr, &ad, sizeof(addr.sin_addr));
addr.sin_port = htons(19132);
auto ret = bind(sock, (sockaddr*)&addr, sizeof(addr));
int sockb = socket(AF_INET, SOCK_DGRAM, 0);
sockaddr_in addrb;
addrb.sin_family = PF_INET;
addrb.sin_addr.s_addr = INADDR_ANY;
addrb.sin_port = 0;
ret = bind(sockb, (sockaddr*)&addrb, sizeof(addrb));
bool started = false;
sockaddr_in addrc;
addrc.sin_family = PF_INET;
addrc.sin_addr.s_addr = inet_addr(argv[1]);
addrc.sin_port = htons((short)atoi(argv[2]));
while(true) {
sockaddr_in remoteaddr;
char buf[4096 * 1024];
socklen_t size = sizeof(remoteaddr);
auto len = recvfrom(sock, buf, sizeof(buf), 0, (sockaddr*)&remoteaddr, &size);
if(!started) {
started = true;
std::thread([sock, sockb, xdest = remoteaddr, &rdest=remoteaddr]() {
while(true) {
sockaddr_in remoteaddr;
char buf[4096 * 1024];
socklen_t size = sizeof(remoteaddr);
auto len = recvfrom(sockb, buf, sizeof(buf), 0, (sockaddr*)&remoteaddr, &size);
if(buf[0] == 0x1c) {
char str[] = "MCPE;Tunnel;600;1.0.0;0;3;12321196102327825775;Tunnel level;Survival;1;19132;19133;0;";
int lena = buf[33] << 8 | buf[34];
int lenb = sizeof(str) - 1;
buf[33] = lenb >> 8;
buf[34] = lenb;
memcpy(buf + 35, str, lenb);
}
len = sendto(sock, buf, len, 0, (sockaddr*)&rdest, size);
}
}).detach();
}
len = sendto(sockb, buf, len, 0, (sockaddr*)&addrc, size);
}
}
Then connect to the tunnel lan server |
|
@ChristopherHX just as a quick reply before I look into this more carefully on Sunday: I installed Fedora 39 today on a X86_64 and could instantly connect to MS. That's within the same LAN, but of course a different machine. Unfortunately also launcher 0.11.5 rather than 0.11.4. Looks like it's either the launcher version or the architecture ;-) Thanks for all your suggestions! I am not sure I have the patience to set up a build system and try to debug: the problem is, while I've done stuff like that before, I don't really understand what I am doing... |
|
ubuntu18.04 appimage ok this is a buggy mess |
|
Yes, I can confirm your own observation, and it now looks consistent to me. Just to be clear, both my systems are arm64 (rpi and opi5+): on Ubuntu 22.04 (running on the OPI5+) the deb is broken and (as I just confirmed) the AppImage works (i.e. all the logins work, playstore, network play etc all fine!). Also the lack of snappiness I observed in the flatpak Ubuntu installer does not occur, the arm64 Appimage must somehow be using hardware-gpu-support. This AppImg is 0.11.4 too, but there is a minor version difference, right, the AppImage is 721, the deb is 6... something. Unfortunately the AppImage doesn't work on Rpi5-bookworm, the problem was discussed in the other thread (pi-apps). But it strongly looks like the particular login-problem would be solved implicitly, if the AppImage could be made to work on the Raspberry Pi. I won't be able to try and properly debug the situation in a build-system, but I'll install Debian Bookworm on a x86_64 system, just to see if the AppImage problem is gone there... |
|
So I just had the launcher run on a live System of Debian Bookworm on a x86_64 (Lenovo X1 Yoga, i7 8th gen), and both variations, deb and AppImage worked. Unfortunately though it were newer versions than the ones that appear from the arm64 repo, even the nightly one. The x86_64 deb installed 0.11.5 - running flawlessly without a hickup an all logins - and the AppImage installed 0.11.4.721 which had several problems like the ones you described (having to restart, getting non-fatal error-messages, etc), but ultimately it allowed to login both in Google and MS. So unfortunately I couldn't compare any pair: same-version - different architecture, but when it worked, the 0.11.5 debs were clearly the cleanest ;-) RPI users will be etearnally gratefull if you provide arm64 debs of version 0.11.5, and once the rpi5 is readily available, that could become a pretty popular platform, as MC Bedrock, even in the most recent versions, should perform decently at a really affordable price. |
Hmm 0.11.5 are only nightly builds and that also have the arm64 build bug. The current nightly 0.11.5 will become 0.12.0 once released. (due to enhanced game version compatibility) For rpi5, don't we need 16k page size support first? E.g. parts of the arm64 (m1) code if runtime pagesize is not 4k. Can you try the armhf 0.11.5 nightly version? Does it have the same bug? I mean the build script is basically copied from arm64, but the arm64 is mostly copied from the AppImage script aswell. I'm still surprised how I can build the same code on the same distro twice, once with working xbl and another time without. |
I guess so, unfortunately I don't even know what that means. I read somewhere however, that rpi4 doesn't have the large page size. I don't have an rpi5 yet, and won't get one before January. It's @theofficialgman who understands that level. I can only test stuff on hardware that is likely not available to you. I'll try the 32-bit builds, AppImage and deb, in the next days... |
While it would be nice to have Linux 16K pagesize support (for stock Pi5 on PiOS and Asahi Linux which default to 16K pagesize kernels), for the Pi5 it isn't a dealbreaker. Pi5 can run a 4K pagesize kernel just fine (albeit with very marginally slower performance) with a simple change in the |
That is correct, all the other Pi use 4K pagesize kernels. I was told by Gordon Hollingworth (RPi Ltd chief technology officer) that for the Pi4 and the other older models they have no intention of shipping 16K pagesize kernels. His words were that they were incompatible but, if true, that must be in reference to their GPUs and other hardware design. Every ARMv8 core (like the ones in Pi3/Pi4/Pi5) "should" be compatible with 4K/16K/64K pagesize. |
|
@ChristopherHX so I went through the 32-bit hf-options on bookworm/rpi4: deb and appimage: 32-bit debs cannot install, because the qt6 qml and webengine related dependencies are not available in armhf bookworm. So no way to get it working. I am almost curious, how you provide those in the appimage, the ui starts and google-login works when using the not yet updated version + the "QT_QUICK_BACKEND=software"-trick and some trial and error, but once trying to start actual Minecraft it crashes X/Wayland instantly and horribly ;-), you are prompted for a new login (I think I am seeing the same as @theofficialgman saw when trying the appimage for pi-apps, likely wayland related crash). Bookworm arm64 does provide the qt6-dependencies, and the debs seem not to have the wayland-related problem, so 0.11.5 arm64 seems the most likely candidate to work. I am pretty sure all rpi-users that try to "zocken" on an rpi use the 64-bit os ;-), so my guess is that a 64-bit build is actually more useful than a 32-hf one, even if the later is the "classical" version. |
|
@ChristopherHX - I was going to try to build the latest version, but I found that the build description still lists the qt5 packages. Is there an updated list somewhere? |
@pigong How do you think I built the armhf version here on bookworm?: https://github.com/minecraft-linux/pkg/actions/runs/6846983794/job/18614453120#step:3:1
Look at the pipeline behind the deb ci I linked above. |
|
Well, as I said, I was intrigued. Maybe you got it from qt-company? Or I do something wrong, but this is what it looks like for me: I then did an apt search and got nothing returned containing qt6 webengine and qml. Ah, and thanks for the list, I hope I find time tomorrow to give it a try. |
|
What about these pages https://packages.debian.org/bookworm/qml6-module-qtwebengine, https://packages.debian.org/bookworm/libqt6webenginewidgets6 you can download the armhf deb there. Nothing missing for armhf.
It depends on what apt sources you have configured, but debian bookwork has these packages. As I mentioned before "raspbian armhf was not a full debian, they removed webengine from there repos". I had to either mix raspbian with real debian (aka frankendebian) or create an AppImage with the files from real debian. This means the pi-apps from @theofficialgman can never use armhf apt packages, thank you raspberry pi os distro owners. |
|
Well, to be fair, Raspbian existed, before Debian even provided armhf (I
think ;-) ). Rpi osses were always Debian based, but initially self
compiled from bottom up. Since the switch to 64-bit they're gradually
shifting to Debian, but it's a difficult process.
It might however be possible to add armhf Debian sources to Raspbian, or
find some other way to provide the dependencies for the debs? I remember
the pi-apps scripts contained some tricks, at least in the past.
…On Mon, 13 Nov 2023, 12:30 ChristopherHX, ***@***.***> wrote:
What about these pages
https://packages.debian.org/bookworm/qml6-module-qtwebengine,
https://packages.debian.org/bookworm/libqt6webenginewidgets6 you can
download the armhf deb there. Nothing missing for armhf.
I then did an apt search and got nothing returned containing qt6 webengine
and qml.
It depends on what apt sources you have configured, but debian bookwork
has these packages.
As I mentioned before "raspbian armhf was not a full debian, they removed
webengine from there repos". I had to either mix raspbian with real debian
(aka frankendebian) or create an AppImage with the files from real debian.
This means the pi-apps from @theofficialgman
<https://github.com/theofficialgman> can never use armhf apt packages,
thank you raspberry pi os distro owners.
—
Reply to this email directly, view it on GitHub
<#709 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/APFJH4NPJPSIGIJWKEWXKC3YEIAENAVCNFSM55FTZBRKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBQG44TQMJVG44A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@ChristopherHX - how can I build using qt6? All three modules ask for "FindQt5.cmake"... Is it another branch, or a cmake argument? |
|
branch qt6 is for qt6 of UI and launcher. branch ng is for qt5 of UI and launcher. Both branches are kept in sync by GitHub Actions. Only msa-manifest has a cmake flag, because I didn't migrate that to qt6 myself |
they did not "remove" webengine from the repo. Thats not how raspbian works. Every single package from debian has to be rebuilt so that is compatible with armv6+VFP CPUs like the ones in the pi1 (BCM2835), all other Pis which use BCM2836/2837/2711/2712 are either armv7 or armv8 and are compatible with standard debian armhf. qt6-webengine has simply been failing to build and you can see that in the public logs http://buildd.raspbian.org/status/logs.php?pkg=qt6-webengine a raspbian maintainer has to go any manually correct that package so that it can build |
Still means package is not available and this software cannot be installed as armhf deb file. This software is technically unable to run on armv6, due to android system requirements. How to proceed? A bookworm AppImage? based on your list of 16k kernel defects is a qt6 AppImage a requirement No replacing qt webengine is not practical for me Did qtwebengine ever built for 32bit Raspberry Pi OS? I gave it up waiting for it in 2019 and created an AppImage, then moved on to ubuntu. |
|
@ChristopherHX , I am at the build, and msa went through quite well (just dependency libxkbcommon-dev was missing). Currently trying to configure mcpelaunder and running into the following problem: I can checkout branch qt6, however I get en error missing "FindQt5" for the submodule mcpe-launcher-webview. If I try a You're German, no problem with the terminal language right: Maybe you didn't commit the submodule update hash? Or have another tip how to get on? Currently the cmake run ends like so: |
|
The easierst way is to delete the clone and type
My system is not as far localized to german than yours, my git speaks english. |
|
@ChristopherHX , thanks, that did it! Build went through, but I get a weird error now on package-creation (I prefer using packages, as it should allow me to uninstall easily), it speaks of architecture i386 ???: PS: not sure why you propose to combine dpkg -i with sudo apt install in the build instructions, but the error is the same. PPS: well, I changed the variable in the CpackConfig.cmake from i386 to amr64, and that seems to have done it. But maybe it shouldn't have read i386 in the first place... Anyhow, on I go... PPPS: I am doing this on my kids RPI4, it speaks German. My own computers speak English ;-) |
I added an outdated notice to the wiki of "Compiling the game launcher", that's really old stuff from 2019. The launcher was packaged only for i386 on x86_64 hardware. Armhf required to built manually after adding submoudules. The outdated notice is from 2021. Installing these debs will result in missing binaries. I'm neither the creator of the original wiki nor the original mcpelauncher from 2019 |
|
@ChristopherHX , this feels promising, though I am not there yet. The builds of the three modules went through and I can actually start mcpelauncher-ui-qt, login to google, download the apk and start the game. The only thing that doesn't work is MS login ;-) (that was the main reason for me to try the build on arm64). As to networking, it's not exactly the same as the official nightly 0.11.5.712 install: I do get the marketplace stuff and also the skins chooser, in the nightly deb I get this weird error message. But if I press login, I first get the MS-offer to login, and if I chose to log in, nothing happens for a while, and then, I get a new MS Error-message: Drowned (in the official deb it was: Creeper). I have one suspicion/hope: in the other thread you asked me to run Do I need to install mcpelauncher-webview via make install? Are there other things, the use of the debs I created following the build instructions might have missed? |
Add the build folder to
No idea, these cpack targets are deprecated for 2 years for now. I don't use them, minecraft-linux/pkg using a different method of creating a deb e.g. one package per big repo. |
|
EDIT: Eh, I didn't see your answer before I typed this, sorry: @ChristopherHX - to answer my own (core) question: yes, that's it: once I copied mcpelauncher-webview to a location in the system-path, the MS login worked, and I could reach my Nitrado server without being asked to login again. Fabulous! My kids will really be happy! Compared to the Appimage I used to use in the previous Debian version, this does feel significantly snappier, I would say, snappier than MC Java on the RPI4. While I generally prefer MC Java, my kids want Bedrock to be able to play with friends using Switch or Xbox... so this is great now: faster than before, and working nicely. All in all this build went much smoother than I expected, I think you're not entirely just to yourself, this feels a lot more stable than in the past. I still remember the days when I'd be scared to to die each time I entered water ;-). Congratulations! If you want me to try out stuff or test something, just let me know. As the build system is working now, it shouldn't be much work. |
The xbox live problem in the deb's is more complex than I thought... For example if we start the AppImage it works, but if I start the AppRun file after running The exact binary is broken and working at the same time, only the AppImage/(flatpak) environment makes it to work on arm64. After a close look defining So this patch is also required for the deb https://github.com/minecraft-linux/appimage-builder/blob/f94fd0e6077fca26ca6e43d223f08e39b2ea6498/curlappimageca/curl/curl.h#L7-L8 ? The remaining mystery why did a non cross compiled deb work without issues? GitHub doesn't provide me native arm64 builders. However I could look up the distro specfic ca bundle path... A working bookworm appimage is here: https://github.com/minecraft-linux/appimage-builder/actions/runs/6883033738 Qtwayland works too, just the native wayland game client (like in flatpak) is missing to run without xwayland. |
|
This cmake line of curl causes the issue https://github.com/curl/curl/blob/17162dcb27be7bc9c033147836637f331eefd1f3/CMakeLists.txt#L1002C10-L1002C30 It has an cross compile detection, which get's triggered by my ci. AppImage has a fallback to hide the consequences.
|
So I just bought Minecraft for Android specifically to be able to play on my linux machine for now, while I wait to buy my android phone, and I get the error code "Creeper" every single time I try to log into my microsoft account in-game. Can anybody help me here? Is there a discord for faster responses?
MC Version: 1.18.12.01
Launcher Version: 0.3.4 (build 688)
The text was updated successfully, but these errors were encountered: