There are a few things going on, if we knew the full details we’d fix them ![]()
(Historically) the first boot just after an update doesn’t clear memory before the reboot, that means various things may not get reinitialized correctly. So it used to be good to power off after an update before you start listening. (I don’t know if this is still a problem or not.)
In early releases after running for a length of time the FPGA would “slip a gear”, one state machine would get out of sync with another and some signals might be clocked too early or too late, almost always working but not quite. I’ve carefully tried to find any bugs like this and fix them, the last releases that I knew they still existed were Pike’s Peak and Yale. You needed to do a reboot to fix that.
The update process doesn’t do a reliable job of translating settings from the old release to the new release, some times the result is simply that the volume comes up wrong or one channel is silent because the balance was cleared on one side, etc. Some of the stored configuration data is more critical, but the effects when wrong are harder to analyze. Just as an example that many here can relate to from the Snowmass versions: these bad configurations can, say, refresh the screen too often or at a wrong rate and cause audible interference. These bad configurations in flash persist when rebooting. Changing to another release (not always the same one) can clear the affected memory and then when reloading the new software you’ll be like everyone else.