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

Buggy behaviour when closing beatmap browser as a preview song is loading #27883

Closed
bytenekos opened this issue Apr 15, 2024 · 3 comments · Fixed by #27898
Closed

Buggy behaviour when closing beatmap browser as a preview song is loading #27883

bytenekos opened this issue Apr 15, 2024 · 3 comments · Fixed by #27898

Comments

@bytenekos
Copy link

bytenekos commented Apr 15, 2024

Type

Game behaviour

Bug description

When you close the beatmap browser as a song preview is loading, it causes the song to either play as soon as you bring the beatmap browser back up, or it starts playing with the beatmap browser closed regardless

Happens when in the middle of playing a beatmap or when loading a song too

Screenshots or videos

Osu.2024.04.15.-.22.13.26.54.mp4
Osu.2024.04.15.-.22.19.10.55.mp4

Song playing when in the middle of a beatmap ^^

Osu.2024.04.15.-.22.39.30.56.mp4

Song playing when launching a beatmap ^^

Version

2024.412.1-lazer

Logs

compressed-logs.zip

@bytenekos
Copy link
Author

Higher chance of this possibly happening if someone's internet is slow or some networking slowdown happens (came about this bug because the preview of a song took a while to load, then closed the beatmap browser, then reopened it and it started playing the preview song)

@Walavouchey
Copy link
Member

Walavouchey commented Apr 15, 2024

@ppy/team-client

can easily repro all scenarios within a few tries. seemingly doesn't happen on other overlays where audio previews are present (beatmap info, profile page)

@bdach
Copy link
Collaborator

bdach commented Apr 16, 2024

I can make it happen from profile page. It's not specific to listing. This is just async load things.

bdach added a commit to bdach/osu that referenced this issue Apr 16, 2024
RFC. Closes ppy#27883.

The idea here is that `PopOut()` is called _when the hide is requested_,
so once an overlay trigger would hide, the overlay would
`StopAnyPlaying()`, but because of async load things, the actual track
would start playing after that but before the overlay has fully hidden.
(That last part is significant because after the overlay has fully
hidden, schedules save the day.)

Due to the loose coupling between `PreviewTrackManager` and
`IPreviewTrackOwner` there's really no easy way to handle this locally
to the usages of the preview tracks. Heck, `PreviewTrackManager` doesn't
really know which preview track owner is to be considered _present_ at
any time, it just kinda works on vibes based on DI until the owner tells
all of its preview tracks to stop.

This solution causes the preview tracks to stop a little bit later but
maybe that's fine? Just trying to not overthink the issue is all.

No tests because this is going to suck to test automatically while it is
pretty easy to test manually (got it in a few tries on master).

The issue also mentions that the track can sometimes resume playing
after the overlay is pulled up again, but I don't see that as a problem
necessarily, and even if it was, it's not going to be that easy to
address due to the aforementioned loose coupling - to fix that, play
buttons would have to know who is the current preview track owner and
cancel schedules upon determining that their preview track owner has
gone away.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants