-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Fix submission & rank date backpopulation failing every launch for some users #34752
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
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Addresses ppy#34705, I suppose. The cagey tone of that statement is because this change merely papers over the issue. The issue in question for the user that reported this is that they have a bunch of very old beatmaps, whose md5 hashes do not match the online hashes, that need updating. The submission/rank date population was running every single time for these, and failing every time, because there is really not much useful that the lookup *can* do. Because mappers have made `OnlineID` essentially useless for determining the provenance of a beatmap due to reusing them to "fix" beatmap submission failures, online IDs have been explicitly disallowed from use in any sort of beatmap lookup flow. The only things that are allowed to be used are: md5 of the beatmap, and filename as a fallback for very old beatmaps / beatmap packs. If the user has local beatmaps with md5 not matching online, chances are that any metadata lookups are likely to fail or return bogus data. At that point my personal feeling is that backpopulation flows should leave such beatmaps well alone and the user should just go update the beatmap themselves. I am aware that updating 124 individual beatmap sets would - in the current state of things - would probably be a ridiculously onerous thing to do, and that people have been asking multiple times for a facility to update all local beatmaps at once, but that discussion is out of scope at this stage.
peppy
approved these changes
Aug 21, 2025
This was referenced Sep 4, 2025
This was referenced Oct 2, 2025
This was referenced Oct 9, 2025
This was referenced Dec 9, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area:beatmap change tracking
sync of local-online metadata and status
area:database
Deals with local realm database
size/S
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addresses #34705, I suppose.
The cagey tone of that statement is because this change merely papers over the issue. The issue in question for the user that reported this is that they have a bunch of very old beatmaps, whose md5 hashes do not match the online hashes, that need updating. The submission/rank date population was running every single time for these, and failing every time, because there is really not much useful that the lookup can do.
Because mappers have made
OnlineIDessentially useless for determining the provenance of a beatmap due to reusing them to "fix" beatmap submission failures, online IDs have been explicitly disallowed from use in any sort of beatmap lookup flow. The only things that are allowed to be used are: md5 of the beatmap, and filename as a fallback for very old beatmaps / beatmap packs.If the user has local beatmaps with md5 not matching online, chances are that any metadata lookups are likely to fail or return bogus data. At that point my personal feeling is that backpopulation flows should leave such beatmaps well alone and the user should just go update the beatmap themselves.
I am aware that updating 124 individual beatmap sets would - in the current state of things - would probably be a ridiculously onerous thing to do, and that people have been asking multiple times for a facility to update all local beatmaps at once, but that discussion is out of scope at this stage.