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

Downloading a replay from server sometimes doesn't coincide #28169

Closed
FeellsBadSkillz opened this issue May 13, 2024 · 1 comment
Closed

Downloading a replay from server sometimes doesn't coincide #28169

FeellsBadSkillz opened this issue May 13, 2024 · 1 comment

Comments

@FeellsBadSkillz
Copy link

Type

Game behaviour

Bug description

In some cases, downloading an osu!replay from the server and watch it, doesn't coincide from the original source.

In this case over half of the map wasn't counted, then after 8:52 timestamp of the video the replay coincide and works normally.

Screenshots or videos

Attaching youtube link because file was too big:

https://www.youtube.com/watch?v=H0W1n_PMbfI

Version

2024.412.1-lazer

Logs

PC logs:
compressed-logs.zip

Android logs:
osu!lazer log.zip

@bdach
Copy link
Collaborator

bdach commented May 14, 2024

Score in question is https://osu.ppy.sh/scores/2490286289

While there will be no direct confirmation since the score is so old there won't be client logs, the presentation of this is consistent with dropping and re-acquiring connection to spectator server midway through gameplay, which ties into #24609 (comment) / ppy/osu-server-spectator#193.

Probably gonna close as duplicate as we have this tracked elsewhere already.

@bdach bdach closed this as not planned Won't fix, can't repro, duplicate, stale May 14, 2024
bdach added a commit to bdach/osu that referenced this issue May 14, 2024
…score

Something I ran into when investigating
ppy#28169.

If there are two scores with the same online ID available in the
database - for instance, one being recorded locally, and one recorded by
spectator server, of one single play - the lookup code would use online
ID first to find the score and pick any first one that matched. This
could lead to the wrong replay being refetched and presented / exported.

(In the case of the aforementioned issue, I was confused as to whether
after restarting spectator server midway through a play and importing
the replay saved by spectator server after the restart, I was seeing a
complete replay with no dropped frames, even though there was nothing in
the code that prevented the frame drop. It turns out that I was getting
presented the locally recorded replay instead all along.)

Instead, jiggle the fallback preference to use hash first.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants