---
title: Contacting technical support
url: https://doc2.pstreamer.tv/en/manual/support/index.html
lang: en
product: Perfect Streamer
version: 2.0.2.399
---

# Contacting technical support

This section helps you prepare a request so that the investigation can start right away, without an exchange of clarifying questions. It consists of a questionnaire worth answering before you get in touch and a list of the materials attached to the request.

Requests are sent by email; the support address is given on the website [https://pstreamer.tv/](https://pstreamer.tv/).

A request must not contain private information: passwords, keys, secrets, addresses and names of your systems and subscribers, details about the customer. The questionnaire is designed so that none of its answers requires such data, and the materials are cleaned before sending according to the rules of the Private data section.

## Questionnaire

Answer the questions in order. If you do not know an answer, say so: that is information too, and it saves time.

**Node**

1. Which build version is installed? It is shown on the [About](../webui/administration.md#webui-about) screen in the “Build & Libraries” section; from the command line, `/usr/local/bin/pss -v` prints it together with the versions of the bundled libraries.
2. Which operating system and version? Does the node run on a physical server or in a virtual machine?
3. What hardware is involved in the problem: CPU model and amount of memory, models of network cards, graphics cards and DVB boards?
4. Does the node work on its own or is it part of a Meshwork domain? If it is in a domain, how many nodes does the domain have and do they all run the same build version?
5. What type of licence is it and is it valid? The [License](../webui/administration.md#webui-license) screen. The key ID and the C2V/V2C files are not attached to the request unless support asks for them.

**What is happening**

1. What was expected and what happens instead? Describe what you observe, not the presumed cause: “the picture on the HLS output freezes every few minutes”, not “the transcoder broke”.
2. When did the problem first appear and when did it last occur? Give times with the time zone. By default the `main.log` log writes the time in UTC and without the year (Service log) — match one against the other.
3. Is the problem constant, intermittent or did it happen once? If intermittent, how often, and is there a pattern: time of day, load, a particular source?
4. Can the problem be reproduced step by step? If so, list the steps.
5. What changed shortly before the problem appeared: an update of the build or the operating system, a settings change, a hardware replacement, changes in the network or at the source?

**Affected streams**

1. Which streams are affected — the stream numbers on the node? Are all streams affected, some of them or one?
2. What transport is used on the input and the output of the affected stream, and is it SPTS or MPTS? Is transcoding used, and if so, which backend and which version ([Backends and codecs](../streamer/transcoder.md#streamer-transcoder-backends), the [About](../webui/administration.md#webui-about) screen, “Transcoders” section)?
3. Which codecs and which bitrate does the source have? If you have an analyzer report (What to attach), it answers this question.
4. Is the problem on the input side or the output side? Is it visible in the stream statistics ([Stream statistics](../webui/streams.md#webui-stream-stats)) — continuity errors, switchovers to the backup input, buffer resets?
5. How does the same source behave when it bypasses the node or on another node? How does another source behave on the same stream?

**Service and resources**

1. Was the service restarted during the problem interval? On the [Logs](../webui/monitor.md#webui-logs) screen, each start is marked with a “Streamer start” line; a run that ended without a regular shutdown is flagged separately.
2. Which alerts are active on the node ([Alerts](../webui/monitor.md#webui-alerts))?
3. What is the load on the CPU, memory and network interfaces at the time of the problem? The [System Monitor](../webui/monitor.md#webui-system) screen, “History” block.

**What has already been done**

1. What actions have already been taken, and which of them helped: restarting the stream or the service, switching the input, changing settings?

**Incident timeline**

1. Describe the course of events in order, with timestamps and the time zone:

   - the last moment when everything worked as expected;
   - changes made after it — on the node, in the network, at the source or the receiver;
   - the first manifestation of the problem and how it was detected: an alert, a subscriber complaint, your own observation;
   - how the problem developed afterwards: got worse, went away on its own, recurred;
   - every action taken and what changed after it;
   - the current state at the time of the request.

   The timeline ties the answers to the previous questions into a single picture and makes it possible to match events against the node log line by line.

## What to attach

Attach what is relevant to the problem. The list below covers the most common materials, not a mandatory set.

**The service log** for the problem interval — see Service log.

**Transcoder logs**, if transcoding is involved in the problem — first of all the process’s “Previous log”, as well as the last exit code and the current log. They are kept only in the node’s memory and are lost on restarts, so capture them first — see Transcoder logs.

**Entries from the** [Logs](../webui/monitor.md#webui-logs) **screen**, filtered by the affected stream and the date range. The full text of an individual entry is copied with the “Copy message” button.

**Screenshots** of the affected stream’s statistics ([Stream statistics](../webui/streams.md#webui-stream-stats)) and of the system monitor for the same interval.

**Settings of the affected stream** — only after cleaning (Private data). A full configuration backup from the [Maintenance](../webui/administration.md#webui-maintenance) screen contains the passwords and keys of all node objects in plain text; attach it only if support asks for it, and also after cleaning.

**An analyzer report on the source**, if the problem looks like a defect of the stream itself: the [TS Analyze Perfect Streamer Toolkit v2.3 — TR 101 290](../toolkit/ts_analyze.md#toolkit-ts-analyze) utility reads UDP or a file and produces a text or XML report.

**Diagnostic output for the problem profile:**

- licence and key — the output of `pss_lic` with the `-v` option ([PSS Lic Perfect Streamer Toolkit v2.0 — the node license](../toolkit/pss_lic.md#toolkit-pss-lic));
- NVIDIA hardware transcoder — `nvidia-smi`, Intel — `vainfo --display drm --device /dev/dri/renderD128` ([Transcoders](../install/transcoder.md#install-transcoder));
- UDP multicast reception losses — `netstat -su`, the `RcvbufErrors` line ([Recommendations for working with UDP multicast](../faq/index.md#faq-multicast-nic)).

## Service log

The service writes its log to the `main.log` file. The directory is set by the `log-dir` key of the `pss.properties` file, by default `/var/log/pss`. The file is rotated daily: previous days lie next to it in `main.log.<timestamp>` files, so for an interval in the past you need that day’s file, not the current `main.log`.

Times in the log lines are given without the year and in UTC by default; local time is enabled by the `log-time-local` key of the same file.

```sh
$ ls -l /var/log/pss/
$ tail -n 200 /var/log/pss/main.log
$ journalctl -u pss -n 50
```

The last two commands are not equivalent. If the service did not come up at all, the cause may lie before the log itself — its directory is unavailable, `pss.properties` cannot be read — and then `main.log` will not have a single line about it: the file may be left over from the previous run and show old content. The service prints such a cause in a line starting with `!!!`, and it is visible in the system journal, that is, in the output of `journalctl -u pss`. Ordinary log lines go there as well only if `log-to-console` or `log-to-syslog` is enabled in `pss.properties`.

The logging level is set on the [Server Settings](../webui/administration.md#webui-server-settings) screen — a general one and separate ones for the SRT, RIST and FFmpeg libraries. Inputs and outputs of individual transports have their own tracing — the `Trace` field ([Input and output fields by transport](../webui/io/index.md#webui-io)). Raise the level or enable tracing only when support asks for it, and restore the previous value after collecting: a detailed log grows quickly.

## Transcoder logs

If transcoding is involved in the problem, the transcoder process log is the key material of the request: the cause of an encoding or decoding failure is almost always visible only there.

The transcoder process always keeps a detailed log; there is no need to enable tracing separately. But this log is not written to a file: the node keeps only its tail in memory, the last 256 KB, and only for two runs of the process — the current one and the previous one. The log is opened in the [Transcoder instance](../webui/monitor.md#webui-transcoder-detail) window (the [Transcoders](../webui/monitor.md#webui-transcoders) screen), in the “Process log” block: “Current log”, “Previous log” and “Last exit code”. Each log is taken with the “Copy” button.

The “Previous log” is the most valuable. The failed process has usually already been restarted — by the watchdog timer or by the node itself — and then it is the previous log that contains the run that ended, together with the messages that preceded the failure. The current log already describes the new run and only shows whether the problem recurs.

This leads to the following collection rules:

- **Copy the “Previous log” as soon as you notice the problem.** Every new run of the process — a watchdog restart, stopping and starting the stream again — shifts the logs by one position: the current one becomes the previous one, and the former previous one is erased. If the failure recurs before the log has been copied, the record of the first failure will be lost. Restarting the service or the node erases both logs.
- **Do not restart the stream or the service before the log has been copied** — even if the restart restores operation.
- **Attach the last exit code and the current log together with it.**
- **In a long-running process, the beginning of the log has already been pushed out.** If the moment of start-up matters — for example, the choice of device and driver — reproduce the problem after restarting the stream and copy the log right away.

One line about the process ending also remains in the service log: when the transcoder exits on its own, the node writes a warning to `main.log` with its last message and exit code. These lines survive a service restart and let you find the moment of the failure even if the process log itself has already been lost:

```sh
$ grep -i 'transcoder' /var/log/pss/main.log
```

Attach to the transcoder logs the backend type and version from the [About](../webui/administration.md#webui-about) screen (“Transcoders” section) and the device diagnostic output — `nvidia-smi` or `vainfo` (What to attach).

## Private data

Logs, settings and screenshots contain data that must not end up in a request. Replace them before sending:

- passwords, passphrases, keys and secrets — the full list of configuration keys that store them is given in the [Values that must not be passed on](../extras/config_file.md#extras-config-file-secrets) section;
- addresses with credentials right in the URL — for an input source and for the publishing address on an external platform;
- IP addresses and host names of sources, receivers and subscribers, as well as the addresses of the node itself;
- subscriber names, account logins, channel names and details about the customer, if they reveal information in themselves.

Replace consistently: the same original value everywhere with the same substitute (`10.0.0.5` → `HOST-A`). The cleaned log then still shows which lines belong to one node and which to different ones, and the analysis keeps its meaning.

Do not include in a request credentials for logging in to the node or its web interface. If access is needed for the investigation, the way to provide it is agreed separately.