Music sometimes mutes upon quick retrying with network problems

[Adamersky]

Type

Game behaviour

Bug description

I was playing osu mania and when I tried to quick retry (I've got hold-to-confirm activation time set to 0ms) the map started without the music, only the hitsounds were working. After a few seconds of playing, music reappeard.

It happened to me multiple times on multiple maps and while using multiple skins (including argon pro). When I left the map while the music was muted, it was still gone even in the menu. Retrying didn't help, I just needed to wait a couple of seconds either in the menu or while playing a map for music to get unmuted.

The only mod i had on was 4K.

I don't know if this issue appears in other game modes, but it never happened to me before neither in standard nor mania.

(the logs aren't from the session that I'm describing, but I triggered this bug again in a new one)

Screenshots or videos

https://user-images.githubusercontent.com/122567364/212171906-e8951a7e-eb59-4531-a8c8-613b3d8e65e9.mp4

Version

2022.1228.0-lazer

Logs

osu!auth.log runtime.log session.log update_success.log

[bdach]

Sounds similar to #20908 but no mods are apparently involved here?

[Adamersky]

I forgot to add that when music is gone and you retry on a map, that has a skippable section at the beginnig and you press skip, the map timer just freezes and the map won't start even after retrying again and not pressing the skip button.

[ShizuVoice]

May I ask if you can try connecting your system to a fast internet? Based on the video you sent, you have problems with the scoreboard not loading any profile pictures which matches the criteria of triggering the bug I've done few days ago. I also commented the result on #20908 about it.

[Adamersky]

Yes, normally this kind of thing doesn't happen to me, but at the time I recorded and reported this bug I was downloading something from the internet. Usually when I download something I play osu stable since unlike other games on my pc it doesn't require good internet connection but it looks like lazer is different in that matter.

[cdwcgt]

I just encountered a similar problem compressed-logs.zip don't know how to reproduce it stably

https://github.com/user-attachments/assets/c07a4916-53bd-49a1-9412-fb49c98ca6e0

After another retry, it returns to normal

Based on what I discussed above, I realized that I was also having an unstable network when I encountered this problem (unable to load the leaderboard avatars)

[its5Q]

I've been having this issue consistently for a few days, and I'm from Russia so the internet censorship is affecting some online functionality, thus this bug happens very frequently between retries, although it looks like plays still submit and leaderboards load.

[xiaolanmax]

I also encountered this issue while playing in standard mode, and it happens every time I quickly restart, but not when I retry in the ESC menu

I'm using the Tachyon update, and I don't know how to export the logs (sad)

[bdach]

I'm using the Tachyon update, and I don't know how to export the logs (sad)

there's a button in settings to do it

[MAHBOD-85]

the same happenes to me all the time on linux using JACK, sometimes it takes its sweet time and doesn't resume playing music until 2 minutes have passed!!!

[cdwcgt]

also live in 2025.1205.0 (fbac5db964def0b076161f3fe35dc1949ec5b0eb)

and out of curiosity, I discovered that this problem can be stably reproduced (at least for me) by disconnecting the network connection and retrying.

1. switch to skin which will load online resource (like avatar in leaderboard, PlayerAvatar, PlayerTeamFlag)
2. start a map with autoplay or replay
3. (quick?) restart before online resource loaded
4. music and samples will be muted until online resources have finished loading

[peppy]

Root cause is HoldToConfirmContainer not getting disposed on time:

https://github.com/ppy/osu/blob/0ebc90462d2c06884e9004f670ab2800837e0865/osu.Game/Overlays/HoldToConfirmOverlay.cs#L64-L69

We can easily fix this locally, but it's still leaving disposal in a weird unknown state (something is pending on network operations when it should be exiting early). I feel like going down that rabbit hole is going to end in "sync web requests unaware of cancellation".

Repro:

diff --git a/osu.Game/Users/Drawables/DrawableAvatar.cs b/osu.Game/Users/Drawables/DrawableAvatar.cs
index bd09b95164..07db77219b 100644
--- a/osu.Game/Users/Drawables/DrawableAvatar.cs
+++ b/osu.Game/Users/Drawables/DrawableAvatar.cs
@@ -3,6 +3,7 @@
 
 #nullable disable
 
+using System.Threading;
 using osu.Framework.Allocation;
 using osu.Framework.Graphics;
 using osu.Framework.Graphics.Sprites;
@@ -33,6 +34,8 @@ public DrawableAvatar(IUser user = null)
         [BackgroundDependencyLoader]
         private void load(LargeTextureStore textures)
         {
+            Thread.Sleep(1000);
+
             if (user != null && user.OnlineID > 1)
                 // TODO: The fallback here should not need to exist. Users should be looked up and populated via UserLookupCache or otherwise
                 // in remaining cases where this is required (chat tabs, local leaderboard), at which point this should be removed.

• quick retry

[bdach]

but it's still leaving disposal in a weird unknown state

I'm not sure what you mean by this.

It reads to me like we need to .RemoveAndDisposeImmediately() or do some other level of unbind on gameplay completion and that's that.

[peppy]

That's fine as a local fix as I hinted at... if we're okay with the rest of player in a state where it's in the background loading avatars for potentially minutes, and potentially triggering other issues as a result.

[peppy]

The deeper story is that the delay in disposal is roughly equal to the maximum timeout of all actively loading drawables already in SCHEDULER_LONG_LOAD. In this scenario, avatars are the main culprit, and the timeout is 10 seconds plus one extra retry (see WebRequest.AllowRetryOnTimeout).

It does not seem that we're doing anything wrong in terms of cancelling as soon as we can – no new web requests are started after the disposal is triggered.

But it does mean that old instances of Player can exist for up to 20 seconds in worse case scenario, compounding each time a retry is triggered. Not sure how to feel about that.

Addressing this in a better way either requires async BDL support (we've tried and failed this multiple times) or potentially some better centralised network failure management (something like #35752 but for all web requests, not just API?).

The proposed local fix seems like best effort for now.