Administration¶

The Administration group in the “Node” area covers the node server services, storages, hardware, licence and maintenance. Its screens are available to the administrator role. Initial node setup is described in First start and activation.

Server Settings¶

General node parameters. The screen combines several settings groups under a single save panel:

Server

Server name, log level (global and separately for the SRT, RIST and FFmpeg libraries), log retention period, database statistics depth and tracing, and the size limits of both databases (logs and statistics).

The statistics database is bounded from two sides. “Statistics retention, hours” sets the window, and “Statistics DB size limit, MB” sets the volume. Zero in the limit means “no limit”, and the database is then trimmed by the window alone; the node raises a non-zero value below 16 MB to 16. Under the field the node reports the results of the last cleanup: how much history is left, how large the database is and how long the cleanup took. If the size limit has turned out to be stricter than the window, it also states there how much history is actually kept and how much is configured.

Mosaic

Node-wide switch for mosaic generation; the mosaic itself is described in Mosaic.

Meshwork

Enables the node’s participation in Meshwork and sets its identification: node name, note, Meshwork domain, as well as the public HTTP and HTTPS ports at which the node is reachable from outside (Nodes behind NAT), the additional domains of the super-node mode and the announce interface whose address the node reports to its neighbours (Node with several networks). What these parameters mean is explained in Node parameters.

Meshwork peers

The list of neighbour nodes and the shared signing secret for secure exchange (Neighbours and secrets). Each neighbour can have an announce interface of its own; below the list, the announce interfaces of nodes that are not in the list are shown.

Meshwork contact (advanced)

Peer polling parameters: the number of worker threads and the contact timeout. On a node of version 2.0.2.417 or later, the same place holds two fields for the unreachable-neighbour alert (Alert code catalogue):

“Node-down alert after, s” — how long a neighbour may stay silent before the alert: from 0 to 3600, 60 by default; values below 15 count as 15;
“Planned-stop grace, s” — how long not to raise the alert after a neighbour has announced a planned stop or restart: from 0 to 86400, 300 by default.

A value out of range is flagged under the field, and the settings cannot be saved. A node of an earlier version does not have these fields.

Initial node setup is described in Initial settings, Meshwork deployment in Building a Meshwork network.

Alerter¶

Trigger thresholds for node alerts and their replication rules. Besides the global alerter switch, the following are set:

stream thresholds: no-data timeout, minimum bitrate, CC error counters (“warning / error” pairs);
on a node of version 2.0.2.417 or later, under the CC error row, the CC error alert hold time: “Raise the CC alert after, s” and “Clear the CC alert after, s” (from 0 to 3600 seconds, 30 and 60 by default; 0 means at once);
on a node of version 2.0.2.420 or later (each field — if the node supports it), the “Input re-sync (codes 58, 59, 61)” block — thresholds per hour: “Lossy re-syncs per hour (code 58)” (3 by default), “Lossless re-syncs per hour (code 61)” (from 0 to 256, 0 by default) and “Output re-syncs per hour (code 59)” (6 by default), 0 means off everywhere; “Clear after quiet hours” (from 1 to 24, 2 by default);
in the same place, the “Backup inputs (code 65)” block — the “Alert on failing backup inputs” switch (on by default) and “Forget a backup input’s error after, min” (from 0 to 525600, 1440 by default; 0 means never; unavailable while the switch is off); the meaning of the codes is in Alert code catalogue, and their tokens are: 58 — sync-gap-resync, 59 — sync-rt-resync, 61 — sync-gap-absorbed, 65 — backup-input-error (List of alerts);
a separate warning on the CPU load of the worker thread that serves a stream or a DVB adapter (as a percentage);
resource thresholds: host CPU and memory, process and transcoder CPU and memory, network load, GPU, disk usage (in percent, “warning / error” pairs); on a node of version 2.0.2.416 or later, the “GPU” row is followed by a “GPU video memory” row: the thresholds of the NVIDIA card video memory fill alert;
on a node of version 2.0.2.416 or later, the system alert hold time: “Raise system alerts after, s” and “Clear system alerts after, s” (from 0 to 3600 seconds, 30 and 60 by default; 0 means at once);
DVR storage read/write time;
if the node receives DVB: frontend signal quality thresholds (signal level, SNR, bit error rate, uncorrected blocks).

Underneath the global switch, the node reminds you what this switch affects: a switched-off alerter also silences external delivery (process, Telegram and e-mail), including alerts replicated from neighbours across the domain and the notice that an incident already reported has been cleared.

Replication of alerts across the Meshwork domain and, separately, of system hardware alerts is enabled here as well (Domain-wide replication of alerts). External delivery is configured in a separate window (Alert destinations).

The alert model is described in How an alert works, and the thresholds in Alerter settings. Active alerts are viewed on the Alerts screen.

Alert destinations¶

The external alert delivery window opens from the Alerter screen with the “Alert destinations…” button. The channels are split across tabs; each has its own minimum event severity threshold:

Process: Runs an external command on an alert event, with a set timeout. How the command is run and what it receives, with script templates, is described in External scripts for alerts.
Telegram: Delivery to Telegram: the bot token and the list of chat IDs.
E-mail: Delivery over SMTP: server host and port, TLS mode (STARTTLS, implicit TLS or no encryption), server certificate validation, credentials, sender and recipient addresses.

All tabs of the window obey the global alerter enable on the Alerter screen: with the service switched off a configured channel sends nothing. The delivery rules are described in External alert delivery.

Web server & accounts¶

Configuration of the administration panel web server and of the login accounts. The screen contains the tabs:

Server

HTTP port and host name, HTTPS enable with a separate port and CA store selection, verbose tracing. While HTTPS is disabled, the “HTTPS port” and the CA store selection are greyed out with the note “HTTPS is disabled — enable TLS to use the certificate.”; the fields respond to the toggle itself, without waiting for a save, and the entered values are not lost. Below are the details of the current TLS certificate (subject, issuer, validity period, SAN) with the actions to import the certificate and the private key and to reload TLS; with HTTPS disabled the panel shows the same note instead of the details, but the import remains available.

Accounts

Local panel login accounts and their roles: Admin, Restricted admin, Viewer (Access and roles). Each account has a login, a password and a role; accounts can be added, edited and deleted. On creation the password is mandatory; on edit the password field is shown empty, and if it is left blank the password stays unchanged.

The last switch of an account is “Auto sign-in”, off by default. With it, a browser that has once signed in under this account opens the panel of this node without the sign-in form for the next 14 days; accounts with auto sign-in are marked in the list with the word “Auto sign-in”. The period is counted from the sign-in and is not extended by activity: once it expires, the form appears again. A link to an adjacent node followed from this panel carries the session further: a node of the domain opens already signed in. For this, several conditions must be met. The neighbour must publish its entry point (HTTP or HTTPS); it is visible in the details of its row on the “Nodes” screen (Nodes). The domain through which the nodes see each other must be the own domain of both: a link only through an additional domain of the super-node mode carries the session in neither direction. And if the neighbour has its own account with the same login, its own switch decides: with “Auto sign-in” off it does not accept such a session. If the neighbour has no such account, the session opens there with the Viewer role, whatever the role of the account on the original node. When any of this is not met, an available neighbour still opens, but at its own address and with the sign-in form. A neighbour’s address typed by hand does not carry the session, and neither does an account without auto sign-in.

The node explains a refusal itself: a bar “Opened without sign-in: …” with the reason appears above the content. There are four kinds of reason. Two are named by the node the transition came from, and two more are reported by the neighbour itself:

there is no auto sign-in session in this browser for the node the transition came from;
the shared domain is not the main one for the node the transition came from: this happens with a super-node that sees the neighbour only through an additional domain;
the neighbour knows this account, but auto sign-in is not enabled for it there;
the neighbour did not accept the hand-off session: it is unknown to it, has expired or has been revoked.

In practice the third reason is the most common: auto sign-in is off by default, so it is what ends a transition to a node where the same account has simply been created anew. The bar is drawn by the neighbour’s admin UI, so on the neighbour’s earlier builds none of the four reasons appears: such a neighbour does not report its own two and does not understand the other two, and the transition ends with the sign-in form without an explanation. The bar appears when the neighbour’s admin UI has opened, that is, after the sign-in if one was needed; it is closed with the cross and does not come back after the page is reloaded.

Auto sign-in is tied to a single browser: signing in with the same account in another browser works as usual, but there will be no auto sign-in in it. Auto sign-in ends with the “Log out” button, and also when the switch is turned off, the role is changed, or the account is renamed or deleted: the session is closed within a few seconds after saving. The switch is available for an account of any role, so enable it with the rights of that account in mind.

Automatic certificate issuance is on the HTTPS certificates screen, and reloading TLS without a restart is also in Maintenance. Service ports and initial setup are described in Initial settings.

Streaming HTTP server¶

Settings of the built-in HTTP server that delivers streams (OTT delivery, HLS/DASH playlists and segments). At the top is the status of the listeners (HTTP, HTTPS, HTTP/3). The following are configured:

Server: HTTP port, host name, verbose tracing.
TLS: HTTPS enable with a separate port and CA store selection. The port and the store are greyed out while HTTPS is disabled.
HTTP/3 (QUIC): HTTP/3 enable on a separate UDP port and permission for 0-RTT early data; the port and 0-RTT are greyed out while HTTP/3 itself is disabled. This block does not depend on HTTPS: HTTP/3 has a separate listener, which takes the certificate files directly and works with HTTPS disabled. The “Status” block shows exactly that: “HTTPS” may stand at “Off” while “HTTP/3” is running.

Below is the panel of the current TLS certificate with import and TLS reload. The panel follows HTTPS only, so with HTTPS disabled it stays silent even when the same certificate is served over HTTP/3. Delivery is described in OTT and DVR, and the HTTP/3 transport in HTTP/3 (QUIC).

EPG server¶

Settings of the service that delivers EPG (XMLTV) to external consumers such as middleware and applications. The screen has the service enable, the port, the host name and the verbose trace, HTTPS with a separate port and CA store, as well as the TLS certificate panel. The HTTPS port and the CA store are greyed out while the service is disabled or HTTPS is disabled. EPG access accounts and channel sets are configured separately, on the EPG Settings screen. Middleware integration is described in EPG for OTT middleware.

HTTPS certificates¶

Automatic issuance and renewal of TLS certificates via ACME (Let’s Encrypt). The status is shown at the top: the issuance state, the time of the last run, the ACME account and the list of issued certificates with their validity periods. The following are configured:

Automatic issuance: Enable and the contact e-mail. Enabling implies acceptance of the certificate authority terms.
Advanced: The ACME directory URL, the HTTP-01 validation port, the advance renewal period and the external account binding (EAB) parameters.

The “Issue / renew now” action starts issuance immediately. Own certificates are uploaded on the screens of the corresponding services (Web server & accounts, Streaming HTTP server, EPG server). Enabling TLS is described in Initial settings.

DVR storages¶

DVR archive directories. Storages can be added, edited and deleted; each has a name, a directory path (immutable after creation), a note and the maximum disk usage. The “Directory path” is written without a trailing /: the node will not accept a path ending in a separator (the root / itself is the exception), and the text of the refusal comes from the node as it is, in English. The path cannot be edited, so an entry created with a separator on earlier builds is corrected by deleting it and creating it again. A separate group governs the behaviour when disk space runs short: the cleanup interval, the delay and the truncation on overflow, the emergency reserve and the cleanup hysteresis; the emergency reserve is reserved and has no effect on operation (DVR storages). Lowering the usage limit truncates the oldest archive; deleting a storage leaves the files on disk, but the attached streams lose access to VOD. The current disk occupancy is shown on the DVR monitor screen. Archive recording and playback are described in DVR storages and OTT and DVR.

Maintenance¶

Node service operations, grouped into sections:

Node: A graceful node reboot with confirmation; it briefly interrupts all streams.
TLS certificates: Re-reads the TLS certificate from disk without a restart, separately for the web server, the streaming HTTP server and the EPG server.
Configuration backup: Downloads a gzip snapshot of the node configuration.
Restore: Uploads a previously saved copy: the configuration is replaced and the node reboots.

Files and services are described in Files and services.

Hardware¶

The detected reception hardware available to the node (read-only; the refresh button re-reads the list). Two blocks:

DVB adapters: DVB reception frontends: name, supported delivery systems, DVB API version, capabilities, frequency and symbol rate ranges, the busy flag.
CAM modules: CI/CAM slots: the inserted module and its model, the slot type and state, the CA system identifiers and the subscription (descrambling) status per programme.

This is also where the two kinds of module are distinguished, and it is the only place in the interface where the difference is named outright. The collapsed slot header shows a “Model A” or “Model B” badge, and the expanded body a “Model” row with the value A (sec-pump) or B (welded); the letter and the word come from the node and are not translated. Model A is a separate module through which the whole input of a stream is pumped; it is set up on the input (CI/CAM on a stream input). Model B is a module welded into the tuner; it is set up on the DVB adapter itself, by the adapter’s own programme (Descrambling). Nowhere else in the interface is the letter shown: the operator setting up a module tells them apart by where it is done.

The “Module ID” row describes the module itself: the manufacturer identifier, the product code and, when the module reports it, the EN 50221 application type (4A60:0001 · type 1). The row appeared in 2.0.2.362; in the same build the node began decoding the module name, so Cyrillic names stopped arriving garbled.

Three rows of the slot concern its lease: “CI lease” with the value “Taken” or “Free”, “Held by” with the holder’s service prefix in a monospace font, and “Module message” with whatever the module last put on the screen. The rows appear only when the node reports a value, so a free slot has no “Held by” row. They are not to be confused with the “free” and “busy” of the DVB adapter block: there it is about the tuner, here about the lease of a slot.

Releasing a slot. Otherwise the “Hardware” screen is read-only; it has two actions, and both sit side by side in the body of the expanded slot, below all the value rows. The first is “Release”. The button is available to the administrator only. A model B module has none at all: such a slot holds no lease, and the call would be refused anyway. When nobody holds the slot, the button is visible but unavailable, and the reason is written next to it: “Nothing to release: no input holds the slot.”. On a node older than 2.0.2.361 the action does not exist.

The “Release the CI slot?” confirmation window also states the order of the steps: “The slot is held by {holder}. First clear cam-device on that input: a running input will take the slot back in about two seconds. The call itself may take a couple of seconds.”. Read it literally: the release does not stick. A running input will take the slot back almost at once, so the slot is first cleared on the input and only then released. The call does take a second or two while the node stops data exchange with the module; the button shows itself busy for that time.

There are four outcomes. If the slot has been released, the dialog closes, “The CI slot has been released.” appears, and the slot list is read again. If nobody was holding the slot, that is a success too: the dialog closes with the message “Nobody holds the slot.”. If the slot is changing hands right now, the dialog stays open with the message “The slot is changing hands right now. Try again in a moment.”, so that one click repeats it. On any other failure the dialog stays open and shows the node’s own message or, if the node has not sent one, the message “The CI slot could not be released.”.

DVB reception is described in DVB receiver and Adapters, and CAM and descrambling in Descrambling. The detected transcoding devices are shown on the About screen.

Module menu¶

The second action of the slot is “Module menu”. It opens the CI module’s own menu, the same one the module would show on a television screen: card status, subscriptions, serial number, PIN entry, service items. The card drives the menu; the node and the web interface only relay its screens.

The button is available to the administrator only and only on a node 2.0.2.362 or newer; on an older node it does not exist at all. This is not the same threshold as for “Release”: on a node 2.0.2.361 “Release” is there, while the menu is not yet. The second difference from “Release” is that the menu is offered on a slot with a ready module of any model, including model B. The menu works through the CI session, where there is no lease at all, so a module soldered into the tuner has the same menu as a removable one. If there is no ready module in the slot, the button is visible but unavailable, and the reason is written next to it: “There is no module in this slot to talk to.”.

An occupied slot warns you. If an input holds the slot, pressing the button opens not the menu but the confirmation “Open the menu on an occupied slot?”: “The slot is held by {holder}. Some modules stop descrambling while the menu is open. To avoid that, pause the stream and then press ‘Release’ — a pause alone does not give the slot back.”. Read it in full and in the order written. A pause on its own does not surrender the slot: only a running input releases the lease, and a paused input does not run, so the slot stays with it until the input is deleted or the service is restarted. The pause is needed for something else: so that a running input does not take the slot back a couple of seconds after it was released.

This is a warning about a risk, not about an observed failure: in measurements, a stream being descrambled through an open menu kept being descrambled. But not all modules behave that way, and the slot does not show in advance which one you have. That is why the button is never blocked: the operator is entitled to proceed.

The session belongs to the slot, not to the operator. If the menu on this slot is already open, a warning appears next to the button: “The menu on this slot is already open. Opening it again will return both operators to the root menu.”.

What the window shows. The shape of the screen is set by the card, and there are five shapes:

a menu or a list — a heading and one row per item, each row a button, plus “Back”;
a text screen — the module’s message and “Back”;
a question — a prompt and an input field; when the module asks for a PIN, the field is masked and its length is limited to the one the module expects. “Send” submits the answer, “Back” leaves the question;
“Waiting for the module to draw the menu…” — the normal state for the first second or two;
“The module did not draw a menu. Some cards have none at all.” — the session is alive, the card simply has nothing to show; next to it, “Request again”.

At the bottom of the window there is always “Close menu”; Esc and “✕” do the same. That is the way to close the window: it tells the node the conversation is over and does not leave the session hanging on the module.

The texts inside the menu (headings, item names, prompts) come from the card and are not translated: in all six localisations they are shown in the language the card speaks. This also applies to the key hint the card prints at the bottom of the screen: it names the buttons of a television remote that the operator does not have, but those are the card’s words and they are passed on as they are. Information about the card does not always arrive as a text screen either: on some modules the serial number, the versions and the card status are given as menu items.

The menu closes by itself after two minutes without action, and this period cannot be disabled. The countdown is reset by an action (selecting an item, a submitted answer, going back) or by a new screen drawn by the module; reading a long screen does not count as an action. About twenty seconds before the end the window warns: “The node closes the menu after two minutes without action. Select something to keep it open, or simply open it again.”. If the period does run out, the window says “The session is closed. Open the menu again to continue.” and offers a button that does exactly that; nothing is lost, and the conversation starts from the root menu.

The window shows refusals with two messages. “The module did not accept this.”, or, if the node sent its own text, that text verbatim. “The node is not responding. Retrying.” means a temporary loss of connection: the window holds the last screen and keeps polling the node without closing the session. A screen that changed under the operator does not count as a refusal; the window simply redraws.

License¶

Information about the node’s licence: customer, licence type, key format, the start of validity and the licensed time; when the node reports the identifier and the type of the key, the HASP block is shown. The limits shown are what the licence permits, not what the node is using right now; a parameter that has no limit is not shown at all. In the demo edition the same lines describe its own built-in ceilings rather than a licence. The “Demo” flag and the note in the “License attributes” section say so: unlike the licence attributes, these ceilings really do limit the node. Permanent activation with SL/HL keys is described in Permanent activation, and the behaviour on licence expiry in When the annual or trial licence expires.

The “Activation” section works on a node with the protection system, whether the key is a software one or a USB one. If the node has no activation data, the section says so and shows no buttons; this is a normal state, not an error.

“Customer data” — exports the key state for the supplier. “Download C2V file” saves a file named after the key identifier, and “Copy C2V” puts the same content on the clipboard. The node sends nothing outward while doing so: both actions only hand the operator the same text. If the browser has denied access to the clipboard, the interface says so; downloading always works.
“Activate license” — applies the V2C key sent by the supplier. “Upload V2C file…” opens the file chooser, and “Paste V2C…” opens a field for pasting the text. The “Activate” button is enabled only after a file has been chosen or the field has been filled in.

Applying the key restarts the node: a few seconds after the key has been accepted, the service goes down for a restart. The restart cannot be postponed, and the activation windows warn about it in advance. While the node is unavailable, the interface holds a waiting screen and comes back on its own once the node is up.

If the key is rejected, the window stays open and shows the node’s own message. Read that message: refusals differ, and so do their consequences. The key may not have fitted at all: then nothing on the key has changed. But the key may already have been written and the refusal have arrived after that. This happens when the node could not re-read what it had written and when the resulting licence turned out to be expired. The licence screen does not re-read itself: to see what is on the key now, open the page again.

Two refusals are more dangerous than the rest, and they must not be read as “nothing happened”: the node reports that the licence has been applied but is already expired, or that it has been applied but found not to be genuine (the text, like all the node’s answers here, arrives in English). In both cases an unusable licence is already on the key, and a node with such a licence goes off to restart by itself and does not come back up. Either of these two refusals means that another key is needed, and needed immediately.

Transferring the licence to another node is not provided for in the interface; like applying an update and exporting C2V from the command line, it is done with the pss_lic utility (PSS Lic Perfect Streamer Toolkit v2.1 — the node licence).

About¶

A system summary, grouped into sections:

License: Brief licence information; the details are on the License screen.
Transcoders: The detected transcoding backends: type, executable version, readiness and the list of devices. Installing the transcoder packages is described in Transcoders, and choosing a backend in Backends and codecs.
Build and libraries: The PSS build version and the versions of the bundled libraries, the build type.
Identification: The server name, the node and its note, the current account, the uptime and the start time, the source IP restriction.

The documentation can also be opened from the common interface bar (Common bar).