Moving from Flussonic Media Server¶

Catena can take the configuration of a running Flussonic Media Server and create its own streams from it: the import wizard reads the configuration over the source API, shows exactly what will transfer and what will be lost, and writes the documents only after you confirm.

Import is not a switch. It is the first step of a procedure that also includes setting up the machine, checking the air and finally moving your viewers. This page describes the whole of it.

Before you start¶

• Flussonic Media Server is running and reachable from central over the network. Import reads the configuration through the source API rather than parsing a file on disk. A stopped server has nothing to import from.
• An account allowed to read the configuration — the same one you use to log into the source interface (edit_auth or api_auth).
• A Catena installation is already up: central with the console and at least one streamer. If you don't have one yet, start with the quick start and come back here afterwards.

Central never stores the source credentials: they live only while the plan is being built and reach neither the database nor the logs.

What import transfers, and what you set up yourself¶

Import transfers content:

• streams,
• template sections (transcoder, archive, thumbnails, timeouts),
• authorization backends — into the cluster-wide access policy.

Import does not transfer the machine layout, because it describes one particular server rather than your air:

• listeners and ports,
• archive disks and their layout,
• VOD locations,
• reverse proxy and TLS certificates.

You define all of that when adding a streamer — see adding a streamer and node settings. Import lists every non-transferable section it found at the source in the report, so that nothing slips out of sight.

One thing worth remembering: a stream with a configured archive will transfer, but will not start recording until storage is configured on the streamer. The depth and size of the archive live in the stream document, while the storage location lives in the machine settings. Set up the disks before you switch traffic over, otherwise recording will look enabled and not happen.

A cluster is migrated one machine at a time¶

Import knows one address per run. If you have a Flussonic cluster, run the wizard once for every server: cluster configuration is spread across machines, and each has its own.

Streams the server sees from its neighbours will not become documents — they are its state, not its configuration. Streams created by publishing will not transfer either: the air creates them, not the operator.

The Flussonic cluster topology — peers, balancers, cluster_ingest — does not transfer at all. Placement here is the layouter's job: you say which streams you need, and it decides which machine runs them.

Going through the wizard¶

Open Import from Flussonic in the console and enter the source address and credentials.

The wizard builds a plan — what exactly will be done, before a single write:

• how many documents will be created, and how many skipped or overwritten (and which ones, by name);
• whether the import fits your license;
• which access policy is in effect now and which one will replace it;
• which source sections do not transfer;
• the warnings described below.

A plan lives for fifteen minutes and is applied once. What gets applied is exactly what you saw on screen: if the source configuration is edited in the meantime, those changes will not be part of this import — build the plan again.

There are two policies for name conflicts. Skip (the default) leaves whatever already exists in the cluster untouched — which is why repeating an import is harmless and convenient for topping up. Overwrite brings documents in line with the source; the plan lists such names, and mind that overwriting also wipes your own edits made in Catena.

Streams with their own authorization¶

In Flussonic access can be configured per stream. In Catena the access policy is cluster-wide — a stream has no authorization of its own.

This means a stream protected at the source by its own backend ends up under the shared policy after the import and changes who can watch it. For a paid channel that can mean being opened to everyone.

So the wizard never lets such streams through silently: it shows how many there are and asks what to do — import them under the cluster-wide policy, or leave them out and set them up separately. Until you answer, applying is unavailable.

Imported streams go live immediately¶

A stream transfers enabled unless it was disabled at the source. While the old server is still on the air, this has a price, and the wizard warns about it:

• sources get a second consumer. An RTSP camera with a connection limit will give the stream to one of the servers; SRT and RTMP pull may kick the old connection.
• pushes will go to the same receivers. If your streams have pushes configured, the transponder or CDN gets a duplicate, and the viewer is the one who sees it.

Turning off only the delivery is not possible: a push configuration has no "disabled" flag. If running both servers in parallel is unacceptable for you, plan the import closer to the switch-over itself, or stop the pushes at the source.

Why some streams may not start¶

Placement in Catena is the layouter's job, and a stream may end up on any suitable machine. If the stream input is local to the old server — multicast, a file on disk, a capture card — it simply does not exist on another machine, and the stream will not start.

Import lists such streams in the report. After applying, the wizard shows how many imported streams came up and which did not: that is your check that the move worked. The count is not instant — the console keeps asking the cluster while the streams start, so right after applying it reads lower than the final figure.

In the screenshot exactly the two that should have failed did: sport-hd listens to a multicast group only the old server can reach, and lobby-cam points at a camera that is not on this network.

Reading the report¶

The report is folded by reason: one row is one reason, with a count of affected streams; the stream names themselves expand from the arrow on the left. There are four categories:

The report can be exported as a file — convenient to attach to a support request. Passwords in it are masked.

This page deliberately carries no list of all non-transferable fields: that list lives in the report itself and changes together with the product, while a copy in the documentation would drift away from reality.

The archive stays where it is¶

There is no need — and no reason — to move the recorded archive: Catena reads an archive written by Flussonic straight from disk, see archive. Import does not touch archive files at all.

It is enough that the streamer has the same disks configured and the stream keeps its name: the archive path is built from the stream name.

Player links and your integrations¶

Playback links do not change. Stream names transfer as they are — which is why import offers no renaming on conflict: a renamed stream would mean a broken link for every viewer and a broken archive path.

API v3 is read-only. If your scripts created or edited streams through the Flussonic API, they will have to move to API v4 — in Catena the configuration is managed by central, and writes go through it. Reading statistics and listings over v3 keeps working.

Switch-over order and rollback¶

1. Add a streamer to Catena and set up its machine part: listeners, archive disks, VOD locations.
2. Run the import and read the report. Deal with the "not created" and "transferred approximately" entries.
3. Wait for the streams to come up and check the air on several links — especially where a transcoder was involved.
4. Check the archive: open a recording from the past day.
5. Switch the viewers over to the new address.
6. Only then stop the old server.

Rolling back before step 5 costs nothing: the old server keeps running the whole time, and going back simply means not switching the traffic. After step 5 a rollback means putting the previous address back into delivery; import neither changed nor deleted the source configuration, it is still there.