Skip to content
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

Open
Tyfaspo opened this issue Jan 19, 2025 · 17 comments
Open

Missing beatmaps and skins after update #31574

Tyfaspo opened this issue Jan 19, 2025 · 17 comments
Assignees
Labels
platform/linux realm deals with local realm database

Comments

@Tyfaspo
Copy link

Tyfaspo commented Jan 19, 2025

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:

Image

Image

Inside one of files subfolder
Image

find ./ | fzf

returns 109k files inside /osu/files folder Image

Version

2025.118.0

Logs

compressed-logs.zip

@cjwrecks
Copy link

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.

@peppy
Copy link
Member

peppy commented Jan 19, 2025

2025-01-19 15:47:45 [error]: Realm startup failed with unrecoverable error; starting with a fresh database. A backup of your database has been made.
2025-01-19 15:47:45 [error]: Realms.Exceptions.RealmFileAccessErrorException: History schema version not consistent
2025-01-19 15:47:45 [error]: at Realms.NativeException.ThrowIfNecessary()
2025-01-19 15:47:45 [error]: at Realms.SharedRealmHandle.Open(Configuration configuration)
2025-01-19 15:47:45 [error]: at Realms.RealmConfiguration.CreateHandle(Configuration& configuration)
2025-01-19 15:47:45 [error]: at Realms.RealmConfigurationBase.CreateRealm()
2025-01-19 15:47:45 [error]: at Realms.Realm.GetInstance(RealmConfigurationBase config)
2025-01-19 15:47:45 [error]: at osu.Game.Database.RealmAccess.getRealmInstance()
2025-01-19 15:47:45 [error]: at osu.Game.Database.RealmAccess.prepareFirstRealmAccess()
2025-01-19 15:47:45 [verbose]: Creating full realm database backup at client_1737301665_corrupt.realm

Dunno, maybe a realm side error?

Can you try copying the backup database back to client.realm and see if it does the same thing a second time?

@peppy peppy self-assigned this Jan 19, 2025
@cjwrecks
Copy link

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?

@Tyfaspo
Copy link
Author

Tyfaspo commented Jan 19, 2025

Same as with @cjwrecks, renamed backup into cleint.realm and maps, skins, etc are back. Thanks for that solution. But why that happened in the first place?

@Tabisch
Copy link

Tabisch commented Jan 19, 2025

Had same issue.
Restoring client.realm worked.

@SHOESKE-H
Copy link

On LTS Kubuntu 24.04, same issue. Renaming to client.realm solved this

@ticotaco72
Copy link
Contributor

also happens with 2025.118.2-lazer on Fedora 40, renaming the backup seems to resolve the issue

@peppy
Copy link
Member

peppy commented Jan 20, 2025

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%?

@cjwrecks
Copy link

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]

@ticotaco72
Copy link
Contributor

I believe everyone has a backup as realm created at least two identical backups for me. One named client.v23.backup.realm and client_1737326229_corrupt.realm. After the operation with renaming the db and getting beatmaps back, client.v23.backup.realm file was recreated with the same content as before (MD5 match between all three backups).

@ticotaco72
Copy link
Contributor

Putting the original 'bad' db back into the game doesn't recreate the issue.

@peppy peppy added the realm deals with local realm database label Jan 21, 2025
@peppy
Copy link
Member

peppy commented Jan 21, 2025

@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 (Realms.Exceptions.RealmFileAccessErrorException: History schema version not consistent). All users have been on linux. This follows a recent package bump from 12.0.0 to 20.1.0.

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.

@nirinchev
Copy link

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?

@peppy
Copy link
Member

peppy commented Jan 23, 2025

Your suspicion is correct – in our recent release we upgraded from realm 11.5.0 to 20.1.0 (we were held back pending the android fixes which explains the larger jump in versions). I checked some of the users logs in this thread and they all transitioned between these two versions.

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).

@nirinchev
Copy link

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.

@peppy
Copy link
Member

peppy commented Jan 23, 2025

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.

@Tabisch
Copy link

Tabisch commented Jan 23, 2025

I made a one liner for the terminal, that should fix it.

mv ~/.local/share/osu/client.realm ~/.local/share/osu/client.realm.backup && cp ~/.local/share/osu/client.v23.backup.realm ~/.local/share/osu/client.realm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
platform/linux realm deals with local realm database
Projects
None yet
Development

No branches or pull requests

8 participants