Why move from Flussonic Media Server to Catena

Your television is already on the air. Flussonic Media Server has been carrying it, often for years, and it will keep carrying it: the product stays supported, and we keep issuing security updates.

What has changed is where the product grows. The phase of active development of Flussonic Media Server is over. New capabilities go into the products on the new core. For a television or OTT service that product is Catena. For video surveillance it is Watcher. This post is about television.

Media Server was written for one server. The configuration lives on the machine, the stream belongs to that machine, the archive is written to its disks. When the service grew into several servers, clustering stayed a set of agreements between machines that still each live their own life. Every new channel, every night-time failure and every extra server costs engineer hours that the license line does not show.

Catena is built on Sapsan, the new streaming core, and the thing you manage is the cluster. We are asking you to move because the next years of the work — placing streams, surviving a failed server, finding a problem without logging into each box — happen there. And because we do the move with you.

What gets easier in daily work

The gain is not a longer feature list. It is the same jobs you already do, with fewer machines to touch.

Adding a channel. Today you pick a server and copy settings onto it, and those copies drift apart. In Catena you add a stream. Central holds the configuration, and the layouter decides which streamer runs it. One template covers the transcoder, the archive and the timeouts for the whole grid.
A server fails at night. Today someone logs into the machines that are still up and moves streams by hand. In Catena the layouter places streams onto the streamers that are alive, and every decision is recorded with its reason. If central itself is down, streams keep broadcasting and the archive keeps recording: a management outage is not an on-air outage.
The backup input. Today you learn that a backup source is dead when the primary fails. Catena probes the backup while it waits and shows whether it is ready to take the load, on the sources tab, before the incident.
Finding what went wrong. Today the answer is spread across server logs. Catena answers from one console: the dashboard, sessions one by one, and source diagnostics past "frames or no frames".
Growing. Today another server is another configuration to remember. In Catena you add a streamer, and placement is recalculated. You do not rebuild the service you already have.

On low-latency protocols — HTTP MPEG-TS and RTSP — Catena 26.08 holds 30,000 concurrent viewers on one streamer. Media Server on those protocols ran into roughly one to two thousand. That is headroom for the same service, not a reason to buy a second installation before you have seen yours run.

What stays, and what you will touch

The subscriber product stays. Subscribers, packages, the programme guide, billing and the applications are yours. Catena delivers the picture. If you already have a portal, you do not replace it to start the move.

A few things transfer as they are, and that is the point of the import wizard:

Stream names stay, so playback paths stay. Import does not rename a stream: a new name would break every player link and the archive path. You switch viewers to the new address only after the air is checked. If Catena then takes the same port, the links subscribers already have keep working.
Authorization backends written for Flussonic attach without a rewrite: the same request, the same headers. The portal keeps deciding who may watch.
The archive stays on the disks where Flussonic wrote it. Catena reads that archive directly. There is no copy of years of recordings. The stream name and the disk path have to match; the wizard shows source storages next to the disks configured on the streamers before you apply anything.
The servers stay. They take roles in the cluster — prepare, record, deliver — instead of going to scrap on day one. What fits your rack is a calculation for your channel count and your viewers, not a number from this page.

What you will actually touch:

The machine, not the channels. Listeners, archive disks, VOD locations and certificates are set when you add a streamer. Import moves content: streams, template sections, authorization backends. It does not move the layout of one particular server, and the report lists every section that did not transfer.
Scripts that create or edit streams through API v3. In Catena, central owns the configuration, and writes go through API v4. Reading statistics and listings over v3 keeps working.
Streams that each had their own authorization. Catena has one access policy for the cluster. The wizard stops and asks what to do with those streams before it applies anything, so a paid channel is not opened to everyone by accident.
Encryption. DRM settings do not travel literally. An encrypted stream is imported disabled; you configure encryption and only then enable it.

The full procedure — plan, report, archive check, switch-over, rollback — is in Moving from Flussonic Media Server.

How the move goes

Import is not the switch. The old server keeps the air until you decide otherwise.

Catena runs beside the current service. On the same machine it takes a free port, so both stay up.
The wizard reads the running Media Server over the API and shows a plan: what will be created, what will be skipped, what does not transfer, and whether it fits the license. Nothing is written until you confirm.
You read the report. Each skipped field has a reason. You check the air on a few links, and you open an old recording to confirm the archive is really there.
A pilot is one or two channels, or one group, with the portal pointing only those viewers at Catena. The rest of the grid stays on Media Server.
Viewers move when that check passes. Only then is the old server stopped.

Rolling back before the viewer switch costs nothing: it means not switching the traffic. The import does not change or delete the source configuration. After the switch, rollback means putting the previous address back into delivery.

If you have several Media Server machines, the wizard runs once per machine. Placement of the result is the layouter's job, not a copy of the old peer list.

Who is with you during the move and after

Support of Flussonic Media Server does not stop because Catena exists. Security updates continue. What stops is new capabilities on that product. Staying is a working choice for a service that should keep doing exactly what it does today. It is a poor choice for a service that still needs to grow, because the growth is being built in Catena.

The move is not a document we send and a queue you enter alone. Tell us about the installation and we plan it together: what moves first, how the air is checked, when viewers switch. The import report is the list of what did not transfer, and it is the thing you attach when a field needs a human. Bugs found on the pilot are handled on that same installation, by the same company that already knows your Media Server.

If you are already paying for Flussonic Media Server, write to us. We convert those licenses into Catena licenses and work out the terms for your installation.

What it costs, and what happens to the servers

The license line is often the small part of the bill. The part that grows on Media Server is the hours: night calls, settings that drifted apart, the next server added because the current ones are operated by hand. Catena is a subscription for software on your servers. The size follows the number of channels and viewers in the license. Viewer traffic does not pass through our network.

We do not promise that the subscription will be lower than your current license. That number is honest only after we see the installation: how many channels, how many concurrent viewers, where the archive lives, which servers you already have. The same pass says which machines stay, which role each one takes, and what the pilot needs on top of production. You take a plan to the budget conversation, not an open-ended "it will cost more".

Both systems run until the switch, so the pilot does not require a second full installation before you have evidence.

Where to start

Write to us with five facts:

how many Media Server machines are in production;
how many channels;
how many viewers at peak;
whether the portal and billing are yours;
where the archive disks are.

Back you get a picture of the move: what transfers as it is, what you will touch, a pilot of one or two channels beside the current air, and a sketch of hardware and cost for your volumes. The detailed steps, when you want them, are in the migration guide.