· Subject: Migrating ancient Roon Bridge (v159) identifiers to fresh DietPi v10 setup results in generic "Enable" zone. Core Machine: [Mac mini ] Endpoint: Raspberry Pi 3 Model B with IQaudIO DAC+ HAT running DietPi v10.5.2 (Debian 12 Bookworm). Description of Issue: I did a fresh installation of DietPi v10 on a Raspberry Pi 3. I backed up the RAATServer and RoonBridgedirectories containing my original 2018 endpoints from an ancient v159 system. I restored the folders into /mnt/dietpi_userdata/roonbridge/, added the leading dots to make them .RAATServer and .RoonBridge, and verified that the unique_id file contains my original string: b290f3e7-49bc-4099-83f6-20447dc457b0. I applied proper roonbridge:roonbridge ownership permissions. Despite having the matching historical unique_id file present, the Roon Core server refuses to pair it with my historical Kitchen zone profile, displaying it as a brand-new audio output with a blank "Enable" button. Question: Is there a way to force the Roon Core database to recognize this unique ID and map it back to my original zone profile history and settings, or has the deep kernel ALSA hardware string migration between old and new Debian versions caused the server to permanently orphan the old zone configuration?
Tell us about your home network
· n/a
(edit I set this one up as as new, but I have another zone I really want to preserve the setup if possible so am holding off updating dietpi there until I better understand this issue)
While wanting to preserve your historical zone settings is understandable, you will need to set up this endpoint from scratch.
We cannot guarantee the stability or correct behavior of third-party Roon Bridge implementations (like DietPi) when configuration files are manually copied or modified across different OS versions.
For your remaining zone, please perform a clean, fresh installation without migrating the old folders and enable it as a new audio output to ensure a stable connection.
OK, thanks. That’s a shame, in the old days there were ways to reliably preserve these things based on the unique_id - I mean ultimately it’s just a pointer?
I was happy to install fresh, just wanted to then push the original unique_id back to preserve the rest of the settings.
You are correct that in older builds, manually moving the unique_id file often worked to transfer zone settings. However, while this was a common workaround, it was never an officially supported migration method.
RAAT device identification has since evolved. To ensure playback stability, Roon Core now strictly anchors a zone’s identity to both the unique_id and the exact underlying ALSA hardware string provided by the OS.
When upgrading to Debian 12 on DietPi v10, the OS changes how it presents that hardware path. Because the old unique_id no longer matches the new hardware string, Roon correctly treats it as a new device to prevent configuration conflicts.
For your second zone, the best approach is simply to note your DSP and device settings beforehand and apply them to a clean installation.