When it comes to distributing content between multiple stations, especially when geographically remote, RCS has been offering a feature called Wancasting. Originating in NexGen, Wancasting gave the user a way to transfer songs, links, spots and other assets, from one system to another. We also gave you a way to exchange logs and voice tracks via the NexGen Wancasting feature.
When we implemented Wancasting in Zetta Version 2.3 four years ago, we kept improving it. We added ability to automate asset distribution based on assets’ station activation and provided an option to automatically propagate logs based on log sections changed. For audio, we added some intelligence so that only audio files that were different from what we found on the remote system were pushed. That way we didn’t waste your precious internet bandwidth by sending audio files the recipient station already had.
In fact, there were so many improvements and exclusive features in the Zetta brand of Wancasting, we had to give it a new name: “ZCast”. The new name kicks in with the upcoming Zetta version 3.5. This new version introduces a completely new technology that helps you share and synchronize content. That new technology is referred to as, Site Replication.
While ZCast will still facilitate” ad hoc” transfers of content between otherwise unrelated stations, Site Replication literally integrates two or more Zetta systems that can share more than just songs or logs. Way more, in fact…
The whole idea behind Site Replication was to create the “illusion” that multiple remote Zetta systems (each with their own database and content stores) form a single Zetta “super site” where any change made on Zetta system A immediately propagates to Zetta systems B, C, D… apart from all assets and asset types, we keep in sync all Logs, Hot Keys or Stacks banks and other elements: Stations and most Station-related configuration; Organizations (groups of Stations); Users, Roles and associated User Rights and User Preferences. We also went as far to give you synchronizing of user interface; Theming, Row and Attribute highlighting and even Keyboard shortcuts. You can work on a Zetta system in Boston today and then, a completely different Zetta system in New York tomorrow, and as long as you are a member of the Site Replication group, you’ll have the same experience every time.
Obviously, some items such as Computers and Computer configuration, including audio inputs/outputs or GPIO, are site-specific objects that are not involved in the Site Replication process.
Any and all changes propagate automatically behind the scenes and typically synchronize in less than a second. Site Replication is a fantastic technology to achieve high-quality system redundancy and emergency recovery.
In your Zetta system on Site X, you can set up multiple additional replicas (X1, X2, X3…) that will mirror one another. Let’s say you have hardware failure. All you have to do is switch to another Zetta system! All these redundant systems can keep on playing audio in parallel with your main on air Zetta.
If you use GSelector for music scheduling and station programming, you can benefit even more from Site Replication. Each Zetta site would typically have their own GSelector instance; with Zetta and Site Replication in between these GSelector systems, songs, links and logs can be synchronized from one GSelector to another GSelector.
We also equipped Site Replication with throttling capabilities to allow system administrators control inbound and outbound bandwidth. Each and every transfer knows its own priority and importance based on when it is “needed.” For example, we transfer songs and other assets in the order in which they will be needed for playout by Stations’ Logs. That way, the more “urgent” commercial gets bumped up and pushed across to other systems before a song that won’t play until next week (this is particularly useful when your bandwidth is limited). No user intervention is required, these decisions happen automatically and behind the scenes.
So what if your group manages say five Zetta sites where sites 1-3 need all the group’s content but sites 4-5 only care about some? We considered that model as well. For each Zetta site you define which Stations that particular site “subscribes to” and therefore, cares about. While metadata (song titles, artists, station or user information etc.) are cheap to transfer as far as bandwidth utilization goes, with audio files it’s a different story:
If the site subscribes to some stations only, audio files will only be transferred to the site if corresponding assets are active on the station(s) that the site subscribes to. While this helps save bandwidth tremendously, station personnel still have access to all assets in the group which can be easily searched in the “enterprise” asset Library. A user can simply activate those assets, provided the user has sufficient user rights (and remember, user rights are synchronized within the group as well therefore can be managed centrally!).
All in all, Site Replication is another cutting edge feature to look forward to in the upcoming major Zetta release, version 3.5. For additional information on Site Replication, please contact RCS.