---
title: Contato com o suporte técnico
url: https://doc2.pstreamer.tv/pt/manual/support/index.html
lang: pt-BR
product: Perfect Streamer
version: 2.0.2.399
---

# Contato com o suporte técnico

Esta seção ajuda a preparar a solicitação de forma que a análise possa começar imediatamente, sem troca de perguntas de esclarecimento. Ela consiste em um questionário que vale a pena responder antes do contato e em uma lista dos materiais anexados à solicitação.

As solicitações são enviadas por e-mail; o endereço do suporte está indicado no site [https://pstreamer.tv/](https://pstreamer.tv/).

A solicitação não deve conter informações privadas: senhas, chaves, segredos, endereços e nomes dos seus sistemas e assinantes, dados do cliente. O questionário foi elaborado de forma que nenhuma resposta exija esses dados, e os materiais são limpos antes do envio segundo as regras da seção Dados privados.

## Questionário

Responda às perguntas na ordem. Se não souber uma resposta, diga isso: também é informação, e ela economiza tempo.

**Nó**

1. Qual versão da build está instalada? Ela aparece na tela [Sobre o sistema](../webui/administration.md#webui-about), na seção «Build e bibliotecas»; na linha de comando, `/usr/local/bin/pss -v` a exibe junto com as versões das bibliotecas embutidas.
2. Qual sistema operacional e qual versão? O nó roda em um servidor físico ou em uma máquina virtual?
3. Qual hardware está envolvido no problema: modelo do processador e quantidade de memória, modelos de placas de rede, placas de vídeo e placas DVB?
4. O nó funciona sozinho ou faz parte de um domínio Meshwork? Se estiver em um domínio, quantos nós ele tem e todos rodam a mesma versão da build?
5. Qual é o tipo de licença e ela está válida? Tela [Licença](../webui/administration.md#webui-license). O identificador da chave e os arquivos C2V/V2C não são anexados à solicitação enquanto o suporte não os pedir.

**O que está acontecendo**

1. O que era esperado e o que acontece em vez disso? Descreva o que é observado, e não a causa presumida: «na saída HLS a imagem congela a cada poucos minutos», e não «o transcodificador quebrou».
2. Quando o problema apareceu pela primeira vez e quando se manifestou pela última vez? Informe os horários com o fuso horário. Por padrão, o registro `main.log` grava a hora em UTC e sem o ano (Registro do serviço) — faça a correspondência entre um e outro.
3. O problema é constante, periódico ou aconteceu uma única vez? Se for periódico, com que frequência e há algum padrão: hora do dia, carga, uma fonte específica?
4. O problema pode ser reproduzido passo a passo? Se sim, liste os passos.
5. O que mudou pouco antes do surgimento do problema: atualização da build ou do sistema operacional, alteração de configurações, troca de hardware, mudanças na rede ou na fonte?

**Fluxos afetados**

1. Quais fluxos estão afetados — os números dos fluxos no nó? Todos os fluxos estão afetados, uma parte ou apenas um?
2. Qual transporte é usado na entrada e na saída do fluxo afetado, e ele é SPTS ou MPTS? A transcodificação é usada e, se sim, qual backend e qual versão ([Backends e codecs](../streamer/transcoder.md#streamer-transcoder-backends), tela [Sobre o sistema](../webui/administration.md#webui-about), seção «Transcodificadores»)?
3. Quais codecs e qual taxa de bits a fonte tem? Se houver um relatório do analisador (O que anexar), ele responde a esta pergunta.
4. O problema está do lado da entrada ou da saída? Ele aparece nas estatísticas do fluxo ([Estatísticas do fluxo](../webui/streams.md#webui-stream-stats)) — erros de continuidade, comutações para a entrada de reserva, reinícios do buffer?
5. Como a mesma fonte se comporta sem passar pelo nó ou em outro nó? Como outra fonte se comporta no mesmo fluxo?

**Serviço e recursos**

1. O serviço foi reiniciado durante o intervalo do problema? Na tela [Registros](../webui/monitor.md#webui-logs), cada inicialização é marcada com a linha «Início do streamer»; uma execução encerrada sem parada normal é sinalizada separadamente.
2. Quais alertas estão ativos no nó ([Alertas](../webui/monitor.md#webui-alerts))?
3. Qual é a carga do processador, da memória e das interfaces de rede no momento do problema? Tela [Monitor do Sistema](../webui/monitor.md#webui-system), bloco «Histórico».

**O que já foi feito**

1. Quais ações já foram tomadas e quais delas deram resultado: reinício do fluxo ou do serviço, troca de entrada, alteração de configurações?

**Cronologia do incidente**

1. Descreva o curso dos acontecimentos na ordem, com marcas de tempo e fuso horário:

   - o último momento em que tudo funcionava como esperado;
   - as mudanças feitas depois dele — no nó, na rede, na fonte ou no receptor;
   - a primeira manifestação do problema e como ele foi detectado: alerta, reclamação de assinante, observação própria;
   - como o problema evoluiu depois: piorou, desapareceu sozinho, se repetiu;
   - cada ação tomada e o que mudou depois dela;
   - o estado atual no momento da solicitação.

   A cronologia une as respostas às perguntas anteriores em um único quadro e permite comparar os acontecimentos com o registro do nó linha por linha.

## O que anexar

Anexe o que tiver relação com o problema. A lista abaixo traz os materiais mais comuns, e não um conjunto obrigatório.

**O registro do serviço** do intervalo do problema — veja Registro do serviço.

**Os logs do transcodificador**, se a transcodificação estiver envolvida no problema — antes de tudo o «Log anterior» do processo, além do último código de saída e do log atual. Eles ficam apenas na memória do nó e se perdem nas reinicializações; por isso, colete-os primeiro — veja Registros do transcodificador.

**As entradas da tela** [Registros](../webui/monitor.md#webui-logs), filtradas pelo fluxo afetado e pelo intervalo de datas. O texto completo de uma entrada é copiado com o botão «Copiar mensagem».

**Capturas de tela** das estatísticas do fluxo afetado ([Estatísticas do fluxo](../webui/streams.md#webui-stream-stats)) e do monitor do sistema no mesmo intervalo.

**As configurações do fluxo afetado** — somente após a limpeza (Dados privados). Um backup completo da configuração feito na tela [Manutenção](../webui/administration.md#webui-maintenance) contém em texto claro as senhas e chaves de todos os objetos do nó; anexe-o apenas se o suporte pedir, e também após a limpeza.

**Um relatório do analisador sobre a fonte**, se o problema parecer um defeito do próprio fluxo: o utilitário [TS Analyze Perfect Streamer Toolkit v2.3 — TR 101 290](../toolkit/ts_analyze.md#toolkit-ts-analyze) lê UDP ou um arquivo e gera um relatório em texto ou XML.

**Saída de diagnóstico conforme o tipo de problema:**

- licença e chave — a saída do `pss_lic` com a opção `-v` ([PSS Lic Perfect Streamer Toolkit v2.0 — licença do nó](../toolkit/pss_lic.md#toolkit-pss-lic));
- transcodificador por hardware NVIDIA — `nvidia-smi`, Intel — `vainfo --display drm --device /dev/dri/renderD128` ([Transcodificadores](../install/transcoder.md#install-transcoder));
- perdas na recepção de multicast UDP — `netstat -su`, linha `RcvbufErrors` ([Recomendações para o trabalho com multicast UDP](../faq/index.md#faq-multicast-nic)).

## Registro do serviço

O serviço grava seu registro no arquivo `main.log`. O diretório é definido pela chave `log-dir` do arquivo `pss.properties`, por padrão `/var/log/pss`. O arquivo é rotacionado diariamente: os dias anteriores ficam ao lado, em arquivos `main.log.<marca de tempo>`, por isso para um intervalo no passado é preciso o arquivo daquele dia, e não o `main.log` atual.

O horário nas linhas do registro aparece sem o ano e, por padrão, em UTC; o horário local é ativado pela chave `log-time-local` do mesmo arquivo.

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

Os dois últimos comandos não são equivalentes. Se o serviço não subiu de forma alguma, a causa pode estar antes do próprio registro — o diretório dele está inacessível, o `pss.properties` não pode ser lido — e então o `main.log` não terá nem uma linha sobre isso: o arquivo pode ter sobrado da execução anterior e mostrar conteúdo antigo. O serviço imprime essa causa em uma linha que começa com `!!!`, e ela aparece no journal do sistema, ou seja, na saída de `journalctl -u pss`. As linhas comuns do registro só chegam lá também se `log-to-console` ou `log-to-syslog` estiver ativado no `pss.properties`.

O nível de registro é definido na tela [Configurações do servidor](../webui/administration.md#webui-server-settings) — um geral e outros separados para as bibliotecas SRT, RIST e FFmpeg. Entradas e saídas de transportes específicos têm rastreamento próprio — o campo `Trace` ([Campos de entrada e saída por transporte](../webui/io/index.md#webui-io)). Aumente o nível ou ative o rastreamento somente quando o suporte pedir, e restaure o valor anterior após a coleta: um registro detalhado cresce rapidamente.

## Registros do transcodificador

Se a transcodificação estiver envolvida no problema, o registro do processo do transcodificador é o material principal da solicitação: a causa de uma falha de codificação ou decodificação quase sempre só aparece nele.

O processo do transcodificador mantém sempre um registro detalhado; não é preciso ativar o rastreamento separadamente. Mas esse registro não é gravado em arquivo: o nó guarda na memória apenas o final dele, os últimos 256 KB, e só de duas execuções do processo — a atual e a anterior. O registro é aberto na janela [Instância de transcodificador](../webui/monitor.md#webui-transcoder-detail) (tela [Transcodificadores](../webui/monitor.md#webui-transcoders)), no bloco «Log do processo»: «Log atual», «Log anterior» e «Último código de saída». Cada log é obtido com o botão «Copiar».

O mais valioso é o «Log anterior». O processo com falha normalmente já foi reiniciado — pelo temporizador watchdog ou pelo próprio nó — e então é justamente o log anterior que contém a execução encerrada, junto com as mensagens que precederam a falha. O log atual já descreve a nova execução e mostra apenas se o problema se repete.

Daí decorrem as seguintes regras de coleta:

- **Copie o «Log anterior» assim que perceber o problema.** Cada nova execução do processo — reinício pelo watchdog, parada e nova inicialização do fluxo — desloca os logs em uma posição: o atual passa a ser o anterior, e o anterior de antes é apagado. Se a falha se repetir antes de o log ser copiado, o registro da primeira falha será perdido. Reiniciar o serviço ou o nó apaga os dois logs.
- **Não reinicie o fluxo nem o serviço antes de copiar o log** — mesmo que o reinício restabeleça o funcionamento.
- **Anexe junto com ele o último código de saída e o log atual.**
- **Em um processo que está rodando há muito tempo, o início do log já foi descartado.** Se o momento da inicialização for importante — por exemplo, a escolha do dispositivo e do driver —, reproduza o problema após reiniciar o fluxo e copie o log imediatamente.

Uma linha sobre o encerramento do processo permanece também no registro do serviço: quando o transcodificador termina por conta própria, o nó grava no `main.log` um aviso com a última mensagem dele e o código de saída. Essas linhas sobrevivem ao reinício do serviço e permitem encontrar o momento da falha mesmo que o próprio registro do processo já tenha sido perdido:

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

Anexe aos registros do transcodificador o tipo e a versão do backend da tela [Sobre o sistema](../webui/administration.md#webui-about) (seção «Transcodificadores») e a saída de diagnóstico do dispositivo — `nvidia-smi` ou `vainfo` (O que anexar).

## Dados privados

Registros, configurações e capturas de tela contêm dados que não devem ir para a solicitação. Substitua-os antes do envio:

- senhas, frases-senha, chaves e segredos — a lista completa das chaves de configuração que os armazenam está na seção [Valores que não devem ser repassados](../extras/config_file.md#extras-config-file-secrets);
- endereços com credenciais diretamente no link — na fonte de uma entrada e no endereço de publicação em uma plataforma externa;
- endereços IP e nomes de host de fontes, receptores e assinantes, bem como os endereços do próprio nó;
- nomes de assinantes, logins de contas, nomes de canais e dados do cliente, se por si só revelarem informações.

Substitua de forma consistente: um mesmo valor original, em todos os lugares, pela mesma substituição (`10.0.0.5` → `HOST-A`). Assim, no registro limpo continua visível quais linhas pertencem a um mesmo nó e quais a nós diferentes, e a análise não perde o sentido.

Não envie na solicitação credenciais de acesso ao nó ou à interface web dele. Se o acesso for necessário para a análise, a forma de concedê-lo é combinada separadamente.