Osu: Ranked map with no hit objects

[Gabixel]

Describe the bug: I tried to re-download this map (even after reopening the game), but lazer keeps saying that the map _contains no hit objects_ (first screenshot).
You can see on the Info Wedge in map selection (second screenshot) that the map really contains nothing, but on stable it contains hit objects instead (third screenshot).
(Note that it's a ranked map)
For now, it seems the only map with this problem.

Screenshots or videos showing encountered issue:

osu!lazer version: 2019.611.0

Logs:
database.log
network.log

[smoogipoo]

Hmm something must've gone wrong during the import, since it's fine here. Does it work if you delete the beatmap set, restart osu!, and then re-import it?

[peppy]

Also if you can still reproduce, please provide the osz you imported.

[Gabixel]

Actually, I've downloaded the map from osu!direct. I've also tried doing a fresh download of the map from the website, but the map is still empty.

Here's a video with the examples from osu!direct and the website: https://streamable.com/t7a2l
(in the video, I used the Download without Video just for a faster download, the same problem happens with the normal one).

[peppy]

Could you please provide the .osz file you get from the website? Just to confirm it's not a localised beatmap mirror failing.

A filesize / checksum will do too.

[Gabixel]

Sure, here's a folder with the two types of .osz

[peppy]

I've tested and both cases work here. I'm guessing this is going to be a culture specific issue that we've somehow overlooked.

[peppy]

Can you please confirm that this is the case for every difficulty in that beatmap set? Have you reproduced this with any other beatmap since then?

[Gabixel]

Yes, the entire set, and by playing many other beatmaps I can still say that only this one has this issue for now.

[bdach]

This is going to be a long shot, but could you please provide a screenshot of the Details tab? I'd like to see if the metadata is complete or not, since I'm quietly suspecting that it might have to do something with the katakana characters in the title/artist name/tags. Not that it would get me any closer to an answer why that'd be the problem though...

So far my attempts at reproduction have yielded zip, I tested all 866 cultures that CultureInfo.GetCultures(CultureTypes.AllCultures) returned and decoding never dropped hitobjects.

[Gabixel]

I'll try to be more complete as possible:

• To see if there's any difference with original metadata between the two clients, here's a look with two screenshots:
  
  

• About the Details tab, here's a comparison between web and Lazer:
  
  

• One thing probably important that I noticed is that when I filter by length, Lazer knows its length (~2:47) because the beatmap is next to this one that is 2:45 (Actually, I don't know how really this filter works, but I thought it might be useful/important to notice):
  

[bdach]

By the Details tab I meant the tab just under the wedge, not the overlay:

Sorry if I was unclear. As far as I can tell there actually is a difference between it and the overlay, as the overlay actually starts with an API hit while the tab reads local data.

The length being nonzero is sort of relevant in that the length calculation actually checks for hitobject presence:

https://github.com/ppy/osu/blob/fd3e2375bb166624783f8f3676e70493868ab565/osu.Game/Beatmaps/BeatmapManager.cs#L318-L319

So it would appear that hitobjects were read at least once before and now can't be.

[Gabixel]

Oh, I thought that by "tab" you meant "overlay". Anyway, I can see that there's a small but big difference with values in the Details tab, because if it reads local data (from what you said), somehow the map still has values like Star Rating etc. (also, some tags have the first letter uppercase, but on the web/details tab they haven't that, and the last tag is missing):

[bdach]

Thanks for the screenshot, unfortunately not much to see there either. The data matches the .osu file contents, no discrepancies as far as I can see.

Not really sure how to proceed further here - maybe by inspecting what's actually ended up in %AppData%/osu/files?

[peppy]

At this point the user needs to debug this issue using a debugger. It's pointless to guess blindly.

[bdach]

Reliable reproduction steps:

1. Navigate to the filestore (%AppData%/osu/files/), find a victim beatmap to corrupt (should work with any - the file names are obfuscated but you can locate one by searching file contents for the header and/or song name)
2. Corrupt the file in any way (delete the entire [HitObjects] section, add an unrecognized line)
3. Open lazer, navigate to corrupted beatmap. It should spew errors either on selection or on play start, depending on how the file was corrupted.
4. Delete beatmap.
5. Reimport beatmap, either from archive or from osu!direct.
6. Beatmap should remain corrupted.

Root cause (diagnosed by @peppy) is FileStore not copying files to storage if they already exist. The hash is stored in the database/filename, but it's only stored the first time and not refreshed, so when the comparison happens upon reimport, the DB/filename hash matches the hash of the imported file but does not match the hash of the actual file on disk, so the corrupted file is not overwritten until the beatmap is fully purged.
https://github.com/ppy/osu/blob/d2035c49feabbc79d1402b999f1bc7ba2e39c5c8/osu.Game/IO/FileStore.cs#L46-L61
The scenario above is fairly artificial, shouldn't happen very often (if ever) and probably isn't what happened in the bug reported; most likely it got corrupted when the beatmap was being copied to the store from the archive. Either way, more hash checks are probably needed.

I could take a shot at this but not in the immediate future, so posting this in case anyone wants to take this up.

@Gabixel, thanks for the help diagnosing this!

[Gabixel]

Reopening because it probably needs a fix.