I don't think the bug as reported was actually happening

I’m unconvinced from the video and my own experimentation that there were duplicate sounds playing. Does the script for every scene load and call Start() while one scene is executing? If so, why isn’t it logging to the console? It would make little sense that scripts for the non-active scene could execute, but not log. (And in the video, those logs were not present - they were being referred to as what happened “between” the logged messages).

I feel like the people that experienced the issue had the background music asset duplicated within the scene, without noticing.

Can anyone comment on this? The idea that scripts can run for the non-active scene without a log is disconcerting to say the least.

1 Like

Hmm. That does seem fishy. Is this mentioned in an edit for that video?

Hmmm. I just rewatched it to come up with a bunch of notes and realized that he wasn’t saying it happened on game start, but on transitioning between scenes. That does make sense and I’m embarrassed to have misunderstood.

Nothing to see here. Move along.

I’m having a off issue. Ben goes on about there being somesort of bug, however whenever I go between the scenes there appears to be NO glitch or bug I can notice at all and I have pretty sensitive ears so I would’ve noticed if the music paused for a second…I don’t really know what’s going on as it appears to be perfectly fine for me (apart from we haven’t yet asked the music to loop yet.).

Perhaps your setup is slightly different? I’m not sure.

You wouldn’t hear a pause. The bug he’s referring to is that the background music will start on the second scene when the music object Awakes. This is because Awake() is called first, then Start(), and it was in Start() where the music object destroys itself. So while your music from the first scene continues to play (as intended) it is possible that another copy of the background music starts to play and then stops.

However, this will be a very short time. The amount of time it plays for before the Start() function is called will vary depending on your computer speed and what else it is doing at the time. So this bug would be very computer hardware, version, processing, etc dependent. I think most people won’t hear the bug. But his change to use Awake() instead of Start() is still the right approach if the goal is to kill the music object before it starts playing.

I’d still prefer to see a proper implementation of a singleton rather than letting the object come to life and then destroy it.


Weird, it never happened for me. I’m assuming because I never had a awake() function in the script until that video as I never picked that up. Either that or the newer form of unity doesn’t have that bug?

I didn’t have it either. It likely won’t manifest on computers with a decent amount of hardware. But you can see from how the problem was laid out by Ben that the potential for the issue exists.

It definitely isn’t because you didn’t have Awake() in your code. Awake() is something that will happen whether or not you’ve written it. For example, the music game objects have a checkbox that says “Play on Awake”. That means they start playing automatically during the Awake() call, which is why the music plays automatically the way they’ve set up the game.

Adding code for Awake() simply lets you inject your own code to also happen during the other things the system is doing behind the scenes during Awake().

So to sum up: this wasn’t a Unity bug. It was a bug of Ben’s creation because deleting the music game object in Start() allowed for it to play for a short time depending on the time between Awake() and Start(), which will vary depending on your computer’s hardware, and he corrected the issue by deleting the gameobject in Awake().


Makes sense…my system is pretty good (certainly not the best, but I can play Witcher 3 and XCOM 2 fairly well, though the latter slows down thanks to mods.) so I probably never saw that.

Thanks for this great explanation, it really helped me to solidify the subject material in this lesson!

1 Like

Privacy & Terms