Version history

version 2.0.2.423

26.10.2026

• Demo edition — a free edition for technical evaluation, the pstreamer-demo package: no protection key and no activation, no time limit, for evaluation only (commercial use is prohibited). Features and limits — Demo edition.

• Demo edition: the DVR field without an error — on the “OTT” tab of the stream editor, after the “OTT / HLS” mode is chosen, the “Could not load DVR storages” error no longer appears under the “DVR storage” field: the field only shows “Not available in the demo” (Comparison of editions).

• Update the transcoders together with the streamer — pstreamer-tcnv 1.2.0.128, pstreamer-tcsw 1.2.0.127 and pstreamer-tcivpl 1.1.0.56 or newer are needed: a transcoder of an earlier version may crash when the service stops, and the logo on the software transcoder needs the new version of tcsw. After updating the transcoders, restart the service (Files and installation verification).

• Service autostart on a package upgrade — upgrading the rpm package no longer disables the autostart of the pss service and no longer stops it: before, after such an upgrade and a server reboot the streamer did not start by itself. Now, including an upgrade from 2.0.2.408, autostart stays enabled and a running service is restarted on the new version; a service the administrator stopped or disabled stays that way. Upgrading the deb package no longer enables an autostart the administrator disabled. The pss system user is no longer deleted and created again on an upgrade. If an rpm installation was upgraded before, check autostart with systemctl is-enabled pss and, if the answer is disabled, enable it: sudo systemctl enable pss (Installation on RHEL-family systems).

• OTT, DVR and DRM settings without a break in broadcasting — saving the OTT, DVR and DRM settings of a running stream restarts only OTT delivery and archive recording: the inputs and outputs (UDP, SRT and others) keep working without a break, and the stream’s uptime is not reset. Before, any such change restarted all inputs and outputs of the stream, and the outputs had a short break. The archive depth and the LL part target duration are applied on the fly, without a restart. Settings that change the transport stream itself (service name, programme, PID filters, PAT/PMT/PCR fixes, EPG source) restart the inputs and outputs, as before (OTT and DVR).

• Cloning streams — in the web interface a stream, or several selected streams, can be copied together with their inputs and outputs: the copy is created paused, with the -copy suffix in its name, and the summary lists the ports and addresses that coincide with the source stream (Cloning streams).

• Signing in to the web interface without the browser dialog — when the web interface is opened from another computer, the browser no longer shows its own sign-in dialog before the web interface form. An API request to a /data/… path with the X-Requested-With: XMLHttpRequest header gets 401 without a Digest challenge when refused; scripts that sign in with Digest should not send this header (Sign in, Access).

• Complaint assistant in the web interface — while an SPTS stream has an active TR 101 290 violation or PCR drift, the “AI letter” icon is shown in the stream row and in the statistics window: it opens a ready-made prompt for an AI chat, which will compose a letter of complaint to the provider. The prompt is available to the Admin role only, the letter is always in English (the language choice has been removed), and only the input address of the source goes into the prompt, without logins, passwords or keys. Without an active violation the node does not generate the prompt (Complaint assistant).

• Panning the zoomed mosaic frame — in the original frame window the zoomed picture can be moved with the mouse while the right button is held down, and on a phone or a tablet it can be zoomed with a pinch and moved with a finger (Original frame).

• Adaptive bundle OTT name without spaces — the “OTT name” field of an adaptive bundle no longer accepts spaces: they broke playback and the playlist export. The streamer strips them too — when a bundle is added or changed through the API and when the settings are loaded (with a log entry); the cleaned name is written on the next save. If two bundles’ names coincide once the spaces are removed, the settings are still loaded: the second name is not served and a warning is written to the log (previously such settings did not load) (Adaptive bundle).

• M3U export: adaptive bundles and DASH — adaptive bundles are now exported to the playlist too: the bundle’s HLS master playlist and DASH manifest, each while at least one stream of the bundle serves it. The “All active” option adds all running bundles after the streams, and the new DASH protocol includes the bundle manifests and the streams in DASH mode. Previously, selected bundles could not be exported (M3U export and import).

• Logo overlay in the transcoder — a logo from a PNG file can be overlaid on the outputs of an NVIDIA transcoder and of the software transcoder (CPU): each output has its own file, position, opacity and background blur under the logo. The logo is not scaled; the web interface checks at once whether it fits into the output frame and shows a preview to scale. Logo files are uploaded in the web interface and stored on the node. The backend of a decoder with a logo can be switched between NVIDIA and software; with the same size settings their frames can differ by a few pixels, and the logo must fit into the frame of the selected backend. Intel has no logo (Logo overlay).

• Fast stop and restart — transcoders, the external commands of std inputs and outputs, and the alert command exit together with the service, and during a stop the node no longer restarts transcoders. Previously they did not react to the stop signal, and stopping or restarting the service waited until the system terminated them forcibly, usually about 15 seconds.

• Transcoder statistics — the decoder queue and the latency no longer freeze after the node has restarted the transcoder.

• Alerts in groups — the “Alerts” screen by default groups the active alerts by node and by code, with the number of rows and the highest severity in the group header; large groups open collapsed. The “sticky resync” and “backup input” tags set resync recommendations and backup input errors apart from current outages. The former list is available with the “Flat” switch (Alerts).

• Alerts without flapping — a node resource alert (CPU, memory, network, GPU, GPU video memory, DVR storage, worker threads of DVB adapters) is raised only when the value stays beyond the threshold for 30 seconds, and cleared after 60 seconds below the threshold. The stream’s continuity counter error alert (code 15) is raised only when the losses go on for 30 seconds and clears after 60 seconds without losses; the error level is held until the number of errors drops below half the threshold. Previously a load jumping across the threshold and single lost packets produced alerts that appeared and disappeared within seconds. The times are set on the “Alerter” screen (the system-alert-raise-sec, system-alert-clear-sec, stream-cc-raise-sec and stream-cc-clear-sec parameters of the alerter section); 0 restores the previous behaviour (Alerter settings).

• GPU video memory fill alert — a new code 64 alert for each NVIDIA card: a warning when the video memory is 85% full, an error at 95% (the “GPU video memory” row of the “Alerter” screen, the gpu-mem-warning-pct and gpu-mem-error-pct parameters; 0 turns a level off). A card with full video memory does not start a new transcoder channel, even though its load may look normal. There is no such alert for Intel GPUs. The system monitor data (/data/sysmon) show the used and total video memory and the fill percentage for each NVIDIA card, and the system monitor of the web interface shows a “Video memory” bar; the former “Memory” bar of an NVIDIA card is now called “Memory bandwidth”. With system alert replication on, nodes of earlier versions in the same domain show this alert without a name until they are upgraded (Alert code catalogue).

• Faulty backup — in a single alert — the new code 65 alert (“warning” level, one per stream) lists the inputs that are in error while the stream runs through another input. Such inputs no longer hold their own code 1 rows, and code 1 is now always critical: the stream has lost its source. An external destination receives the clearing of the code 1 rows and the raising of code 65 instead of the former “critical” → “error” update. It is configured in the “Backup inputs (code 65)” block of the “Alerter” screen (Alert code catalogue).

• Quieter resynchronisation alerts — the code 61 alert (a PCR break without loss) is now informational and off by default; its threshold is a separate key stream-sync-absorbed-count. Codes 58, 59 and 61 clear after two hours below the threshold instead of six hours without a single event, and the row of an input the stream has switched away from is cleared at once. The thresholds and the number of quiet hours are set in the new “Input re-sync (codes 58, 59, 61)” block of the “Alerter” screen (Alert code catalogue).

• ACME alert clears itself — the alert about a certificate issuance error caused by a problem on the node (no HTTPS server with the host name, the HTTP-01 validation port is busy, the account key) clears after the first attempt that gets past that step; previously it held until automatic issuance was turned off (Alert code catalogue).

• External alerts: raise and clear as a pair — the minimum severity threshold of the “Process”, Telegram and e-mail channels applies to the incident, not to each message. An incident whose severity rose to the threshold is reported at the moment of the rise, and the clear always arrives when the raise was reported. Before, when the severity changed relative to the threshold, a clear arrived without a raise or a raise without a clear (When the script runs).

• Alert scripts and stderr — the script’s standard error is read while the script runs: heavy output to stderr no longer leads to a timeout, and a process left in the background does not hold up the next alerts. Only a non-zero exit code counts as a delivery error; the last 4 KB of stderr go to the log (Result, timeout and log).

• Meshwork: protection of the exchange between nodes — a node checks that a response from a neighbour is signed with the same secret or domain key, that is, that it came from a genuine member of the network, and refuses a neighbour’s message that was recorded earlier and sent again, as well as a message addressed to another node. The domain key travels encrypted: a recorded exchange replayed later does not obtain it. Before, whoever answered the connection (an intercepted link over HTTP, or TLS without certificate verification) could substitute node data, sign-in sessions and the domain key. Nothing needs to be configured (Neighbours and secrets).

• Meshwork: node clocks must be synchronised — a node whose clock differs from a neighbour’s by more than 5 minutes is refused by that neighbour, and the link is shown as unavailable. Both nodes write a warning to the log with the neighbour’s name and the size of the difference; the first warning appears already at half the tolerance. The tolerance is set by a new optional parameter, cluster-hello-window-sec (300 seconds by default, 0–86400); 0 turns the clock check off for nodes whose clocks cannot be synchronised, and replayed messages are refused even then. Before the upgrade, check that NTP is running on all nodes (Requirements and reachability).

• Meshwork upgrade and rollback — if possible, upgrade all nodes of the domain at once. If that is not possible, first upgrade the nodes the others connect to (central nodes and nodes with public addresses), then the nodes behind NAT. While nodes of different versions run in the domain, data exchange is limited, and messages of nodes of earlier versions can still be replayed. A node rolled back to an earlier version is refused by its neighbours on the new version until they restart: roll back the whole domain, or restart the new-version nodes after the rollback (Upgrading the domain’s nodes).

• Quieter on planned Meshwork node restarts — the unreachable-node alert (code 26) is raised after a minute of silence rather than after 15 seconds, so a quick restart of a neighbour does not wake the whole domain. A node that is stopped or restarted deliberately first warns its neighbours (nodes of earlier versions do not get the notice), and for 5 minutes they do not raise the alert for it, while the node table lists it as “Restarting (N s)”. The times are set by the fields of the “Meshwork contact (advanced)” block of the server settings (the cluster-node-down-sec and cluster-leave-grace-sec parameters of the cluster section, Alert code catalogue). Fixed: a node could show itself twice in the network and repeat its own alerts as if they came from a neighbour.

• Changing Meshwork settings — saving the settings no longer removes auto-discovered nodes from the network map and no longer clears their “a network node went silent” alerts by mistake (Alert code catalogue).

• Auto sign-in from another node of the domain — an auto sign-in session that arrives from another node of the domain gets the Viewer role on a node that has no such account. If the node has the account, its role applies, as before (Web server & accounts).

• External billing and neighbouring nodes — billing servers no longer receive a sign-in request from a neighbouring Meshwork node that the node has already rejected itself.

• Secrets in API responses and writing them back — the response to adding or changing a record through the API (POST to /config/…) no longer repeats passwords and other secrets, for the Admin role too: they come as ********; reading the settings (GET) has not changed. A secret or a command line sent in a write as ******** keeps the stored value, and so does an address hidden with the <hidden> trace: the response you got can be sent back without losing passwords. ******** itself can no longer be set as a password (Managing the node over the HTTP API).

• Addresses in responses for the Viewer and Restricted admin roles — in the /data/events event stream (the address of the stream’s active input and the error texts), in the event texts of /data/dbstat and in the reason from /data/cert/acme/status, logins, passwords and secret address parameters are hidden, as in the /data XML. Nothing changes for the Admin role.

• A rejected settings change changes nothing — if the node rejects a change to a stream, input, output or the server settings (for example, an invalid node name), the object stays as it was. Previously, the keys applied before the refusal remained in effect until a restart (How errors arrive).

• Database statistics without the missing tables — a /data/dbstat request with the missing=skip parameter skips the tables that do not exist instead of rejecting the whole request.

• Settings files no longer readable by other users — pss.json and its backup copies are readable only by the service user. The pss-metrics metrics exporter, when run as another user, connects to port 43971; if the web server uses another port, set PSS_URL, including in the /etc/pss-metrics.conf file. Fixed: the exporter connected to port 8808 if no web server port was set in pss.json, and ignored PSS_URL from that file (Files and services, Configuration).

• IP address accounts and IPv6 clients — a client connecting over IPv6 no longer causes an error when accounts are checked by IP address: such a client simply does not match IPv4 addresses (Users / Logins).

• Allowed streams of a local login — a login for which none of the streams in its “Allowed streams” list remains by the time the node starts gets no stream at all. Before, such a login could watch all streams (Users / Logins).

• Enabling and disabling the EPG server — “Enable EPG server” now controls both ports, HTTP and HTTPS, and takes effect at once, without a restart: a disabled server opens no port at all. Before, a disabled server still took its ports when the service started (connections hung), disabling it on the fly restarted the HTTP port, and the HTTPS port ignored the flag (XMLTV delivery).

• Full EPG export with mapping data — the new EPG server path /xmltv-src (and /xmltv-src.gz) returns the channels of all or selected sources with the data for mapping on-air channels: the source number and name, the channel identifier in the feed; you can export only the channel catalogue or add past days. Access — for an EPG server account with the “All channels on /xmltv-src” flag (all-channels) or from the node itself (Full export with mapping data, EPG Settings).

• Age rating in the programme schedule — the channel’s daily schedule in JSON for OTT middleware returns the programme’s age rating (the age and the rating system, for example 16+), taken from the XMLTV feed or from the DVB EIT parental rating; in the channel schedule in the web interface it is shown as a badge (Single-day schedule in JSON, EPG Database).

• Programme sub-title as a separate field — the sub-title from the XMLTV feed (<sub-title>, for example the episode name) in the language of the title or with no language given is returned in the channel’s daily JSON schedule as a separate sub field, and in the full /xmltv-src export as a <sub-title> element; the programme title there comes without the sub-title. The regular /xmltv delivery is unchanged. Sub-titles appear after the next update of each source (Single-day schedule in JSON).

• EPG fetching in turn — large feeds are fetched and processed one at a time while the others wait in the queue, and at service start the fetches are spread out in time: the memory peak when restarting with several large feeds is that of one feed. A failed fetch is retried after 2, 5 and 15 minutes, then every 30 minutes, rather than after the full update interval. In the web interface a queued source is marked, and the “Sources state” tab shows the “Next retry” and “Failed fetches in a row” fields (Fetch queue and retries, EPG Database).

• EPG source fetch timeout — the new “Fetch timeout, s” source parameter (fetch-timeout) for slow sources that build the file on request; 30 seconds by default, as before (Source configuration).

• EPG sources — on a change, “Source URL / path” must be an http or https address or an absolute path to a file; otherwise the change is rejected. A source’s Cookies are now really sent — in the standard Cookie header and only to the configured host; before, the header was named Cookies, and servers ignored it. After an enabled source is changed (for example, its address), the data is loaded at once rather than when the update interval expires (Source configuration).

• Deleting an EPG channel set — the contents of a set are deleted together with the set, and only if the deletion succeeded. Before, the contents of a set with no accounts stayed in the database, and a refused deletion of a set assigned to an account could erase its contents.

• EPG: programmes across midnight — a programme that runs across midnight (UTC) is shown in both days of the schedule, and its tag in the OTT playlist is found after midnight as well. Before, such a programme vanished from both days.

• Fixed: in the /xmltv export a programme could be repeated if two sources provide a channel with the same identifier; the programme schedule from stream EIT shows a changed programme at once, rather than its old text or rating.

• Fixed: “Auto-clean orphan channels” could delete the channels of an EPG source whose feed had not changed; programme changes in external sources are now recognised more reliably, and channel name edits made in the web interface are kept (EPG Database).

• EIT — the service no longer crashes while building the EIT from XMLTV when an event has two or more age ratings or a long description in Polish, Czech, Hungarian, Croatian or Bosnian: a text that is too long is split into several descriptors. A long description in Cyrillic and other non-Latin scripts is no longer split into one-byte fragments, the descriptors are numbered correctly, and an event with a long description keeps its parental rating (EIT generator).

• NIT — the node tracks the NIT version after a reset as well (before, the list of logical channel numbers could stay empty) and applies only the NIT of its own network (actual).

• Automatic service type — with Service type 0, an H.264 programme counts as HD (type 0x19) from level 3.1. Before, the threshold was level 3.0, and SD 576i/480i at that level was marked as HD; now it is SD (0x16) (Programme parameters).

• Multicast reception on the loopback interface — a UDP or RTP input with the interface lo or 127.0.0.1 joins the multicast group only on the loopback interface and receives a group sent from the same node. Previously, the input joined the group on an external interface and received nothing. To receive a group from the network, specify a network interface or leave the field empty (Input).

• Multicast group rejoin — for UDP, RTP and Pro-MPEG inputs the rejoin period is capped at 3600 seconds: the node does not accept a greater value and lowers it to 3600 at startup. Previously, a value greater than 4294 seconds made the input rejoin continuously. A failed attempt is now repeated after the period instead of stopping the rejoins until the input reconnects; a Pro-MPEG input also resubscribes its FEC streams (Input).

• Address check of UDP and RTP inputs — on a change, an address that is not an IPv4 address (for example, 999.999.1.1) is rejected with the message Incorrect IPv4 address. Settings saved earlier are not re-checked at startup (Input).

• RIST multicast input — joins the group on the interface from the Interface column; before, the default route was always used. On a RIST multicast output the interface still has no effect: the traffic leaves by the system route to the group (The list of peers).

• RIST without crashes — a RIST sender whose data block size is not a multiple of 188 bytes no longer stops the service: such blocks are discarded, and a log entry appears at most once a minute. Replacing all inputs or outputs of a stream in a single change while a RIST input or output is running no longer crashes the service either.

• RTSP input — on an address change, a pause, a fallback to a backup input or a reconnect, the input really closes its previous session. Before, it could keep receiving the stream from the old source.

• DVB: no more periodic stream interruptions — an incomplete read of data from a DVB device no longer causes the input to restart and the tuner to be retuned, which made a DVB-T/S stream drop out periodically (DVB receiver).

• Slow receiver of file, pipe and std outputs — if the receiver falls behind the stream for a long time, the output goes into the Output queue full error and restarts, like outputs of other types; the data delivered stay in order. Before, TS packets in this situation were silently lost and reordered (External applications (std)).

• std output with heavy stderr — an application that writes a lot to stderr no longer stalls after 64 KB of output and no longer restarts in a loop. On a failure, the end of its stderr is shown in the error text (External applications (std)).

• Damaged tables in the input stream — the node discards damaged PAT, PMT, CAT, NIT, EIT and TOT sections and the descriptors in them; they can no longer crash the service.

• The ESCR field in PES — streams with the ESCR field in their PES headers are parsed correctly; previously their parsing stopped with an error.

• Adding a stream with a transcoder — adding a stream whose transcoder input is connected to a decoder that is already running no longer crashes the service (Connection).

• HTTP/3: streamed responses arrive intact — over HTTP/3, MPEG-TS over HTTP (/http/) and live LL-DASH parts are delivered whole, as over HTTP/1.1. Before, the body of such a response arrived corrupted: it did not start at a TS packet boundary, fragments went missing or were repeated, and players lost sync. HLS and DASH segments and other files were not affected (HTTP/3 (QUIC)).

• OTT — DASH and LL-HLS delivery resumes after the video PID changes in the stream (before, only after an OTT restart); MPEG-TS over HTTP delivery no longer resets the input when the DVR disk slows down briefly.

• Deleting an input or output does not stop DVR recording — after an input or output of a stream is deleted, the DVR archive keeps being recorded. Previously, recording stopped until the next change to the stream’s OTT settings.

• DVR: a damaged index record — if a single record of the archive index is damaged (for example, after a power failure), the node skips it and loads the rest of the archive; only that fragment is lost. Before, everything recorded after it vanished from the archive at every restart, and the files were then deleted (DVR storages).

• DVR: cleanup of MP4 archives — when the disk usage limit is exceeded, the oldest segments of the MP4 archives (DASH and LL-HLS) are removed as well. Before, only the TS archive was cleaned up, and a disk holding only MP4 archives stayed full.

• DVR: subtitles — the WebVTT subtitle archive survives a restart; before, it was lost (WebVTT subtitles).

• DVR: emergency free space — the “Emergency free space, GiB” field of DVR storages never had and still has no effect on operation: the value is saved, but recording is not stopped by free space. The field is now described as reserved; the disk is kept within the limit by the cleanup by space, which does not touch archive younger than the protected floor (DVR storages).

• Other improvements and bug fixes.

version 2.0.2.408

19.10.2026

• A failing DVR disk does not stop live delivery — a full, read-only or failing DVR disk no longer stops the live delivery of a stream over HLS and DASH. Previously an archive write error, with no log entry, stopped both the live delivery and the archive until a restart, and clearing the archive did not help. Now the log marks the start and the end of a write failure, and once the fault is fixed the archive is written again, including after the stream archive is cleared (Stream statistics). The same applies to the subtitle archive.

• Changing settings does not block the API — editing a stream (a parameter, an output, deleting the stream) can no longer hang when an input is down or idle, or under load. Previously all configuration requests and the stream list in the web interface stopped responding along with it.

• Saving settings without loss — a change made immediately before a regular shutdown or restart of the service is no longer lost; a failed write of the settings file is retried every 10 seconds, and the log names the cause; a change made before the automatic restart after a restore from a backup no longer overwrites the restored configuration.

• Reconnecting inputs and outputs — after a reconnection retry, an input or output can no longer hang in a start attempt without having opened anything, until the service is restarted or the settings are edited. This happened most often with an SRT input in listener mode; PS1, RTMP/RTMPS, RTSP, the HLS input, TCP and the transcoder were affected too.

• SRT: a wrong passphrase does not lock the input — callers that connect again and again to an SRT port in listener mode with a wrong passphrase, or without one, no longer take up all the connection slots: a sender with the correct passphrase connects at once.

• The package repository over HTTPS and signed — the repository works over HTTPS, and the packages and metadata are signed with the repository key. The new commands to add it are in Installation on RHEL-family systems and Installation on Debian-family systems; a repository added earlier keeps working.

• Creating a stream with an invalid value — a request to create a stream through the HTTP API with an invalid parameter value is refused as a whole, and no stream is created. Previously the value was dropped and the stream was created (How errors arrive).

• The position of the ``mpts`` key does not matter — mpts is applied before the other keys of a stream entry, wherever it stands. OTT parameters and other settings of a single-programme stream passed when a stream is created through the HTTP API without mpts, or written in the settings file above it, are no longer lost (The order of the keys inside an object matters).

• SIGHUP is a regular shutdown — the SIGHUP signal stops the service in the same way as SIGTERM: the streams are stopped and the last settings change is saved. Previously the process exited at once.

• Pro-MPEG input in the Meshwork catalogue — a Pro-MPEG input receiving a multicast group is announced in the shared domain resource catalogue in the same way as UDP and RTP inputs (Shared resource catalogue).

• Other improvements and bug fixes.

version 2.0.2.399

01.10.2026

• T-STD buffer is a metric only — the video buffer model produced false positives on healthy streams, so its indicator stays in the statistics for diagnostics but no longer raises an alarm (code 11) and is not part of the aggregate TR 101 290 verdict (code 49) (Alert code catalogue).

• OTT without CBR padding — the NULL packets that pad the stream to a constant bitrate are not delivered to any OTT client, including HTTP delivery without a segmenter. The constant bitrate is preserved only on transport outputs — UDP, SRT, PS1, RIST.

• LL-HLS parts aligned to keyframes — every IDR opens a new part flagged INDEPENDENT, so a player joining at the live edge finds an entry point within a single GOP.

• Many HLS inputs on a node — HLS inputs download segments through a shared pool: an open input no longer holds worker threads of its own, and when the pool is busy, a segment download is deferred rather than restarting the input.

• Other improvements and bug fixes.

version 2.0.2.362

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 (Synchronisation).

• 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

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 SPTS — enable-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 session — GET /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 session — POST /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 — Behaviour 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 newer — pstreamer 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 (Synchronisation).

• 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 (Behaviour 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 catalogue).

• 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 (Synchronisation).

• Other improvements and bug fixes.