Describe the bug

In a rehearsal with about 20 users which my client had seen before, I experienced unexpected resets of fader levels and mute state in my mix. I think this always happened when someone (re)connected. It always affected the same users and I suspect that mixer/mute state got restored to what was saved from a previous session.

To Reproduce

• Run a Jamulus server (should not matter if 3.6.2 or master)
• Connect Client A, B (based on current master code)
• In Client A's mix, mute B.
• Close Client A (to ensure that mixer levels are saved)
• Re-connect Client A
• In Client A's mix, unmute B.
• Connect Client C
• In Client A: Observe, that Client B gets set to muted again (to be verified)

The same happens to mixer levels.

Expected behavior

In Client A, B's mute state should not change unexpectedly.

Operating system

Arch Linux

Version of Jamulus

Current master (e7389e3) for both server and at least the problematic client.

Additional context

#1009 seems to be the culprit. My assumption there was that it would always be safe to load stored mixer settings. I suspect that this is not the case and that mixer settings are only stored on specific events (client exit?). If this is the case,

• we could revert Client: Always update gain levels #1009 and solely rely on Server: Send empty channel list on connect #1010 to keep Restarting the server on the fly ignores set levels and mixes everybody at 100% #955 fixed or
• we could ensure that mixer state is stored more regularly (e.g. any time something changes or timer-based).

I'd prefer the second option. I think it might even fix two other edge cases:

• If a Jamulus client exits unexpectedly, all changed mixer state might not get stored (even in 3.6.2).
• If a Jamulus client sees a new user for the first time and the fader levels are adjusted, then they might not be stored immediately. If that new user disconnects and re-connects later, I suspect they will start with initial levels again. Update: Fader settings are stored when a fader slot becomes unused:

  jamulus/src/audiomixerboard.cpp

  Line 1219 in 22d34ed

  StoreFaderSettings ( vecpChanFader[i] );

#1010 may also trigger this issue, but I'd argue that this is not that bad. Without #1010, mixer state for all clients is wrong. With #1010, mixer state may still not be fully up-to-date, but it will at least be close to being up-to-date (I suspect mixer state will be the same as during the initial start of each Jamulus client).

• Reproduce with master-level server and master-level, clean client code and adapt issue title.
• Decide on a fix (I'd prefer optimization of the fader storage logic)