Version history

version 2.0.2.362 Beta

06.09.2026

  • CI module menu — the module’s own menu is now readable: card status, subscriptions, serial number, PIN entry and service items are available straight from the hardware screen — the same as the module would show on a television screen. The module passport appeared there as well — manufacturer, product code and EN 50221 application type — and the node decodes the module name, so Cyrillic names no longer arrive garbled (Module menu).

  • Descrambling by a separate CI module — a module in a standalone card reader serves any input of a stream, not only reception from a DVB card: the whole transport of the input passes through it, while the list of programs only states which of them to descramble. The slot is assigned on the input itself, and it is there that one sees which input holds it (CI/CAM on a stream input).

  • Several CI slots on one input — a multiplex is passed through several modules in sequence, with its own set of programs for each slot. The clock rate of the CI bus is chosen from the actual bitrate of the input, and a slot left taken is released on request from the hardware screen.

  • Service tables on demultiplexing — the network and time tables and the other service PIDs of the source multiplex now obey the same keys mpegts-filter-nit, mpegts-filter-tdt, mpegts-filter-unnecessary and mpegts-filter-cat as on the other paths, instead of being discarded unconditionally. The default has changed with this: a stream extracted from a multiplex carries the network and time tables it did not carry before — a receiver behind such a stream, and a CI module first of all, expects to see them. The former behaviour is brought back by mpegts-filter-nit.

  • A PCR discontinuity no longer flushes the jitter buffer — an input that has caught a forward PCR jump moves the synchronization point on the fly, without draining the queue, so the discontinuity costs a single hitch instead of refilling the buffer. The window beyond which a jump counts as a discontinuity is chosen automatically (Synchronization).

  • Fast start of an HLS input — a live playlist is picked up from its tail: only the last segments needed for the configured jitter go into the queue, not the whole window, so the input goes on air with a delay of a couple of segments instead of an entire playlist window. A finished playlist (VOD) is still played from the beginning.

  • Suppression of alert flapping — an alert that is raised and cleared over and over is folded into a single incident: the node holds it through the lull and closes it only once the flapping has genuinely stopped. A storm of repetitions spreads neither through the log nor through the external channels. A flapping source, once recognized, stays recognized after the lull: its next series is held from the very first repetition.

  • Editing an EPG channel — a channel is given an XMLTV identifier separate from the display name, together with names per language, and a channel no longer needed is deleted outright: its names, its events and its membership of sets go with it.

  • Other improvements and bug fixes.

version 2.0.2.335 Beta

27.08.2026

  • Meshwork (multi-domain) — several servers are joined into named domains, and a domain serves as an isolation boundary: node membership, the resource catalog and alerts propagate only within their own domain, and nothing is passed between domains. A node may belong to several domains at once without mixing their data. For details, see Meshwork.

  • Node auto-discovery — it is sufficient to set the domain and a single entry point: the nodes exchange neighbor lists and build up a full mesh of direct links on their own. The shared domain key is derived automatically and is transferred only over a protected channel — TLS or a trusted local network segment.

  • Distributed resource library — UDP, RTP, Pro-MPEG and RIST outputs, UDP, RTP and RIST multicast inputs, and also PS1 and SRT links are published in the shared catalog of the domain (/data/library): a single list of multicast groups, ports, VLANs, SSM sources and point-to-point links with the node and the stream indicated. The catalog shows which addresses and ports are already taken, and a new input is connected directly from it — by picking a stream already delivered on another node of the domain, without entering the address manually.

  • Domain node overview — for every node the status, the time of the last contact, the role, the region, the build version, the uptime since start, the CPU load, the traffic per physical interface and the number of on-air streams are shown, and for every inter-node PS1 or SRT link — the bitrate, the RTT, the share of retransmissions and losses and a verdict on its condition. A node that has gone down does not disappear from the list: it stays there as unreachable, together with its alert, for seven days, and one that has been decommissioned is taken out of the overview by a command of its own.

  • Operation behind NAT — a node behind NAT takes part in the domain in full and without forwarding inbound ports: it connects on its own, its public access point is derived from the actually observed address and the announced port, and its state is relayed by the neighbors one hop further — the node is visible even to those that cannot reach it directly.

  • The node name from the certificate — a node with no host name configured announces to its peers the name covered by its own certificate, and only after that name resolves back to it; the result of the check is visible in the server data as cert-host and cert-host-refused.

  • Auto-login of links inside a domain — PS1 and SRT links between nodes of the same domain no longer require a login and password to be created for every link: on the calling side (PS1 input, SRT input, SRT output in caller mode) it is enough to enable the “Meshwork peer auth” setting, and authorization is performed with the shared domain secret. The confirmed peer node and its stream are shown in the resource library and in the session list.

  • Low-Latency HLS and MPEG-DASH over CMAF — a new delivery mode, “OTT / LL-HLS / DASH”: the built-in multiplexer produces fragmented MP4 (CMAF), on top of which MPEG-DASH is served at /dash and Low-Latency HLS at /llhls; adaptive bundles are assembled for these formats as well. For details, see Delivery modes.

  • LL-HLS low latency — the media playlist is split into parts, blocking playlist reload and the preload hint are applied, so the player starts playback without waiting for a complete segment to be ready. CMAF segments carry Producer Reference Time, the DASH manifest advertises UTCTiming and the target latency, and the “LL part target duration (ms)” setting is applied on the fly, without restarting the stream.

  • HTTP/3 (QUIC) — HLS, MPEG-DASH, LL-HLS and MPEG-TS over HTTP are delivered over QUIC on a UDP port of their own, with optional 0-RTT; the client asks to move to QUIC with the ?h3 parameter. QUIC only works over TLS: with TLS off the listener is not raised and is not offered to the client, and the actual state of the listener is visible in the HTTP-server data rather than only in the setting. The administrative routes stay on TCP only.

  • Segment alignment to IDR — the segmenter distinguishes an IDR frame from an ordinary I-frame: on closed-GOP sources every segment starts with a full entry point, so the player can open the stream at any segment; on open-GOP sources the nearest I-frame serves as the boundary.

  • Content protection (DRM) — the OTT delivery of a stream can be encrypted: HLS AES-128 with a key from the server itself or from an external key server and with optional rotation by time windows, or MPEG Common Encryption (ISO/IEC 23001-7) with the cenc and cbcs schemes for CMAF and DASH. Encryption is performed once, at the moment the segment is produced, so the DVR archive is stored encrypted and survives any number of key rotations. For details, see Content protection (DRM).

  • Every MPEG-TS over HTTP connection is a session of its own — the stream’s client list now has one row per connection with its own sess-id, the details are available at /data/stream/http-clients/<sess-id>, a single connection is closed with POST /data/kick?sess-id=<id>, and the max-conn limit is honored for values above one as well.

  • DVR (network archive) — every OTT channel is written to disk in parallel with delivery, with the same segmentation and without a separate recorder; in low-latency mode the archive is kept in two lines, MPEG-TS and CMAF, so the recording is available in the same container as the live broadcast. For details, see DVR.

  • Archive playback (VOD) — the archive is served over the same HLS, DASH and LL-HLS URLs as the live broadcast: t=<time> switches on VOD mode and sets the start of the window, d=<seconds> sets its duration. The HLS playlist is then closed, the DASH manifest is static and the recording gaps are presented as separate periods; adaptive bundles play the archive back with the same parameters.

  • EPG-based catch-up — instead of t and d it is enough to pass epg=<time>: the server itself finds the programme running at that moment on the bound EPG channel and takes its start and duration as the boundaries of the playback window.

  • Subtitles in the archive — WebVTT tracks are written to disk together with the segments and are played back in VOD over the same URLs; windows with no cues take up no disk space.

  • DVR storages — there may be several storages, each with its own fill limit and its own cleanup order. The archive depth (“Retention (hours)”, up to 90 days) and the protected floor are set separately for every stream, and the cleanup by free space touches neither the protected floor nor the windows of open VOD sessions.

  • DVR monitor — a dedicated screen shows the state and the fill of the storages, the size and the depth of the archive per stream and the read and write latencies, while the coverage histogram (/data/dvrstat) marks not only the gaps in the archive but also their cause — an input loss, a PMT change, scrambling, a cleanup run. The archive of an individual stream and the directories of deleted streams are erased from the same screen.

  • An archive disk failure no longer stops the node — an error servicing the DVR archive is confined to the storage and the step where it arose: the other streams and the other recording lines carry on, and the affected archive is marked as needing a rebuild.

  • Alerter — a new alerting service: every failure becomes an incident that is raised, updated and cleared automatically, while the deduplicated active set shows only what is happening now. Severity is set on a single scale — from information to requires administrator action; such an incident is cleared by an operator acknowledgement. For details, see Alerts (alerter).

  • Alert code catalog — more than fifty incident types in a single list: streams and their inputs and outputs, TR 101 290 violations, node resources, DVR storages and recording health, DVB and CI/CAM reception, transcoders, OTT, certificates and domain nodes. The trigger thresholds are configured in the alerts section.

  • External alert delivery — alerts leave the web console: by email over SMTP (STARTTLS, implicit TLS, AUTH), by a message to Telegram and by running an arbitrary command, to which the incident is passed in environment variables and as full JSON on standard input. Each channel has its own switch and its own severity threshold.

  • Domain-wide alerts — the operator on duty sees the alerts of any node from any other one: the active set propagates together with the keep-alive and is cleared as soon as it disappears at the source, and every row indicates the source node. Hardware and system alerts remain local by default and are promoted to domain-wide with a separate setting.

  • Log in a database — the service messages are written to SQLite: typed records with a source and a severity level, collapsing of consecutive repeats into a single row with a counter, retention limited by age and by size. Unlike the active alert set, the log survives a restart.

  • A master switch for notifications — with enable off in the alerter settings the node raises no alerts of its own and sends nothing outward, including the alerts received from its peers in the domain; only the peers’ alerts distributed across the domain remain in the list and in the event stream.

  • The severity of an I/O alert follows the consequences — an input that fails while it is not carrying the stream is marked Error, while a carrying input, any output and a failure with nothing on air are marked Critical; the assessment is recalculated while the alert is open and follows a switch to the backup.

  • Color in external notifications — a color marker for the level has been added to the message text (red for errors, yellow for warnings, green for a clear, blue for informational), and the mail goes out in two variants at once: plain text and HTML with a colored bar.

  • Telegram notifications survive a storm — the accumulated alerts are combined into the smallest number of messages the 4096-character limit allows, and on a rate-limit reply the node waits out the time it was given and repeats the send instead of dropping the notification.

  • The notification delay now covers the backup input — the warning that a stream is running on its backup input is raised only if the situation has lasted longer than alert-delay, so a source that recovers and fails again no longer produces a run of raises and clears; with alert-delay at zero the behavior is as before.

  • TR 101 290 monitor — continuous monitoring of the conformance of the input stream to the standard: a single verdict (“OK”, “Problem”, “Checking…”) and a structured report by priorities 1, 2 and 3, where the clause of the standard, the measured value and the limit are given for every indicator. An MPTS multiplex is evaluated as a whole — across all PIDs, programs and SI tables. The stream is automatically classified as CBR or VBR, and the checks that are meaningful only at a constant bitrate are not evaluated on a VBR source and produce no false triggers. For details, see TR 101 290 monitor.

  • Reference clock drift — the systematic divergence of the source clock frequency is measured by linear regression in ppm against the ISO/IEC 13818-1 tolerance of ±30 ppm and is reported as a separate metric. A slow divergence is handled by smooth micro-shifts of the synchronization point (“Sync drift compensation”, enabled by default), so there are no jumps at the output.

  • T-STD buffer model — analysis of the video buffer of the reference decoder per ISO/IEC 13818-1 with overflow and underflow counters for MPEG-2, H.264 and HEVC; the timing is taken from the PCR clock, and the drain rate follows the actual video bitrate. Switched on with the “Analyze T-STD video buffer” setting.

  • Ad insertion analysis — parsing of SCTE-35 sections with splice events, transport-layer splice points with a configurable advance notification and random access indicators. The data is shown in the stream statistics when deep analysis is enabled.

  • Complaint assistant — for a stream with persistent violations a ready-made text prompt for an AI chat is produced, from which the chat composes a formal complaint letter to the stream provider: the list of persistent violations, the measured values, the clauses of the standard and the impact on the decoder. The prompt is served by the GET /data/stream/<id>/ai-complaint-prompt request; the stream name and the source address are not included in the text.

  • CI/CAM (EN 50221) — a built-in Common Interface host: detection of the module, reading its name and the list of supported CA_system_id values, selection of the programs to descramble and delivery of CA_PMT for each of them. A module combined with the DVB receiver descrambles the selected programs of the received multiplex inline, several of them at a time; the state of the slots and the verdict for every program are visible in the interface.

  • Software BISS-1 / BISS-E descrambler — applied not only to reception from a DVB card but to any stream input: the key is set for the whole SPTS or per program of the multiplex and is changed on the fly, without restarting the input. On reception from a DVB card the result is additionally verified against the stream itself, so a wrong key does not look like successful descrambling but raises a dedicated alert.

  • Conditional access cleanup on DVB reception — a separate adapter setting removes the ECM and EMM PIDs from a multiplex received by a DVB card, and the CA descriptors of the cleared programs from the PMT: a clean FTA stream goes further down the path. When the key is lost, the conditional access signalling is restored so that a receiver further down the chain can request access again.

  • Transcoder telemetry — for every encoder the media information of the transcoded output is published: the frame format, the video codec, the set of audio codecs and the current bitrate, and for every process — the CPU load and the memory occupied.

  • RTMP and RTMPS — a channel is published to any RTMP receiver, including YouTube and Facebook: H.264 or HEVC video (HEVC through Enhanced RTMP) and a single AAC track; for rtmps:// the node connects as a TLS client. In the opposite direction the input pulls the stream from an rtmp:// or rtmps:// source itself and remultiplexes FLV into MPEG-TS.

  • Seamless source switchover — when the active input is changed on the transmitter, the receiving PS1 peers do not reconnect: the numbering and the timestamps remain continuous, a queue burst is absorbed by dropping the oldest packets, and the gap is filled in by the regular retransmission.

  • Adaptive PS1 retransmission — the receiver measures the actual RTT to the transmitter and adjusts the repeat request intervals to it on its own; the measured RTT, the current re-request interval and the indication of an insufficient latency are reported in the link statistics. The latency of the receiving tunnel is set directly in milliseconds instead of the former multiple of the RTT.

  • The “Reconnecting” and “Administrator action” states — an input or output that has lost its source is reopened in place and stays in the “Reconnecting” state for the whole time of the attempts, raising one warning per episode instead of a message on every attempt. A cause that a retry cannot resolve — a busy port, a missing interface, data that is not MPEG-TS, an SRT failure on encryption — puts the input or output into the “Administrator action” state with a sticky alert, while an edit of the settings is applied immediately.

  • The date of the last error — the time of the last error of an input or an output is published next to its text (last-error-ts, the same field is in the event stream too), so an old cause left on a paused input is visible separately from the current failure.

  • A diagnosis when the input carries unusable content — the message about a loss of MPEG-TS synchronization names the likely cause: packets were found but are offset by a known number of bytes, or there is no MPEG-TS structure at all; for PS1 and Pro-MPEG inputs a hint about the encryption passphrase is added.

  • The actual size of the receive buffer — the input publishes socket-buffer-actual, the size the kernel granted, whereas socket-buffer-size remains only a request and is trimmed by the system limit; the discrepancy is therefore visible at once instead of showing up as losses at a high bitrate.

  • MPTS multiplexer: original identity — the programs can keep their original PIDs, and the order of the programs in the PAT, SDT and NIT is set manually, so a multiplex is migrated to Perfect Streamer without changing the stream identity for the receiving equipment. Programs with TS scrambling are migrated with their original timestamps.

  • Automatic PID numbering for SPTSenable-autopid together with autopid-base moves the whole program into a predictable window of 64 identifiers, starting with the PMT and then the video, the audio and the remaining elementary streams in the order of the source table; a program that does not fit the window keeps its original PIDs in full.

  • The datagram size can be set on every output — the packets setting now applies not only on SRT but on the UDP, RTP, Pro-MPEG and RIST outputs as well, and on output to a file and to the standard stream it sets the size of the block written. The defaults match the previous behavior, so a configuration in which the key was never set does not change; a stored value other than the default was ignored by earlier builds and now takes effect on the very first restart — check it before upgrading.

  • Integration with external billing — every viewer session is authorized in an external billing or CRM system, is held by periodic re-authorization and is reported to the same system when it ends: a RADIUS-style Start / Interim / Stop lifecycle, and a subscription revocation drops the session mid-viewing. OTT, PS1 peering and SRT outputs are covered, and the billing system itself is connected with request and response parsing templates, without any software modification.

  • Built-in ACME client (Let’s Encrypt) — issuance and automatic renewal of the certificates for the web server, the HTTP/OTT server and the EPG server: a certificate is ordered for every configured host name, the renewal is checked daily, and an alert is raised on failure. An arbitrary certificate authority and external account binding are supported, and a new certificate is applied without restarting the service.

  • Fast shutdown of the service — stopping no longer waits for a client that has stopped reading data: under the same load the node finishes in 2–4 seconds instead of about a minute, so a restart takes seconds and does not leave the air without a broadcast.

  • pss_lic 2.0 — the command-line licence utility has moved to the commands apply, c2v, fingerprint, recipient, keys, detach, rehost and cancel with long options: it applies a licence update that has been sent to you, exports the state of the key for the supplier and moves the licence from node to node, temporarily as well, and it accepts any file on standard input and writes to standard output. In detail — pss_lic.

  • Editing the configuration file by hand — a JSON Schema for pss.json (strict and compatible) is published with the documentation, together with a step-by-step guide to editing and carrying the file: the configuration of a stopped node may now be edited directly and carried between installations and versions once the result has been checked against the schema, whereas previously the HTTP API was the only supported way. In detail — The pss.json settings file.

  • New web interface — node management has moved to a new console, which is opened at the node address (the /admin path): the overview, streams, system monitoring, DVB, DVR, transcoders, clients, the log, alerts and all server settings. Dedicated diagrams show the topology of the Meshwork domain and the path of the selected stream from the inputs to the outputs. The former interface is preserved at /classic. For details, see Web interface.

  • Single sign-on across the domain — an account can be allowed to sign in automatically: after one password sign-in the browser opens this node’s panel without the sign-in form for 14 days, and survives a restart. Following a link from that panel hands the session over to a neighboring node of the domain if the hand-off conditions are met (Web server & accounts); an address of a neighbor typed by hand carries no session. A script or a third-party panel presents the same key in the X-Auth-Token header or the auth-token parameter, and an administrator revokes the automatic sign-in across the whole domain at once.

  • CORS for the administrative API — the nodes of one Meshwork domain are allowed without any configuration, the remaining origins are listed in web-server/cors-origin (the value * allows any origin, none turns the mechanism off), so the interface of one node reaches the API of another; a cross-domain request must carry the token explicitly — a cookie and Digest do not work in it.

  • The token of your own sessionGET /data/auth-token returns the client its own token and the absolute expiry, and the field web-login-expires has been added to /data/server, so the interface shows until when the sign-in is valid without reading the token itself.

  • Ending an auto-login sessionPOST /data/auth-tokens/revoke?login=<login> closes every live session of an account, and ?id=<hex> closes one by the identifier from the session list; the reply carries the number of sessions closed, and the revocation spreads across the whole domain.

  • The reason a jump to a neighboring node was refused — if the jump did not produce an automatic sign-in, the node returns a jump parameter in the address with the value no-session, foreign-domain, autologin-off or token-refused, instead of silently showing the password form.

  • Real-time updates — the node publishes its state as an event stream at /data/events: on connection a full snapshot arrives, after which the frames of the streams, the system resources, the clients and the DVB adapters are updated once a second, while alerts and state changes arrive as events. The interface and external dashboards work without periodic polling.

  • Context-sensitive help — every screen and every important window of the new interface is provided with a help call that opens the documentation section for exactly what is open at the moment: the common help button for the screen, the “?” button in the window header for that window. The section opens in the language of the interface.

  • Languages, themes and layouts — the interface is translated into six languages (Russian, English, German, French, Spanish, Portuguese), supports a light and a dark theme and adapts the layout density on its own to a phone, a tablet, a workstation and a video wall.

  • Access with no limit on the number of connections — the receiver’s connection limits have gained a third state, “No limit”, alongside “Protocol forbidden” and “At most” with a number; unlimited access used to be represented by a deliberately large number. Zero still means the protocol is forbidden, so the meaning of the saved settings does not change after the update. In detail — User: add and edit.

  • Editing stream access no longer disturbs unrelated sessions — adding a stream to the allowed list and going back to an empty list break no session at all, while narrowing the list closes the PS1 and SRT sessions only on the streams that have left it. Previously any edit of the list disconnected the account entirely on all protocols.

  • License activation from the web interface — the “License” screen has gained an “Activation” section: the export of the key state for the supplier — as a C2V file or to the clipboard — and the application of the V2C key that has been sent, as a file or by pasting the text. Applying the key restarts the node. In detail — License.

  • Warning about license expiry — the node raises an alert two weeks before the end of the term and escalates it to the level that requires intervention once the term has run out. The alert is replicated across the domain, so a neighbour’s expiring license is visible from any node (Alerts (alerter)).

  • A licence found not to be genuine stops the node — a node whose licence is found not to be genuine raises an alert that requires administrator action, restarts the service, and the start is refused: the service stays stopped until a genuine licence is present on the node. The alert is replicated across the domain (Alerts (alerter)).

  • Fallback to the last working configuration — the node keeps a copy of the settings it last started cleanly with, and when pss.json is unacceptable it comes up on that copy — with all of its streams, rather than on the default settings, which contain no streams. The archive of rejected files has been put in order: names in UTC, a numeric suffix instead of overwriting when two failures fall in the same second, the twenty most recent copies; the alert names the path of the archived copy outright. In detail — Behavior at startup and on configuration errors.

  • Input priority is edited with the mouse and from the keyboard — an administrator can reorder the inputs of a stream by dragging or with Alt+↑ and Alt+↓, on the “Inputs” tab of the editor and in the expanded row of the stream list (on a phone the order is only displayed); an added input always goes last and never takes the place of the main one (Streams).

  • An input’s number is its place in the redundancy list — one and the same number now appears in the stream row, in the expanded row, in the editor and in the text of the alert. Inputs with equal priority values keep the order in which they are written, through later edits of the settings as well (Source redundancy).

  • The failure of an abandoned input reads as history — the input the stream left for a backup is stopped but keeps its reason: the interface shows it as a dimmed line with an age, not as a current failure, and the alert about that input’s error is cleared. The reason is the input’s own, transport-level one, if the input managed to report it itself (Source redundancy).

  • Sorting the client list — on the “Clients” screen a column header sorts the list: numeric columns open in descending order, text ones from A to Z, and a third click restores the node’s order. The whole list found is sorted, not the page on display (Clients).

  • Jumping to a stream from the transcoders screen — the row of the decoder and of every encoder has gained a button that opens the stream list on the stream in question. Available in any role (Transcoders).

  • The demultiplexer program is picked from a list for a DVB adapter too — a running adapter publishes its multiplex, and the “PNR” field offers its programs by name, including the inner T2-MI programs under their composite numbers (Demultiplexer (demuxer)). The adapter of a dvb input is likewise picked by name rather than typed in as a record number (DVB adapter (dvb)).

  • DVB reception no longer depends on the build — the dvb input type and the DVB adapters section are available on any node; the only condition is a detected frontend and a driver that lets the service open it (DVB receiver).

  • The DVB scanner yields the tuner to a configured adapter — a multiplex that has been found can be applied without waiting for the pass to end: the adapter takes the tuner and comes up in about a second, while the scan ends as cancelled and keeps its results on screen. A pass is stopped with the “Stop” button and by closing the window (Scanning).

  • Node overview panels follow the presence of the subsystem — “Transcoders” and “DVB adapters” appear on the overview where the hardware or the instances exist, or where there is a failure to report. On a node without transcoders and without a tuner these panels are absent, and so is the way into their sections from the overview (Node overview).

  • Interface addresses in the system monitor — the “Network” card and the history graphs are labelled with the interface’s IPv4 address whenever the node reports it, nested VLANs included (System Monitor).

  • A DVR storage path is written without a trailing separator — the interface and the HTTP API reject such a value: two spellings of one directory would pass the uniqueness check as two different storages (DVR storages).

  • The package needs protection service 10.33 or newerpstreamer ships the new-generation libraries of the protection system, and an older aksusbd does not accept them (System requirements). The service lives in the same repository and is installed together with the package, but upgrading it is irreversible, whatever the key type — the procedure and its consequences are described on the installation pages (Installation on RHEL-family systems, Installation on Debian-family systems).

  • Explicit PLP selection on DVB-T2 — the “Stream id (ISI/PLP)” field has gained an “auto” value (-1): no filter is applied, the tuner takes the driver’s default stream, and a new adapter is created exactly like that. An explicit zero has thereby become a real selection of stream zero rather than “not set”, so an adapter with zero saved in its settings will, after the node is upgraded, receive only that stream (Adapters).

  • The scanner finds PLPs — the “Probe PLP up to” field sweeps the PLPs on DVB-T2 transponders and lists every one found as a separate row with its own program list; the number is carried into the adapter that is created, and the adapter statistics have gained a “PLP / ISI” line (Scanning).

  • Search in the scanner catalogs — hundreds of satellites and regional bands are sorted by name and filtered by a search string; a row already selected never disappears from the list, whatever is typed (DVB scan).

  • Fixing the PCR reference in the PMT — a new MPEG-TS setting for sources whose table declares no usable PCR: the node declares in the PMT the PID on which the PCR is actually carried (Stream modification).

  • Rebuilding the jitter buffer after a source dip — an input that has survived a stall of its source no longer carries on with an almost empty queue, passing every subsequent hiccup on to the outputs: the node rebuilds the buffer once, at the cost of a single break (Synchronization).

  • Video encoder bitrate control mode — the transcoder has gained a choice between a constant rate and two variable modes: the number given is read either as the average bitrate (peaks reach one and a half times that) or as a hard ceiling (the average rate then comes to two thirds of it). There is still only one number — the encoder derives the second limit itself from a fixed peak-to-average ratio of 1.5. In the variable modes the encoder stops padding the elementary stream, so bandwidth is saved only where the receiving stream does not level the bitrate back up (Encoder settings).

  • A transcoder restart is explained in the log — every restart of the child process names its reason and its exit code at the “Notice” level, instead of silently in the trace. Besides that, the node has stopped reopening an unresponsive channel indefinitely: after two failed attempts it asks for a new process (Monitoring).

  • A deleted stream is visible in an open editor — if a stream is deleted from the node while its editor or its processing diagram is open, the node reports this on a line of its own, and saving becomes unavailable with the same reason stated next to the button. Previously all the lists of such a stream simply emptied, which looked like a stream with no inputs and outputs configured (Configure stream).

  • A refused save names its reason — instead of one blanket phrase for every case, the form reports what exactly got in the way: a response timeout, a role restriction, or the node’s own refusal in the node’s own words.

  • PID labels and PID selection in the filtering rules — every number is labelled with its kind and codec and, on a multiplex, with the program it belongs to as well; the add row has gained a list of the PIDs the source actually carries. Manual entry remains: the transport may carry a PID about which nothing has been decoded (Input and output editor).

  • The DVB screens show the addressable program number — for a service inside a T2-MI carrier, the adapter’s program list and its statistics carry the composite PNR, the very one by which the program is addressed in the demultiplexer, BISS and CAM selectors. Its own number inside the carrier repeats on every carrier of a transponder with mirrored groups and points to nothing (Adapter statistics).

  • A BISS slot is always offered as a list — clear programs have been added to it last, marked · clear ·, so on a multiplex without a single encrypted program the list is no longer empty: a key is often entered in advance, and an event feed is in the clear between events (Descrambling).

  • From stream statistics to the transcoder and to its source — if the active input of a stream was created by a transcoder, its value has become a link to the transcoders screen with the row of the relevant instance expanded, and a badge with the name of the stream that instance decodes has appeared beside it. Both links are available in any role (Stream statistics).

  • Run boundaries in the log — every start of the service is marked in the feed by a line of its own carrying the moment of the start and the build the run came up on: the current run has its uptime beside it, past ones show how long the run worked and how long the node stood idle before the next start, and a run that ended without a proper stop is marked out. The separator is placed even when the severity filter is on (Logs).

  • A size limit for the statistics database — the metrics database is bounded not only by the retention window but also by size. The node reports on the last cleanup — how much history is left, how large the database is and how long the cleanup took — and states outright when the size limit has turned out to be stricter than the configured window (Server Settings).

  • Values clamped at load time are announced at once — if the node, while reading the settings, pulled a value to the nearest allowed limit, it says so on screen right after the start and not merely on a line in the log (Behavior at startup and on configuration errors).

  • A licence of an obsolete generation is not accepted — a node with a genuine licence of the previous generation does not start and raises an alert of its own. This is neither an expired term nor a forgery: generation 2 is accepted only as a temporary trial licence, so a perpetual licence of that generation is rejected outright instead of living until its date (Alert code catalog).

  • Automatic padding computes its target from the content — in the automatic bitrate mode the node works from the actual rate of the content rather than from its own output, so the target no longer creeps upwards without coming back and drops again as soon as the content fits within the configured rate (Bitrate control).

  • The drift compensation window is proportional to the buffer — the soft window is capped at a quarter of the target jitter buffer size, but never below 100 ms: an input with the standard buffer no longer runs without headroom, compensation pulls the synchronisation back sooner, and the emergency rebuild of the buffer on depletion finally fires (Synchronization).

  • Other improvements and bug fixes.