Confirmed - cause found, patch not written yet.

Muting only writes the volume to zero; nothing records that you muted it. Changing map restarts the track and the real volume gets written back.

Moving it out of OPEN so the list reflects reality: this one is pinned down to exact files and lines, so what is left is writing and testing the change, not working out what is wrong.

Fixed in 100ddb65.

Cause: the audio system had never heard of the mute setting. The SYSTEM OPTION checkbox set a 'muted' flag and then faked the mute by pushing the volume to 0 - which writes the stored volume as 0. But closing the options window re-saves that same stored volume from the untouched slider, throwing the 0 away. So the mute survived exactly as long as the window stayed open.

The next map change destroys the muted track and builds a fresh one straight from the stored volume, and the music came back at 50% - your 'travelling between maps resumes the music'. Logging out and back in was the same thing on the boot path: the mute flag reloads from settings and nothing consulted it.

Fix: the flag is the gate now. The stored volume carries the SLIDER and nothing else, and the two are folded together at every point the volume is read - the track built on each map arrival, the live volume change, and Southperry, which had been ignoring both the slider and the mute in favour of a hardcoded 0.5.

Muting by volume rather than by stopping the stream is what the real client does, so the track stays in sync and unmuting picks it up where it would have been.

Retest: mute BGM, change maps a few times, then log out and back in.