Sounds loop/restart when exiting screens

STILL OCCURRING in 1.7! Come'on Mojang, don't release partially made games like EA or Rockstar. We expect better. Just saying.

I can still replicate in 1.7.1 by breaking/placing a block or open/close a chest (MC-36603 and MC-36608).

This is happening to me when placing blocks too, if I place dirt, and go into my inventory immediately to grab more, it plays again. It doesn't happen all the time.

I just want to confirm... this bug ticket is in existence not JUST for the jukebox music but also for the normal background music too right?

Windows 7, Java 1.7.0_45, Minecraft 1.7.1
I can confirm this with opening/closing chests, apparently closing it quickly triggers the opening sound.

Issue still occurs in 1.7.2

Confirmed. Issue persists in 1.7.2. Background music looping appears to be fixed and is no longer an issue, but duplicate chest sounds still persist.

Yup. I also made a video showing two Minecraft music tracks playing at the same time. I was going to post a bug report but obviously I was a good person and went and searched to see if someone else had already posted the bug. 😛

http://www.youtube.com/watch?v=io68pyzP6s8

@Zach: The background music looping is still there in 1.7.2. I just had it happen.

Still present in the latest snapshots, currently using 13w47e.

This bug kills my ears. Actually, a different one that is similar. It's made the game unplayable.

Pretty sure this relates to a bug I'm having where bringing up a menu (like your inventory) while a sound is playing causes the sound to play again when the menu is closed.

@Djome Kinoshita
I've noticed that too; it is easies to notice when you, say, place a block then immediately open a command block. I'm pretty sure it is only single player.

Still occurs in 13w49a.

EDIT: And in 1.7.3 pre-release.

Affects 1.7.4. Unpausing the game replays the last raised sound event. It's very annoying.

It appears to be related to timing — if I pause the game just as the sound is ending, I can reliably reproduce.

I also have another bug where, if I change the time using /time set, it loops through songs for if I hadn't used /time set to change the time, and also through a new ambient music loop created by a slightly off day-night cycle. It's hard to explain in words.

@@unknown:
Try a screen recorder. (I use windows media encoder: http://www.microsoft.com/en-us/download/details.aspx?id=17792)
Or maybe the twitch streaming thing. Or something. Not quite sure what.

I have something for this bug.
You can make it play twice (first time for a few seconds, then second time fully)
If you place the music disc in and at the same time pause the game, it plays the disc for a little while.
Once you unpause, it starts again, as if you just placed it in.
Also, if you eject the disc then pause the game at the same time, it doesn't play, but once you unpause, it plays the disc as if it was still in the jukebox.
These will not yield loops, but are a quicker way of seeing these bugs (also, you can play two or more music discs at a time with the eject and pause one).
They also don't need to be ending.

Confirming in latest snapshots (14w02a) 14w02b.

NEW for SMP:
This only works if there are 2 or more people in the world. One person must have a music disc, while the other has nothing. Simply follow these steps:
1. Have the second person hold down their right-click on the jukebox
2. Have the first person place the music disc in the jukebox
3. The music disc will pop out immediately
4a. The music will play fully with no music disc inside
OR
4b. The music will play, but finish early with no disc inside

I'd like to add this bug affects mostly every event that produces sounds. Examples:

• Run, the footsteps sound is played, stop, the sound is still in execution for a tic further. (this one confuses me a lot, it seems a creeper is approaching me but in fact I'm still hearing my own footsteps even if I have just stopped);

• Open a chest, the chest opening sound is played, just when the chest is fully open hit ESC, resume the game, the sound is still in execution for a tic further;

• Skeleton shoots an arrow and it hits the floor, the arrow hit sound is played, you can hear the sound is played twice and one of them a tic ahead;

• and so on...

It seems there's a desynch between the event and the sound or the latter is being executed twice. The sound was supposed to be played only within the duration of the event (run, open, hit) but it's noticeable the sound is being played a tic further.

Confirmed in 14w10c

Please for the love of god update the description. I believe why this bug has never been fixed is because of the instructions. You can't duplicate this bug with those instructions so please update the description!!!!!!!!

I was really hoping this would have gotten fixed in 1.7 still, because I will be playing 1.7.x for a long time to come because of mods.
I just tried it in the 1.7.10-pre2, and it is still present :/
The problem based on in-game experiences is, that sounds play an extra time when the player opens his inventory while a sound is still playing, and then closes the inventory again pretty quickly. This often happens when browsing chests and opening and closing the inventory/chests a lot, and it gets really confusing and annoying quickly.
I recorded a short video demonstration in the just released 1.7.10-pre2: http://youtu.be/7f6X4cuPRGA

Also occurs in 14w25b: https://www.youtube.com/watch?v=hEXWj0QeY9s

Issue still persists in 14w30c.

Issue much more noticeable in latest snapshot's remote multiplayer.

14w33a:
Changing gamemodes will stop background music, and at one point there were 2 background songs playing at once (not sure how to reproduce).

Also part of this issue: Opening the Command-Block GUI freezes the game, but not the music. When exiting, the music often repeats

I have also been able to confirm this with the game chat.

confirm. everytime like i splash a potion on the ground, and then press esc, and resume and press esc again the sound resume and it is a little bit weird

Confirmed for 1.8-pre1.

Confirmed for 1.8-pre2.

Confirmed for 1.8-pre3.

Confirmed for 1.8.

At 1.8:

The same goes for every sound, and opening and closing the inventory. Breaking grass, footsteps, getting objetcs, increasing exp, etc. You break something, press E before the sound stop, and then press E again, and you hear the sound.

I can understand that it happens presing 'Esc', because of some kind of sound bug or problem pausing and replaying a sound.

But opening the inventory? Why?

The amazing and lovely misteries of Minecraft.

Why do so many people keep posting very similar comments? There is no need to keep commenting that the record sounds can be replayed, or opening and closing a chest or the inventory repeats sounds.

A mod should remove some of the older/unimportant affected versions so that the list isn't quite so long 😉

No, it's relevant for basic record keeping. You don't need the list to be easy to read. Checking the latest affected version is easy to do.
By the way Aaron Rhodes, comments like that never help either...

@@unknown: Exactly (both)

It is not only the inventory screen, it is the chat window as well.

@Nicholas Braden
Can we just clear this up here? This works with EVERY SINGLE GUI and EVERY SINGLE sound.

Confirmed for 1.8.1-pre1.

Confirmed for 1.8.2-pre1.

Also affects any sound played in a certain time limit before opening inventory. Even affect normal music game, if your volume is set to 0%, the music that was playing continues to play but at a lower volume, if put back the music in a 100% a music frame it's listen very strong and the initial volume is returned.

Confirmed for 1.8.2-pre2, pre3 and pre4.

Confirmed for 1.8.2-pre6 so that means it is in pre5 aswell. https://www.youtube.com/watch?v=iTYaiIlSo0E

Could the reporter or a mod edit the description, because this bug affects ALL sounds (afaik). It is not just the jukebox.
For example block breaking and placing and walking sounds and chest sounds loop when you quickly open and close your inventory after the sound started playing. It gets really confusing at times.

MC-80063 confirms 1.8.4

Confirmed for 1.8.5 and 1.8.6

I wonder if it could occur before the sound file is not actually over, but is silent to make it sound better (less abrupt). If there are a few frames where the sound hasn't ended yet, and the chest or your inventory is opened, it may trigger the sound again. Just a thought, and I don't mean to be annoying. I mean to be helpful.

Confirmed for 1.8.7

Alright, let me give the cause of this programmatically. It's in the displayGuiScreen method of net.minecraft.client.Minecraft (these are mcp910 mappings). Here's the code at the end of that method:

net.minecraft.client.Minecraft at the end of displayGuiScreen(GuiScreen guiScreenIn)

if (guiScreenIn != null) {
    this.setIngameNotInFocus();
    ScaledResolution var2 = new ScaledResolution(this,
            this.displayWidth, this.displayHeight);
    int var3 = var2.getScaledWidth();
    int var4 = var2.getScaledHeight();
    guiScreenIn.setWorldAndResolution(this, var3, var4);
    this.skipRenderWorld = false;
} else {
    this.mcSoundHandler.resumeSounds();
    this.setIngameFocus();
}

Now, the second to last line is what matters here:

this.mcSoundHandler.resumeSounds();

Now, when the ingame pause menu is opened (and the game is in singleplayer and not open to lan), it pauses all current sounds, but no other GUIs do so. But it resumes sounds regardless of whether it paused them when a GUI is closed.

Now, that wouldn't be that bad, except that resumeSounds doesn't actually resume sounds.

The SoundHandler (net.minecraft.client.audio.SoundHandler)'s pauseSounds and resumeSounds just call the SoundManager (net.minecraft.client.audio.SoundManager)'s pauseAllSounds and resumeAllSounds methods respectively. But...

net.minecraft.client.audio.SoundManager

/**
 * Pauses all currently playing sounds
 */
public void pauseAllSounds() {
    Iterator var1 = this.playingSounds.keySet().iterator();

    while (var1.hasNext()) {
        String var2 = (String) var1.next();
        logger.debug(LOG_MARKER, "Pausing channel {}",
                new Object[] { var2 });
        this.sndSystem.pause(var2);
    }
}

/**
 * Resumes playing all currently playing sounds (after pauseAllSounds)
 */
public void resumeAllSounds() {
    Iterator var1 = this.playingSounds.keySet().iterator();

    while (var1.hasNext()) {
        String var2 = (String) var1.next();
        logger.debug(LOG_MARKER, "Resuming channel {}",
                new Object[] { var2 });
        this.sndSystem.play(var2);
    }
}

The code in resumeAllSounds is perfectly fine if it paused them in the first place. But if it isn't, this appears to allow it to play multiple times, if the timing is good. Otherwise, it'll just resume an already-playing sound (which is, more or less, fine, since it won't start it from the beginning again). You probably could get better info by enabling debug-level logging (which there is for the SoundManager, but I couldn't get it enabled).

I think the required timing is that you need to unpause it before updateAllSounds removes it.

The simple fix that isn't very good is to just remove the call to resumeAllSounds, which will mess up the pause menu resuming sounds. Alternatively, more thorough logic could be used to see if sounds were already paused, but I feel like this would be prone to failure. But the best solution is just to track what sounds were paused, and only resume those.

Something like this:

private List<String> pausedSounds = Lists.newArrayList();

/**
 * Pauses all currently playing sounds
 */
public void pauseAllSounds() {
    Iterator var1 = this.playingSounds.keySet().iterator();

    while (var1.hasNext()) {
        String var2 = (String) var1.next();
        logger.debug(LOG_MARKER, "Pausing channel {}",
                new Object[] { var2 });
        pausedSounds.add(var2);
        this.sndSystem.pause(var2);
    }
}

/**
 * Resumes playing all currently playing sounds (after pauseAllSounds)
 */
public void resumeAllSounds() {
    Iterator var1 = this.pausedSounds.iterator();

    while (var1.hasNext()) {
        String var2 = (String) var1.next();
        
        logger.debug(LOG_MARKER, "Resuming channel {}",
                new Object[] { var2 });
        this.sndSystem.play(var2);
        
        pausedSounds.clear();
    }
}

Or more humanly-readable (this is a guess on what it should look like if it weren't decompiled):

private List<String> pausedSounds = Lists.newArrayList();

/**
 * Pauses all currently playing sounds
 */
public void pauseAllSounds() {
    for (String channel : playingSounds.keySet()) {
        logger.debug(LOG_MARKER, "Pausing channel {}",
                new Object[] { channel });
        pausedSounds.add(channel);
        this.sndSystem.pause(channel);
    }
}

/**
 * Resumes playing all currently playing sounds (after pauseAllSounds)
 */
public void resumeAllSounds() {
    for (String channel : pausedSounds) {
        logger.debug(LOG_MARKER, "Resuming channel {}",
                new Object[] { channel });
        this.sndSystem.play(channel);
    }
    
    pausedSounds.clear();
}

Hopefully this is helpful.

Also, note that this doesn't fix the jukebox being broken when the disk is inserted glitch, but it does fix the repeated block sounds when closing GUIs glitch.

EDIT: It also would make sense to have the sound pausing/resuming logic moved from Minecraft.java to the ingame pause screen GUI (IE, pausing it on open if the conditions are right and resuming it when the GUI is closed). That, combined with the pausedSounds list, would make this code much clearer. (It still won't fix the left+right click on jukebox glitches)

EDIT 2: Here's the code I referenced with the obfuscated mappings (and actual line numbers).

net.minecraft.client.Minecraft.displayGuiScreen(GuiScreen) = bsu.a(bxf), quoting lines 804 to 814.

this.mcSoundHandler.resumeSounds(); is this.aD.e() (line 812). aD is a czh.

SoundHandler.pauseSounds() is czh.a(), line 182. SoundHandler.resumeSounds() is czh.e(), line 199. Both call the corresponding methods on the f field, which is the SoundManager of type cza.

SoundManager.pauseAllSounds() is cza.e() (lines 369-372), and SoundManager.resumeAllSounds() is cza.f() (lines 376-378).

The previous fix with these mappings and line numbers:

cza, lines 369 - 378 (ish)

public void e()
    {
        for (String str : this.h.keySet()) {
            b.debug(a, "Pausing channel {}", new Object[] { str });
            this.e.pause(str);
        }
    
        pausedSounds.addAll(this.h.keySet());
    }
    
    public void f()
    {
        for (String str : pausedSounds) {
            b.debug(a, "Resuming channel {}", new Object[] { str });
            this.e.play(str);
        }
    
        pausedSounds.clear();
    }

Is this helpful?

Your solution seems very clear and easy to deploy. The jukebox issue is another problem, less important than this one (for me).

Sorry for the duplicate thread. i could not find any correct matches using the keyword "Sound"

Would the sounds of mobs/events in general restarting/stacking-and-being-louder when exiting out of the inventory, pause menu, and command block menus count as the same glitch? I'd rather ask here than make a duplicate and waste moderator's time. What I mean is that if a lot of sounds are playing, and you go into any of those menus, then exit out, they all stack on each other and can be pretty loud sometimes, and can restart long sounds like the cave warning and such.

@Wyatt Boyle

Yes.

Reproduced in 1.8.8 (both the jukebox portion and repeating audio portion).

EDIT: 1.8.8 mappings for this comment:

net.minecraft.client.Minecraft.displayGuiScreen(GuiScreen) = bsu.a(axu), quoting lines 814 to 824.

this.mcSoundHandler.resumeSounds(); is this.aH.e() (line 822). aH is a bpz.

SoundHandler.pauseSounds() is bpz.a(), line 182. SoundHandler.resumeSounds() is bpz.e(), line 199. Both call the corresponding methods on the f field, which is the SoundManager of type bpx.

SoundManager.pauseAllSounds() is bpx.e() (lines 369-372), and SoundManager.resumeAllSounds() is bpx.f() (lines 376-378).

Both portions reproduced in 15w31a.

15w31a mappings for this comment:

net.minecraft.client.Minecraft.displayGuiScreen(GuiScreen) = axc.a(azu), quoting lines 801 to 811.

this.mcSoundHandler.resumeSounds(); is this.aG.e() (line 809). aH is a bsr.

SoundHandler.pauseSounds() is bsr.a(), line 182. SoundHandler.resumeSounds() is bsr.e(), line 199. Both call the corresponding methods on the f field, which is the SoundManager of type bsp.

SoundManager.pauseAllSounds() is bsp.e() (lines 369-372), and SoundManager.resumeAllSounds() is bsp.f() (lines 376-378).

Confirmed for 15w31b.

Confirmed for 15w31c. Same obf as previous comment.

Confirmed for 15w32a.

15w32a mappings for this comment:

net.minecraft.client.Minecraft.displayGuiScreen(GuiScreen) = axz.a(bar), quoting lines 801 to 811.

this.mcSoundHandler.resumeSounds(); is this.aG.e() (line 809). aG is a bto.

SoundHandler.pauseSounds() is bto.a(), line 182. SoundHandler.resumeSounds() is bto.e(), line 199. Both call the corresponding methods on the f field, which is the SoundManager (btm).

SoundManager.pauseAllSounds() is btm.e() (lines 369-372), and SoundManager.resumeAllSounds() is btm.f() (lines 376-378).

Confirmed for 15w32b.

15w32b mappings for this comment:

net.minecraft.client.Minecraft.displayGuiScreen(GuiScreen) = ayh.a(bax), quoting lines 801 to 811.

this.mcSoundHandler.resumeSounds(); is this.aG.e() (line 809). aG is a bua.

SoundHandler.pauseSounds() is bua.a(), line 182. SoundHandler.resumeSounds() is bua.e(), line 199. Both call the corresponding methods on the f field, which is the SoundManager (bty).

SoundManager.pauseAllSounds() is bty.e() (lines 369-372), and SoundManager.resumeAllSounds() is bty.f() (lines 376-378).

Confirmed in 15w33a, 15w33b, and 15w33c. Sorry for the delay.

15w33a and 15w33b mappings for this comment:

net.minecraft.client.Minecraft.displayGuiScreen(GuiScreen) = ayt.a(bbj), quoting lines 804 to 814.

this.mcSoundHandler.resumeSounds(); is this.aH.e() (line 812). aH is a buo.

SoundHandler.pauseSounds() is buo.a(), line 182. SoundHandler.resumeSounds() is buo.e(), line 199. Both call the corresponding methods on the f field, which is the SoundManager (bum).

SoundManager.pauseAllSounds() is bum.e() (lines 369-372), and SoundManager.resumeAllSounds() is bum.f() (lines 376-378).

15w33c mappings for this comment:

net.minecraft.client.Minecraft.displayGuiScreen(GuiScreen) = ayy.a(bbo), quoting lines 806 to 816.

this.mcSoundHandler.resumeSounds(); is this.aH.e() (line 814). aH is a buu.

SoundHandler.pauseSounds() is buu.a(), line 182. SoundHandler.resumeSounds() is buu.e(), line 199. Both call the corresponding methods on the f field, which is the SoundManager (bus).

SoundManager.pauseAllSounds() is bus.e() (lines 369-372), and SoundManager.resumeAllSounds() is bus.f() (lines 376-378).

Confirmed in 15w34a.

15w34a mappings for this comment:

net.minecraft.client.Minecraft.displayGuiScreen(GuiScreen) = azc.a(bbs), quoting lines 806 to 816.

this.mcSoundHandler.resumeSounds(); is this.aH.e() (line 814). aH is a buz.

SoundHandler.pauseSounds() is buz.a(), line 182. SoundHandler.resumeSounds() is buz.e(), line 199. Both call the corresponding methods on the f field, which is the SoundManager (bux).

SoundManager.pauseAllSounds() is bux.e() (lines 369-372), and SoundManager.resumeAllSounds() is bux.f() (lines 376-378).

Giving you this ticket too, original reporter seems inactive.

Can confirm for 15w39c.

Please fix this. It's getting very irritating!

@@unknown It should be in the effects versions list already. I probably could actually write a mod for 1.8.8 and / or snapshot versions if I wanted to (it's a relatively small change to fix it) but I've had issues getting things to recompile.

Confirmed for 15w42a. A sound also replays when executing a command just after the sound played.

Confirmed for 15w44a and 15w44b

Yep, I put 15w44b in the list of versions (plus I also updated the obfuscation info).

@Pokechu22 Yes, I'm sorry, I saw it right after I made the edit, but I thought I shouldn't edit it again, since an extra mail would be sent.

Confirmed for 15w45a

The summary should say this also happens when executing a command or talking using the chat.

@@unknown: Done.

Confirmed for 15w47a and 15w47c

In case we need one, I've can confirm 15w51b.

This also happens with some mob sounds, notably pigs and villagers.

Affects 16w06a.