-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing beatmaps and skins after update #31574
Comments
Having the same issue here on Arch Linux with the AppImage. Another thing I noticed is that my "files" folder in lazer is still the same size as it was pre-update meaning the files for these skins and maps are still there but I guess aren't being read? I tried seeing if maybe downgrading and running the update before this (which worked for me before) would read those files and still have my maps and skins but still nothing. |
Dunno, maybe a realm side error? Can you try copying the backup database back to |
I renamed the client.v23.backup.realm to client.realm and backed up the one created after the update and now my maps, skins, etc are all back. I'm just wondering now if this is an isolated issue or if it's somehow an issue with the newest release maybe specific to the AppImage? |
Same as with @cjwrecks, renamed backup into |
Had same issue. |
On LTS Kubuntu 24.04, same issue. Renaming to |
also happens with 2025.118.2-lazer on Fedora 40, renaming the backup seems to resolve the issue |
See realm/realm-swift#8731, realm/realm-swift#8703, I don't know what the solution here is and I'd say it's very unlikely to get a fix from realm's end. That said, it does look to be limited in scope (and only happened to linux users). Does anyone happen to have a copy of their database which can trigger this issue 100%? |
If you are asking for the realm.client file that was causing the bug I did end up backing it up. [https://drive.google.com/file/d/1xGkmxdZxyYYFwGahxcq3tIp9ge7M5cJp/view?usp=sharing] |
I believe everyone has a backup as realm created at least two identical backups for me. One named |
Putting the original 'bad' db back into the game doesn't recreate the issue. |
@nirinchev excuse me for pulling you in here, but we've had at least five users have realm report an issue on realm version migration ( On a second attempt to migrate using a backed-up copy of the realm database (we make automatic backups in the case of a startup failure), the user has no issue. I'm not sure how this can happen. I found (realm/realm-swift#8731, realm/realm-swift#8703) which both look similar, but this looks like a relative high effort investigation/fix which I presume the realm/mongo team won't have bandwidth to fix. If you have any quick hints or recommendations that would be appreciated, else I guess we just have affected users restore their database and carry on with life. |
Hey, yeah, this is a bit deep in the weeds. I won't be able to spend a whole lot of time on this, but one thing that could be interesting if we can get a consistent repro case is to enable debug logging and see what's the sequence of events. Additionally, it's not clear from the bug report if the issue persists across app/computer restarts. Skimming through the code, it appears to be caused by a discrepancy between the history schema version on disk and the history schema version expected when opening the Realm file for a second time in the same process. This is because if that was the first time, a transparent migration would kick in and the problem would go away. My gut feeling is that this is happening as part of a migration (or less likely, compaction), which can also be a file format migration - the fact that users report finding .v23.realm backups implies that their databases got automatically updated from v23 to v24. However, for this to have happened, they must have upgraded from a version prior to 12.0.0, since 12.0.0 already uses file format v24 and history schema version 1 - can we confirm that the affected users were indeed running Realm 12.0.0 prior to upgrading to the broken version? |
Your suspicion is correct – in our recent release we upgraded from realm The weird part is that this only happened to linux users. Our main audience is windows and we haven't had one report of failure there (luckily). |
Unfortunately, I'm not super well versed in C++, so can't really suggest an actual fix, but if you're down for it, this should probably be workaroundable. Since it's an exception and not a crash, you could catch it and then inform the users they need to restart the game. I'm like 70% certain a restart should not re-trigger the exception, though I'm not sure if the data in the migrated file is somehow negatively affected (the report doesn't appear to mention it). Alternatively, you could look for the automatic backup file, restore it, then try reopening. Not a huge fan of sweeping it under the rug like that, but assuming it affects only a small portion of your users and has a non-destructive workaround, I think that'd be a more realistic solution than tracking the source and fixing it in Realm Core. The good news is that the workaround should be mostly transparent to users and it's a one-off file format migration, so once everyone updates, it should stop happening for good. |
Thanks for the answers. I think we can handle the exception based on the message and do something about it. Or just continue to help the small group of users that are hitting this. |
I made a one liner for the terminal, that should fix it.
|
Type
Game behaviour
Bug description
After new update I have no maps nor skins in-game, however all my settings such as gameplay cursor scale are still being used correctly except binds and scroll speed. All files are still intact in the folder.
I have tried redownloading AppImage file and manually select the folder but still has this issue.
System:
Arch Linux
Using official AppImage to launch the game. Never used custom installation folder.
Screenshots or videos
In-game:
Inside one of files subfolder
find ./ | fzf
returns 109k files inside /osu/files folder
Version
2025.118.0
Logs
compressed-logs.zip
The text was updated successfully, but these errors were encountered: