Server upgrade, IP address changes affect some automation and metadata push users

We’re moving Spinitron to a new cluster of servers each with of 8-cores with 128 GiB memory. This is necessary to cope with the growth of database tables and search engine indexes. The IP addresses of our servers will change.

In the past changing server IP address caused some disruption to service no matter what. This time it can be avoided if you take certain steps before we shut down the old servers.

Automation systems

If you are using ENCO, iMediaTouch, WideOrbit or Skylla then you need to update the IP address it uses to send now-playling updates to Spinitron. At present it is probably configured to send to

  • Change your automation to send to (asap)

Your protocol and port number stays the same – only change the IP addess. Updated instructions to configure your automation systems are in Spinitron in Admin: Automation & API: Automation control panel, including the protocol, IP address and port number to use.

Metadata push

Many of you have metadata push channels sending to devices (RDS encoders, for example) behind firewalls. The firewall is usually configured with a pinhole or port forwarding rule that accepts data only from one of Spinitron’s IP address and

  • Change your firewall/router to accept ALSO from (asap)

Protocols and port numbers are unchanged – only change the source IP address.

When everyone has transitioned and we cut over metadata push to send from the new address, we’ll notify you again so you can close the other two addresses.

We will gradually start using starting Feb 20 2020 ramping up to Mar 25 at which point the old addresses will be phased out.

Warning: Very dense person.

My automation system runs with an urlbase of

would I be changing the bit to the ip above or no?


Hi Eric, thanks for joining the forum!

No, the change doesn’t affect your automation.

Most automation systems including yours use the host name, which isn’t changing. But ENCO, iMediaTouch and WideOrbit don’t accept a host name and only accept an IP address, and that needs to change.

And thanks for asking, @WNMC_Eric. Your question showed how I could make the notice more clear.

Super. Thanks for the clarification.


Transitioning tcp:// and udp:// push channels

Today we started a gradual transition of the push service from using the old source addresses to the new one on tcp:// and udp:// push channels.

From now until Mar 25 2020 the push service will choose at random to send from the new source address or from one of the old source addresses.

The probability of using the new address is starting at about 1% now and it will increase by roughly 3% per day until Mar 25 at which point it reaches 100%.

This applies to tcp:// and udp:// push channels only.

If you have already opened your network equipment (e.g. routers, firewalls) to accept TCP and/or UDP push messages from then you’re all set – you don’t need to make any more changes at present.

If your network equipment is configured to accept TCP and/or UDP push messages only from the old addresses and then

  1. Some of these messages will be lost. The loss will be random and the rate of loss will increase steadily from now until Mar 25 at which point all messages will be lost.
  2. You should set your network equipment to accept also from the new address and then 100% of messages will get through.

If you have any questions or need any help, please contact me here or by email or phone.

Is the transition complete? My university IT department removed the firewall pin holes from the old addresses this past week. I’m only getting about every third song pushed to my RDS encoder from the new address.


Hi Mike,

Yes, the transition was completed a while back. We’re only sending on afaik.

So we should look for other explanations. I see you have 3 channels all of which seem to be working as far as the metadata push logs can reveal. Is there any problem with the other two? I mean, do the same messages get lost on all channels or is only RDS affected?

If you want, I can put a packet monitor on the destination address and port of the RDS channel and then we can cross check that with the metadata push log. Let me know.