---
title: Monitoring
url: https://doc2.pstreamer.tv/en/manual/webui/monitor.html
lang: en
product: Perfect Streamer
version: 2.0.2.362
---

# Monitoring

The **Monitoring** group in the “Node” area collects the observation screens for the current node: the state of streams, clients, hardware and services. The screens refresh automatically. Most of them only display data, but some also allow the object to be managed: “Streams” — to create and configure streams, “DVB adapters” — to add, configure and scan an adapter, “EPG Database” — to edit a channel. The configuration of the services, the accounts and the storages is placed in the [Configure](configure.md#webui-configure) and [Administration](administration.md#webui-administration) groups.

The central screen of the group — “Streams” — is covered in a separate section [Streams](streams.md#webui-streams).

## Node overview

![Node overview.](../../_images/webui_home_overview.en.png)

The start dashboard of the node. The top bar holds the key indicator tiles: the number of streams and how many of them are “On air”, the “Problems” counter, active “Alerts” (in the administrator role), CPU and memory load. Every tile is a link to the screen its figure is taken from: the first three lead to [Streams](streams.md#webui-streams), “Alerts” — to Alerts, “CPU” and “Memory” — to System Monitor. Two tiles also set up where they lead, so that the list matches the figure that was clicked: “Streams” returns the list to the “All” mode, and “Alerts” sets the “This node” scope. “On air” and “Problems” deliberately leave the filter alone: it divides the streams by pause, and that is not what either figure counts. The “Alerts” tile counts the alerts of the own node only, so in a domain its number is smaller than the one of the top bar bell if that one has the “All nodes” scope selected; going from the tile is exactly what levels these two numbers. Below are the panels of the problem subsystems; each one lists the faulty objects, or, when there are none, a short summary of how many objects are working. “Problem streams” is always there. “Transcoders” appears when the node has transcoder instances or an alert about the node’s transcoder has been raised, “DVB adapters” — when a tuner has been detected or at least one adapter is configured. The conditions for the panels are wider than for the menu items of the same name ([Interface layout](index.md#webui-layout)): a subsystem that has fallen away does not take its panel with it, so a configured adapter keeps the panel even when the tuner has gone, and an alert keeps the transcoders panel even when not a single instance is left. In that case the menu item is already hidden while the panel is still in place, and the “Open →” link in its heading remains the only way into the section. A failure with nothing to list is reported by the transcoders panel on a line with a counter of the failed ones. That is why on a node without transcoders and without a tuner only one subsystem panel remains, and there is no way into those two sections from the overview. “Recent logs” lives by a rule of its own: the panel is visible to an administrator whose log database is working, and only while it holds records of the “warning” level and above from the last five minutes. On a quiet node it is absent, however many records have piled up over the years, and it goes away by itself when the last warning leaves that window. In the subsystem panels the name of an object is a link that opens the statistics window of exactly that stream, transcoder instance or adapter on its own screen, while the “Open →” link in the panel heading leads to the whole list. In “Recent logs” the rows are not links — the transition is made from the heading or through the “+N more →” link at the bottom of the panel. At the very bottom is the “Favorites” bar with the pinned signal charts of DVB adapters and mosaic tiles (they are pinned on their own screens); while nothing is pinned, there is no bar. The order in the bar is set by the operator: an item is moved by dragging or with the `Alt+↑` and `Alt+↓` shortcuts. The bar draws the charts and the tiles as two groups, so a move goes within its own group: a chart takes its place among the charts, a tile among the tiles. The order is kept in the browser together with the favorites list itself and survives a page reload, but on another machine and for another operator it is their own. Rearranging works only on a wide screen; the bar has no separate reset button — what is no longer needed is unpinned with the same star that pinned it. Node load assessment is covered in more detail on the System Monitor screen.

## Pipeline

![Pipeline graph: single stream (SPTS).](../../_images/webui_pipeline_stream.en.png)

![Pipeline graph: MPTS multiplexer.](../../_images/webui_pipeline_mpts.en.png)

![Pipeline graph: transcoder.](../../_images/webui_pipeline_transcoder.en.png)

The processing graph of a single selected entity. The core of the graph is three lanes: “INGRESS”, “STREAM” and “EGRESS”. If the stream is linked to a transcoder or to a multiplex, the link is unfolded right in the picture: three more lanes are added on that side — the neighbouring streams, the processing stage between them (“TRANSCODER”, “DEMUX” or “MUX”) and the neighbours’ own transport points (“INPUTS” and “OUTPUTS”). A chain unfolded on both sides occupies nine lanes and shows the path in full, from the input socket of the neighbouring stream to its own output socket. One stage is unfolded on each side, and only where a link actually exists; there is no switch for this, and what has been unfolded is taken out of the core, so one and the same entity is never duplicated in the graph.

The view of the graph is chosen by the type of the entity. An SPTS stream and an MPTS multiplex are drawn in the same way: for a multiplex, “MEMBERS” unfolds upstream (the card of each one carries its PNR) and “CONSUMERS” downstream; for the stream list see [Streams](streams.md#webui-streams). An ABR bundle ([Adaptive bundles](../streamer/ott_dvr.md#streamer-ott-adaptive)), a transcoder (Transcoders) and a DVB adapter (DVB adapters) each have their own fixed view.

The neighbouring streams are given as two lists — above the diagram and below it; the focus is moved by clicking a name or with the mouse wheel over the list, one position per step. The focus is also changed by the search on the stream name in the header and by transitions from other screens; the current focus is kept in the address, so a direct link to it can be shared. After a transition the diagram returns to the centre of the screen. The diagram area itself is a camera: dragging pans it, the wheel zooms it, and the “−”, “+” and “Fit” buttons are in the top right corner. “Fit” only shrinks a chain that is too wide down to the size of the window; the zoom is not adjusted by itself — a new focus opens at natural size.

A stream card opens its statistics. A click on a neighbouring stream, on a program of the multiplex or on the “TRANSCODER” stage moves the focus onto them; as long as the transcoder chain has not been unfolded, the same transition is made by the transcoder card in “INGRESS” or “EGRESS” — for an input this requires a decoder to be set. The inputs and outputs in the transports of the shared domain catalogue carry a “Show in the library” button ([Library — this feed](streams.md#webui-stream-library-feed)); in the lanes of the neighbouring streams there is none. A separate “Node relays” panel gathers the local relays of the node and is not shown on a node that has none, while the “doors” to the adjacent nodes open their admin UI at the same focus.

Selecting several rows on the “Streams” screen and pressing “Open in pipeline” gives a group view. The streams in it are drawn as one shared diagram: a row for each participant, while what they have in common — a transcoder decoder feeding two encoding variants, or a multiplex several of the selected streams belong to — is drawn once, with links running from it to the participants’ rows. The lists of adjacent streams, the focus counter and the search are removed here: each of them moves the focus to a single stream and would thereby break up the group. The live state of the inputs is not shown in the group view, of which the bar above the diagram gives warning: the diagram is built from a single snapshot of the configuration, the time of the snapshot is stated there as well, the “Refresh” button reads it again, and “Back to the stream list” returns to the screen. The state of each stream itself is live, as usual. No more than twelve participants are drawn; more can be selected, but the bar will then say how many out of how many are shown. A participant that is no longer on the node shows “This stream is no longer on the node.” instead of a diagram. Selected ABR sets do not share the common diagram — each gets its own card with an “Open separately” button. The address of the group view is fit for a link and opens on any device: a wide window is needed only to assemble the selection.

The graph does not draw paused inputs and outputs, and paused streams get neither into the list of neighbours nor into the composition of a multiplex; by a direct link such a stream still opens, while a paused transcoder variant in the “VARIANTS” lane stays on the diagram. The transmission model is described in [Transmission model: Stream, Sender, Receiver, Peer](../planning/index.md#planning-model), stream processing on a node — in [Streamer: implementation details](../streamer/index.md#streamer), MPTS multiplexes — in [MPTS streams](../streamer/mpts.md#streamer-mpts).

## Clients

![The “Clients” screen, the “HTTP / OTT” tab.](../../_images/webui_clients_http.en.png)

The list of connected receivers, laid out across tabs for the delivery protocols: “HTTP / OTT”, “SRT”, “PS1” and “RIST”; each tab carries a live counter of active sessions. The columns “Client” (with a mark of its origin: “Local login” or “External billing”), “Address”, “Stream”, “Login” and “Uptime” are present on every tab; the protocol columns are inserted between them rather than appended at the end: on “HTTP / OTT” they are “Type”, “Session” and “Quality”, on “SRT” — “Mode” (caller or listener), “Loss %”, “TSBPD” and “RTT”, on “PS1” — “Loss %” and “RTT”, on “RIST” — “Status”, “RTT”, “Bandwidth” and “Quality”. Search works over the list (name, login, address), and long lists are split into pages.

The row order is set by the operator: a column header is a button, and clicking it sorts the list by that column. The icon beside the caption shows the state of the column: `↕` — the column can be sorted but is not the one being sorted on; `▲` and `▼` — the direction chosen. A column that does not sort has no icon at all. Clicks cycle through three states: first the direction useful for that column, then the reverse, then the sorting is dropped and the order in which the node sent the rows returns. The useful direction for numeric columns is descending (“Uptime”, “Loss %”, “RTT”, “Bandwidth”, “Quality”), so that the outliers land at the top on the first click; for text columns it is A to Z. “Session” is ordered not alphabetically but by the kind of delivery: “direct” first, then “OTT”. “TSBPD” does not sort at all — the column holds “Yes” and “No”, and grouping by it says nothing. Rows with no value in the column being sorted go to the bottom in both directions rather than to the top; the exception is “Uptime”, where an unknown running time is shown as `0s` and sorts together with the zeros. Numbers inside text values are compared as numbers rather than character by character, and anywhere in the string: `192.168.1.9` comes before `192.168.1.10`, port `:80` before `:5000`, and `stb2` before `stb10`. The whole list found is sorted, not the page on display, and the counter of rows shown does not change with the sorting, though the list returns to the first page. Rows with equal values always line up in one and the same order, so the next refresh of the list does not swap them around. The chosen order is not remembered: the screen always opens in the node’s order. On switching to another protocol tab the order is kept, but it only takes effect if the same column is present there as well; if it is not, the list runs in the node’s order, and on returning the sorting comes into force again.

Expanding a row opens the full set of diagnostic counters of the session, updated in real time. Never more than one row is expanded at a time: expanding the next one closes the previous, so two sets of counters cannot be compared side by side — the readings are taken in turn. A row stays expanded as long as its session is alive: refreshing the list does not close it, not even when an OTT session changes its address. It is closed by clicking again, by switching tabs, by changing the search string, by changing the sort order or by paging; with the row, the selection of the session for “Kick” is cleared as well.

Two columns of the “HTTP / OTT” tab divide the receivers by the way of delivery: on one and the same port the node serves both direct MPEG-TS and OTT. “Type” shows what the node has reported — the protocol and the scheme through a slash (`HLS/https`, `LL-DASH/quic`): the protocol is HTTP (direct MPEG-TS delivery), HLS, LL-HLS or LL-DASH, the scheme is http, https or quic. “Session” reduces this to two values: “direct” for the HTTP protocol and “OTT” for the rest; a dash would mean that the node did not report the kind of session — on a healthy build that does not happen. The difference between the values is operational. Direct delivery is a row per connection: as many rows as this login’s “Max connections, HTTP/HLS” allows ([User: add and edit](configure.md#webui-user-editor)), and they are disconnected separately; the row holds as long as the connection is alive — the node does not close it for inactivity. An OTT session is a row per player session, not per request, and it disappears by itself about a minute after the player’s last request over that session: any request counts, not only a chunk download, so a player that keeps refreshing the manifest holds the row. With DASH, several players of one login watching one stream go as a single session ([3.2. Session reuse for DASH](../extras/ott_caching.md#manual-extras-ott-caching-3-2-session-reuse-for-dash)). “Quality” is computed over chunks, so for the rows of direct delivery this column is always empty.

The administrator has the “Kick” action available. It ends a single session — the one whose row is expanded; the other sessions of the same login keep working. The expanded row is exactly the selected target, so the button is enabled the whole time at least one row is expanded, and it follows the selection as you move from session to session. When nothing is expanded, it is disabled, and what is missing is stated next to it — “Expand a session row to select it, then kick.” Two more reasons for unavailability are permanent: on the “RIST” tab kicking is not supported at all (“RIST sessions can’t be kicked.”), and on “SRT” the connections in caller mode are not kicked (“Caller-mode sessions can’t be kicked (display-only).”). What has been selected is confirmed in the “Kick session” window. The command goes to the node asynchronously: the reply “Kick sent.” means that the node has accepted it, not that the connection is already closed. The delivery protocols are described in [Peer protocols for reliable transmission](../planning/index.md#planning-peer-protocols), OTT delivery — in [OTT and DVR](../streamer/ott_dvr.md#streamer-ott-dvr), the receivers’ accounts — on the [Configure](configure.md#webui-configure) screen ([2. Client behaviour](../extras/ott_caching.md#extras-ott-clients)).

## DVR monitor

![DVR storages monitor.](../../_images/webui_dvr_monitor.en.png)

Read-only observation of DVR recording per storage. For each storage — the fill level relative to the cleanup target (a bar with the target mark), the volumes (used, free, total, archive size broken down into TS/MP4), the “Disk pressure” flag, the current background task and the number of bound streams; the active alerts of the storage are shown alongside. Expanding shows the archive streams line by line (recording / idle, retention depth, accumulated volume, read/write latencies) and the maintenance diagnostics (collection of orphaned directories, trimming under disk pressure). For a stream the [Stream statistics](streams.md#webui-stream-stats) window opens; the administrator additionally gets archive cleanup for an individual stream and the general “Clean up orphaned archives” command. The storages themselves are configured on the [DVR storages](administration.md#webui-dvr-storages) screen; archive recording and playback are described in [OTT and DVR](../streamer/ott_dvr.md#streamer-ott-dvr) and [DVR: the stream archive](../streamer/ott_dvr.md#streamer-dvr).

## Transcoders

![The Transcoders screen.](../../_images/webui_transcoders.en.png)

The list of the node’s active transcoder instances with an “All / Active” filter. The header carries the total load, “Total CPU” and “Total memory”, along with the actions on the selected instance: “Statistics” and “Open in the pipeline” (Pipeline). Along the row — the state, the decoder (the source), the type, the number of encoders, the running time, CPU and memory; expanding it shows the encoders with their output parameters (video codec, resolution, frame rate/scanning, audio codecs, actual bitrate). The decoder and every encoder have their own actions on the stream named in that row: for the decoder it is the source stream, for an encoder the stream it produces. The pipeline label opens the statistics of such a stream, and an administrator has a settings button beside it that opens the stream’s editor over the list ([Configure stream](streams.md#webui-stream-editor)). Both leave the operator here; the “Show <stream name> in the stream list” button, on the contrary, leads away from the screen: it opens [Streams](streams.md#webui-streams), where the row of that stream is expanded and the list is scrolled to it, and it opens nothing over the list. Arriving by such a link clears the filters on that screen, and in particular returns the “All / Active” switch to “All” — otherwise the stream could turn out to be hidden. Unlike the settings button, the jump is available in any role: it is navigation, not a change. Going back with the browser returns to the transcoders screen, but afresh — the expanded row of the instance is closed in the process. The capabilities and the configuration of transcoding are in [Transcoders](../streamer/transcoder.md#streamer-transcoder), the monitoring in [Monitoring](../streamer/transcoder.md#streamer-transcoder-monitor), and the installation of packages and drivers in [Transcoders](../install/transcoder.md#install-transcoder).

### Transcoder instance

![The statistics window of a transcoder instance.](../../_images/webui_transcoder_detail.en.png)

The card of an individual transcoder — a statistics window opened from the screen header, from the “Transcoders” panel of the node overview or from the central node of the transcoder graph. It shows the source (decoder), the list of encoders (1 → N), the resources (CPU, uptime, PID, memory) and the process log: the last exit code, the current and the previous run logs (with copying) — for diagnostics. When followed by a link from another screen, the window also expands and highlights the row of this instance in the list behind it, so that after the window is closed the operator stays on it; if the list stood in the “Active” mode, it returns to “All” — otherwise a stopped instance, and it is precisely such ones that the links from the node overview lead to, would be hidden. A window opened from the header of the list itself leaves the filter alone.

## DVB adapters

![The DVB adapters screen.](../../_images/webui_dvb_adapters.en.png)

A single DVB reception screen: the adapter configuration enriched with live state (signal lock, quality, bitrate). The rows are grouped by mode — “Stream mode” (reception into a stream) and “FE Monitor” (monitoring of a frontend tuned by another application); the columns are name, transponder, signal, bitrate, alerts and state; each row has a pause toggle. The actions on the selected adapter are placed in the header: “Statistics”, “Open in graph” (Pipeline), and also (for the administrator) “Configure adapter” and “Delete adapter”. The header also holds the “All / Active” filter, “Add adapter” and “Scan…” (for the administrator; the scan button additionally requires a window at least 768 pixels wide, so on a phone it is absent). Arriving at the screen by a link that names a particular adapter returns the filter to “All”, so that the adapter does not stay hidden; opening the statistics from the list itself leaves the filter alone. DVB reception is described in [DVB receiver](../streamer/dvb.md#streamer-dvb), adapter monitoring — in [Signal monitoring](../streamer/dvb.md#streamer-dvb-monitoring).

### DVB adapter editor

The window for adding and configuring a DVB adapter. “Mode” and “Broadcast system” are set when the adapter is added and cannot be changed afterwards — they determine the set of settings. The hardware is selected from the list of detected frontends (see [Hardware](administration.md#webui-hardware)). Stream mode provides the tuning parameters (frequency, symbol rate, FEC, modulation and so on — according to the broadcast system), the LNB section for satellite reception, “T2-MI”, “BISS descrambling” and “CI/CAM descrambling”. Muting of the adapter alerts and the “Advanced” section (extended parameters) are available in both modes; FE Monitor mode reads the signal without retuning the tuner. Reception and descrambling are described in [Adapters](../streamer/dvb.md#streamer-dvb-adapter), [Descrambling](../streamer/dvb.md#streamer-dvb-descrambling) and [T2-MI decapsulation](../streamer/dvb.md#streamer-dvb-t2mi).

Some fields the dialog requires to be filled in before creation, and it does not let an adapter be created without them. The hardware is mandatory **in both modes**, FE Monitor included: while the list still reads “— select hardware —”, the “Create and configure” button is locked and the text under the field says “Select the hardware — without it the adapter cannot be saved.”. The frontend monitor also watches a particular tuner — it merely does not retune it. On a node where no frontend is listed there is nothing to choose from, and the same requirement passes to the manual “Adapter index” field. For DVB-S, DVB-S2 and DVB-C in Stream mode “Symbol rate, ksym/s” joins the mandatory ones — while it is zero, creation is locked and the field explains “State the symbol rate — without it the adapter will not be configured.”. The frequency and the symbol rate are checked not only by creation but by the editing dialog as well: a zero value there is no longer saved halfway.

The requirement comes from the node: it declares these keys with a default value below its own lower bound and validates them when the adapter is created, so the value has to be supplied by the operator and the default cannot be relied on. Before the symbol rate field appeared, a satellite or cable adapter in Stream mode could not be created by hand at all — the node refused — and only the scanning wizard worked, which takes the rate from the multiplex it has found.

### DVB scan

A channel search wizard (for the administrator). It proceeds in steps: selection of the tuner and the broadcast system, selection of the source — “Catalog” (satellite, cable or terrestrial with LNB parameters) or “Blind scan” over a frequency range; then the transponders are swept with progress indication and accumulation of the multiplexes found, each with its list of services.

The catalogs of satellites and of cable and terrestrial regions are searched by string: a “Search” field sits above the list, the list itself is sorted by name, and numbers within the names are compared as numbers. The words entered are looked for in any order and across the whole row — including the orbital position of a satellite and the country code of a cable or terrestrial region — so the query `hot 13` finds Hotbird at 13.0°E. A row already selected does not disappear from the list even if it does not match the query: the source selected cannot be cleared by searching. The counter under the list counts the rows displayed, not the matches, and as long as there is at least one row in the list, “Nothing found.” does not appear; an empty catalog has no counter at all, and the reason is stated by the message above it. The query is cleared when moving between satellite, cable and terrestrial and when switching “Catalog” ↔ “Blind scan”; changing DVB-T to DVB-T2 or DVB-S to DVB-S2 preserves it.

The satellites no longer follow the arc: the name of each begins with its own position, so sorting by name lines them up by the size of the degree, alternating eastern with western. The position wanted is quicker to type into the search than to find by scrolling.

For a terrestrial scan the first step gains a “Probe PLP up to” field — a sweep of the PLPs on every DVB-T2 transponder ([Scanning](../streamer/dvb.md#streamer-dvb-scan)). The default is 0: there is no sweep, and the node receives the same request as before. A value outside the range 0…255 is not sent — the start button is disabled instead. A node older than 2.0.2.291 does not understand such a request, and the field has no effect there.

Multiplexes found on different PLPs of one frequency are shown as separate rows — each with its own program list, its own PLP mark and its own selection checkbox; a row read with no filter is marked “PLP auto”. The “PLP auto” mark relates to the whole result list rather than to a single transponder: it appears on the rows without a number once at least one row in the list has one. The PLP number also arrives without a sweep, if the catalog gives it.

The busy tuners are visible in the tuner list as well — they cannot be selected — and the state of each stands beside it: “free”, “busy · scanning” or “busy” with an English token for the reason: `kernel` — an outside process holds the tuner, `pss-id-<number>` — an adapter of this same node holds it, and such an adapter can be paused to release the tuner. The sweep is stopped with the “Stop” button; while the command is on its way the button reads “Stopping…”. The node itself never refuses a stop — it always accepts one — but the command may fail to reach it: a timeout expired, the link broke, the session ran out. A message then appears in the window opening with the words “Could not stop the scan — the tuner is still busy.”, with a description of the failure after them; the sweep meanwhile carries on, and “Stop” can be pressed again. The interface will not pass an unstopped scan off as stopped. There is one scan per node, shared by all adapters, so starting a new pass ends the previous one and takes its place. The node can refuse a start, and that is the only case where it refuses for real: the previous pass has not released the tuner within the time allowed — “Could not start the scan — the tuner is still busy with the previous pass. Try again in a few seconds.” Closing the window by any means sends the node the same stop command — but now without a window in which a failure could be reported; a command that does not arrive is backed up by the node’s own timeout. The multiplexes found are added one at a time or in a batch. One at a time — the “Add DVB adapter” window opens with the parameters pre-filled; it holds only the essentials, and the settings window with all the parameters opens once the adapter has been created. In a batch — the selected rows are created with no windows, and only a warning about matching names can interrupt it. Names are formed automatically and checked for duplicates; for a row with a PLP number, the number goes into the name. The PLP number is written into the “Stream id (ISI/PLP)” of the new adapter at once in both cases, so checking and correcting it has to be done in the settings of the adapter created. Adding also closes the wizard and therefore stops the sweep. The channel search is described in [Scanning](../streamer/dvb.md#streamer-dvb-scan).

### Adapter statistics

A window with the live parameters of the selected adapter. It contains: the state summary and the tuning parameters, the active alerts, the signal history charts (level, SNR, BER, UCB), the “Metrics” section (frontend, lock status, frequency, “PLP / ISI”, SNR, signal level, error counters, and for Stream mode — the bitrate), the list of programs, “T2-MI carriers”, “BISS descramblers”, “CI/CAM module”, “Profiler” (processing thread load, DVR ring overflow) and the adapter log. The administrator can use “Reset statistics”. It serves for antenna alignment and for checking the stability of reception ([Signal monitoring](../streamer/dvb.md#streamer-dvb-monitoring)).

In the adapter’s program list and in this window (the program heading and summary, the “Program” line in the media block) a service inside a T2-MI carrier is shown with the composite PNR — the very one by which the program is addressed everywhere: in the program selector of the demultiplexer, of BISS and of CAM ([T2-MI decapsulation](../streamer/dvb.md#streamer-dvb-t2mi)). The program’s own number inside the carrier is no good for addressing — on a transponder with mirrored groups it repeats on every carrier and points to nothing. The programs of the outer multiplex are shown as before.

The “PLP / ISI” line in “Metrics” appears only when the node reports the number of the selected stream: an adapter on “auto”, and DVB-C and ATSC, do not have it. This is a tuner-level number — the one set in “Stream id (ISI/PLP)”: the PLP for DVB-T2, the stream identifier for satellite multistream. The PLPs of T2-MI carriers are a different thing, shown by the separate “T2-MI carriers” section.

## Test streams

The test streams screen — generation of service streams for checking signal paths ([Test streams](../streamer/test_stream.md#streamer-test-stream)). The section is in preparation.

## EPG Database

The collected program guide and the state of its sources. The screen contains the tabs:

****Database****
  Viewing of the accumulated guide: source selection, the channel list with search and filtering by sets, the schedule of the selected channel by day (day and language switching, the current event highlighted). The administrator can edit a channel — name, time zone, icon, membership in sets.
****Source status****
  The import status for each source: state, the time of the previous and the next update, the number of channels and events, the error; the administrator can force an update of a source.

EPG import and processing are described in [EPG Database](../streamer/epg/xmltv.md#streamer-epg-database) and [EPG/XMLTV import](../streamer/epg/xmltv.md#streamer-epg-xmltv); the sources and their configuration — in [Source configuration](../streamer/epg/xmltv.md#streamer-epg-sources) and on the [EPG Settings](configure.md#webui-epg-settings) screen.

## Mosaic

A preview wall: live frame thumbnails — one tile per active SPTS stream and per program of an active MPTS (multiplex programs are marked with an icon). The grid adapts to the screen width, the tile size is switched by the “Size” control (1, 1/2, 1/3). Paused and stopped streams do not appear in the mosaic. Clicking the picture opens the enlarged frame, clicking the caption — the statistics window of its stream ([Stream statistics](streams.md#webui-stream-stats)); for a multiplex program these are the statistics of the whole MPTS, not of a single program. The star pins the tile to “Favorites” on the Node overview screen.

The tile order is set by the operator: a tile is moved to the place of its neighbour by dragging or with the `Alt+↑` and `Alt+↓` shortcuts; the tile’s tooltip says the same — “Drag to rearrange · Alt+↑/↓”. The gesture works only on a wide screen: on a tablet and a phone the wall displays the layout that has been set but does not let you change it. The layout is kept in the browser, not on the node and not in the account, so another operator and another machine have an order of their own. The “Reset layout” button appears in the header next to the “Size” control as soon as a layout of your own has been set, and returns the wall to the usual order — by stream number, and for a multiplex by program number as well. The tile of a stream that has gone into pause keeps its place and returns to exactly that place — even if the neighbouring tiles have been rearranged in the meantime. The place is forgotten only when the tile has not appeared on the wall for a month. A new tile is always added at the end.

### Original frame

An enlarged view window for the selected frame at its original resolution — for a detailed visual inspection of the picture. The window header holds the tile name and the frame size, and on the right the “Zoom out”, current scale, “Zoom in”, “Open in new tab” and “Close” controls. The scale changes from 100% to 600% — with the mouse wheel, with the `+` and `−` keys or with those same buttons. A hundred percent means “fit to the window width”, not “pixel for pixel”; the proportions of the frame are always preserved, so a tall frame may not fit the window in height even at 100% — such a frame is examined by scrolling. Inside the window the adjacent mosaic tiles can be paged through — with the `←` and `→` keys or with the buttons at the edges, in the order in which the tiles stand on the wall; when moving to an adjacent tile the scale returns to 100%. `Esc` closes the window. The header and the tooltips hide after a few seconds of inactivity and come back when the frame is clicked.

## System Monitor

![System Monitor.](../../_images/webui_system.en.png)

The state of the server as cards: “CPU” (the total load and the share of the PSS process, the number of cores), “Memory” (used and the share of PSS, the amount in GB), “Network” (per interface — receive/transmit and link utilisation, with VLANs nested under the physical adapter) and the hardware acceleration cards (NVIDIA — GPU/memory/decoder/encoder, Intel VPL). In an interface row, after the name and, if it is known, the link speed, comes its IPv4 address — `eno3 · 1 Gbps · 10.0.0.5`; for a nested VLAN the speed is not reported and the address follows the name directly. Several addresses on one interface are listed separated by commas, and an interface with no IPv4 address shows nothing. Below is the “History” block: graphs of the indicators over time with the same window presets as the stream statistics ([Stream statistics](streams.md#webui-stream-stats)); the heading of an interface graph carries the same address. An interface with a known link speed is drawn as a percentage of it, while one whose speed the node does not report (usually a VLAN) is drawn in megabits. Such a graph does not squeeze the scale below 1 Mbit/s, so that an almost idle interface does not look loaded; and if at least one direction carried something over the window but its peak fell short of a megabit, the graph’s readings move to two decimal places — otherwise an interface carrying tens of kilobits would read as dead. A direction that stayed silent for the whole window does not count towards this, so a completely idle interface stays at a plain zero. On nodes with configured DVB adapters, the signal quality graphs of the frontends are shown in a section of their own ([Signal monitoring](../streamer/dvb.md#streamer-dvb-monitoring)). It helps to judge the headroom in load; recommendations for tuning resources are in [Node performance tuning](../extras/tuning.md#extras-tuning), external metric collection in [Connecting external monitoring systems](../extras/monitoring.md#extras-monitoring).

## Logs

![Logs.](../../_images/webui_logs.en.png)

A structured event log of the node (available to the administrator) with filters and paginated output. Selection is by severity (“Severity ≥”), by source type and identifier, by message text and by date range; the sort order is switchable (newest / oldest first). The columns are time, severity, source and message; a stream source opens its [Stream statistics](streams.md#webui-stream-stats) window, other sources lead to the dedicated screen. It serves for diagnostics and incident analysis.

Every start of the service is marked in the feed by a separator line of its own, “Streamer start”, 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; a run that ended without a proper stop is marked out separately. The separator is placed even when the feed is filtered by severity: the start line is itself a notice and would not pass an error filter, yet the boundary between runs is needed precisely when an incident is being looked into.

A long message in the list is collapsed to two lines; a click on the row (or on the chevron at its start) opens a panel beneath it with the full text, a “Copy message” button, the time, the level, the source of the entry and — if the entry repeated — the number of repetitions. Rows expand independently of each other, and on paging and on refreshing the feed the expansion is dropped: a log entry has no identifier of its own, so there would be nothing to remember.

The source of a record is denoted by the object type, and for streams also by the number and the name: `Stream #43 · orig CBC HD`; if no display name is set, the stream name is substituted. Streams are labelled with the same name and number in the selection list of the “Source ID” filter. Records made by an input or an output of a stream are attributed to the stream itself and show its name, while the particular input or output is named at the start of the message text.

## Alerts

![Active alerts.](../../_images/webui_alerts.en.png)

A consolidated screen of the alerts in force: own (of the current node) or those of the whole domain — switched by the scope in the header. The screen shows only the active set — an alert that has been cleared disappears from the list. The columns are severity, source, message and age; a stream source opens its [Stream statistics](streams.md#webui-stream-stats) window. An alert about an input or an output is booked against the stream, while the input or the output itself is appended to the stream name as an English token — `input #2` for an input, `output #7` for an output. For an input this is its number in the redundancy list, the same one that is visible on screen; for an output it is the internal record number, which is shown nowhere, because outputs have no priority and are given no ordinal. Counting the outputs down the list is of no use: the numbers stay with deleted records. It is simpler to open the expanded row of the stream — there the alert stands right on the row of its own input or output. In a domain of several nodes the row shows the originating node (with a link to its admin UI). Alerts at the administrator-action level are provided with a “Reset” button (manual acknowledgement) that acts on their own node. For such alerts the place where the cause is to be removed is shown under the source; when it is an input or an output, the row serves the administrator as a link and opens the editor of the owning stream ([Configure stream](streams.md#webui-stream-editor)). An alert that arrived from another node gives no link — the stream numbers are each node’s own. The alert model, its analysis and the full list of codes are given in [Alerts (alerter)](../meshwork/alerts.md#meshwork-alerts) and [Alert code catalog](../meshwork/alerts.md#meshwork-alert-codes); threshold configuration and external delivery — on the [Alerter](administration.md#webui-alerter) screen.