Moving the services to a new host

[mcrossley]

I have AfterTouch (0.127) and the player installed on a rPi and functioning great.

I want to move the services to a different rPi.

When I tried that (copying what I thought were all the config files - and amending the contained IP addresses), after migrating two ST10's to the new rPi, they worked OK (NAS etc) except for the Radio Player and presets that use it.
Migrate the speakers back to the original rPi and the radio player presets worked again.

Could you create a doc or give me some hints on how to migrate the services from one host to another?

[gesellix]

Thanks for the question, @mcrossley. There's no guide for this yet; I'll add one to the docs. Until then, this is the order that should work:

1. Stop the service on the old Pi, so nothing changes while you copy.
2. Copy the whole data directory, not only the config files. Its location is the DATA_DIR in your env file (/var/lib/soundtouch-service with the Pi installer). Besides the speakers, presets and settings, it holds certs/, the certificate authority your speakers were given during migration. Without it, the new Pi creates a new one, and the speakers don't trust that until they are migrated again.
3. Keep the address the speakers know, if you can. If SERVER_URL uses a hostname (for example a name your router hands out), move that name to the new Pi, and the speakers need no change at all. That is by far the easiest way.
4. If the address changes, set SERVER_URL on the new Pi to the new address, run the migration again for each speaker from the Migrate tab, and restart each speaker afterwards (unplug it for a few seconds).

There is one catch with a changed address, and it probably explains what you saw. Radio presets created with Play URL in the player (or with soundtouch-cli) store the full AfterTouch address in the preset, e.g. http://<old-pi>:8000/core02/.../orion/station?data=.... After the move, those presets still point at the old Pi, which is why they worked again once you moved back. TuneIn and Radio Browser presets don't have that problem; they only name the station. So with a new address, those Play URL presets have to be saved again. Your NAS kept working because the speaker streams from it directly, without AfterTouch.

If you try again and something still fails on the new Pi, please create a diagnostic export there (admin page, Health tab, "Download diagnostic report") and attach it here. It shows which addresses the speakers and their presets are actually using.

[gesellix]

The guide is online now: Moving AfterTouch to Another Host. It has the steps from above, where the data directory lives for each install method, and the catch with Play URL presets. Making those presets independent of the address is tracked in issue #769.

[gesellix]

A follow-up on the Play URL catch: with the next release, Play URL stations no longer store AfterTouch's address, so they keep working after a move, like TuneIn and Radio Browser presets already did. For presets saved earlier, the Health tab lists the ones that still carry a full address and offers a button that stores them again in the new form. Details in issue #769.

[mcrossley]

Great, thanks for all this. I'm not in a rush, so I'll maybe wait for the next release, then I can test the new presets function.

[mcrossley]

OK, updated the service on both servers.
Migrated first ST10 - OK, presets work.
Second ST10, would not migrate as there was an issue with the presets (3,2) service config showed 2 presets, speaker showed two presets. Data sync says (3,2).
Anyhow, removed the presets from the ST10, Data Sync, then Migrate and all goes ok this time, and the two presets reappear and work OK.

Thanks for these updates and documents. The only thing I had to do different was change the default http/https ports on the service on the new host as it already runs web services on the defaults (plus another web service on 81).

[gesellix]

Thanks for testing the move and for writing it up, @mcrossley. Good to hear both ST10s play their presets from the new host.

About the second ST10: before migrating, AfterTouch compares three views of the speaker's presets (what the speaker reports live, what the service stored, and what it would hand the speaker back after migration) and refuses when they disagree. That's what kept it from migrating. Since both the speaker and the service page showed two presets, I'd like to understand where the third one came from. If you happen to still have the exact message somewhere, I'd be glad to see it, but no need to reproduce anything, it's working now.

The ports are a good point. A different port is a different address for the speakers, the same as a new hostname, so it needs the re-migration you did. The guide now says so in Step 4: If the address changes.

[mcrossley]

Sorry, I do not have a screenshot of the error. I had a quick look at the service log and it may contain some useful information for you. I shows my failed attempts, various re-scans etc and eventually working after I removed the presets. The device that failed is called "Bedroom"
aftertouch-diagnostic-2026-09-28T21-28-12Z.age.txt