the component dies with its owner. components live and die with their actor, and the game state is torn down and rebuilt on every level change, so your music manager component and its active track variable are destroyed at the exact moment you travel. the state does not reset, the object does.
the lifecycle map, ownership top to bottom:
game instance: created at engine start, survives everything until shutdown. this is where cross level state belongs. either promote your music manager to a game instance subsystem (created automatically, blueprint subclassable, one instance per game) or keep a component on a game instance spawned actor.
game state: exists on the server for the match, replicated to clients, but recreated on travel unless seamless travel is configured, and clients tear it down fully on seamless transitions. match state belongs here, background music does not.
player state: per player, survives most travels server side, still not the right home for global music.
the cleanest fix for a music manager: create a game instance subsystem blueprint, move the active track variable and the play logic there, and have whatever UI or actor needs to talk to it just get that subsystem by class. subsystems are directly blueprint accessible from anywhere that has world context, so the awkward component-on-gamestate wiring disappears entirely. actors that spawn per level can find it, set the track, and the subsystem keeps playing across the travel because nothing destroyed it.
one detail to keep music gapless across a travel: audio components attached to level actors stop when the level unloads. if the music source lives on the subsystem side and only the volume or track parameters get adjusted per level, the audio component should be owned by something persistent too. the simple pattern is the subsystem holding its own audio component created against the game instance, which never unloads.
