Histórico de versões

versão 2.0.2.362 Beta

06.09.2026

• Menu do módulo CI — o menu próprio do módulo é lido: estado do cartão, assinaturas, número de série, entrada do PIN e itens de serviço estão disponíveis diretamente na tela de hardware — o mesmo que o módulo mostraria na tela do televisor. Ali mesmo surgiu o passaporte do módulo — fabricante, código do produto e tipo de aplicação EN 50221 — e o nó decodifica seu nome, de modo que nomes cirílicos não chegam mais corrompidos (Menu do módulo).

• Desembaralhamento por um módulo CI separado — um módulo em um leitor de cartões autônomo atende qualquer entrada de um fluxo, e não apenas a recepção de uma placa DVB: por ele passa todo o transporte da entrada, ao passo que a lista de programas apenas indica quais deles desembaralhar. O slot é atribuído na própria entrada, e ali mesmo se vê qual entrada o ocupa (CI/CAM na entrada de um fluxo).

• Vários slots CI em uma mesma entrada — o multiplex é conduzido sucessivamente através de vários módulos, com seu próprio conjunto de programas para cada slot. A frequência de relógio do barramento CI é escolhida conforme o bitrate real da entrada, e um slot que tenha ficado ocupado é liberado mediante solicitação a partir da tela de hardware.

• Tabelas de serviço na demultiplexação — as tabelas de rede e de hora e os demais PID de serviço do multiplex de origem passam a obedecer às mesmas chaves mpegts-filter-nit, mpegts-filter-tdt, mpegts-filter-unnecessary e mpegts-filter-cat que nos demais caminhos, em vez de serem descartadas incondicionalmente. Com isso o padrão mudou: um fluxo extraído de um multiplex carrega as tabelas de rede e de hora que antes não carregava — um receptor por trás desse fluxo, e um módulo CI em primeiro lugar, espera vê-las. O comportamento anterior é restabelecido por mpegts-filter-nit.

• Uma descontinuidade de PCR não esvazia mais o buffer de jitter — uma entrada que captou um salto de PCR para a frente desloca o ponto de sincronização em pleno funcionamento, sem drenar a fila, de modo que a descontinuidade custa um único tropeço em vez de um novo enchimento do buffer. A janela a partir da qual um salto conta como descontinuidade é escolhida automaticamente (Sincronização).

• Partida rápida de uma entrada HLS — uma playlist ao vivo é retomada pela cauda: entram na fila apenas os últimos segmentos necessários para o jitter configurado, e não a janela inteira, de modo que a entrada vai ao ar com um atraso de alguns segmentos em vez de uma janela inteira da playlist. Uma playlist concluída (VOD) continua sendo reproduzida desde o início.

• Supressão da oscilação de alertas — um alerta que se levanta e se resolve repetidamente é dobrado em um único incidente: o nó o mantém durante a calmaria e o fecha apenas quando a oscilação de fato cessou. Uma tempestade de repetições não se espalha nem pelo registro nem pelos canais externos. Uma fonte oscilante, uma vez reconhecida, continua reconhecida após a calmaria: a série seguinte dela é mantida desde a primeira repetição.

• Edição de um canal de EPG — ao canal são atribuídos um identificador XMLTV separado do nome exibido e denominações por idioma, e um canal desnecessário é excluído por inteiro: com ele vão suas denominações, seus eventos e sua participação em conjuntos.

• Outras melhorias e correções de erros.

versão 2.0.2.335 Beta

27.08.2026

• Meshwork (multidomínio) — vários servidores são reunidos em domínios nomeados, e o domínio serve de fronteira de isolamento: a filiação dos nós, o catálogo de recursos e os alertas propagam-se somente dentro do próprio domínio, e nada é transmitido entre domínios. Um nó pode integrar vários domínios ao mesmo tempo, sem misturar seus dados. Em detalhes — Meshwork.

• Autodescoberta de nós — basta definir o domínio e um único ponto de entrada: os nós trocam listas de vizinhos e constroem por conta própria uma malha totalmente conectada de ligações diretas. A chave comum do domínio é gerada automaticamente e é transmitida apenas por um canal protegido — TLS ou um segmento confiável da rede local.

• Biblioteca de recursos distribuída — as saídas UDP, RTP, Pro-MPEG e RIST, as entradas multicast UDP, RTP e RIST, bem como as ligações PS1 e SRT são publicadas no catálogo comum do domínio (/data/library): uma lista única de grupos multicast, portas, VLANs, fontes SSM e ligações ponto a ponto com a indicação do nó e do fluxo. Pelo catálogo vê-se quais endereços e portas já estão ocupados, e uma nova entrada é conectada diretamente a partir dele — pela escolha de um fluxo já entregue em outro nó do domínio, sem digitar o endereço manualmente.

• Visão geral dos nós do domínio — para cada nó são exibidos o status, o horário do último contato, o papel, a região, a versão da compilação, o tempo de funcionamento desde a inicialização, a carga de CPU, o tráfego por interface física e o número de fluxos no ar, e para cada ligação entre nós PS1 ou SRT — o bitrate, o RTT, a proporção de retransmissões e perdas e um veredicto sobre o seu estado. Um nó que caiu não desaparece da lista: ele permanece nela como inacessível, junto com o seu alerta, por sete dias, e um nó retirado de operação é removido da visão geral por um comando próprio.

• Operação através de NAT — um nó atrás de NAT participa plenamente do domínio e sem encaminhamento de portas de entrada: ele mesmo se conecta, o ponto de acesso público é montado a partir do endereço efetivamente observado e da porta anunciada, e os vizinhos retransmitem o seu estado por um salto — o nó é visível também para aqueles que não conseguem alcançá-lo diretamente.

• Nome do nó a partir do certificado — um nó sem nome de host configurado anuncia aos seus peers o nome coberto pelo seu próprio certificado, e somente depois que esse nome é resolvido de volta para ele; o resultado da verificação aparece nos dados do servidor como cert-host e cert-host-refused.

• Login automático das ligações dentro do domínio — para as ligações PS1 e SRT entre nós de um mesmo domínio não é necessário criar login e senha para cada ligação: no lado chamador (entrada PS1, entrada SRT, saída SRT no modo caller) basta ativar a configuração «Meshwork peer auth», e a autorização é feita pelo segredo comum do domínio. O nó parceiro confirmado e o seu fluxo ficam visíveis na biblioteca de recursos e na lista de sessões.

• Low-Latency HLS e MPEG-DASH sobre CMAF — novo modo de distribuição «OTT / LL-HLS / DASH»: o multiplexador integrado forma um MP4 fragmentado (CMAF), sobre o qual são entregues MPEG-DASH em /dash e Low-Latency HLS em /llhls; os pacotes adaptativos também são montados para esses formatos. Em detalhes — Modos de distribuição.

• Baixa latência do LL-HLS — a playlist de mídia é dividida em partes, são aplicados o recarregamento bloqueante da playlist e a dica de pré-carregamento, de modo que o player inicia a reprodução sem aguardar que o segmento completo esteja pronto. Os segmentos CMAF transportam Producer Reference Time, o manifesto DASH anuncia UTCTiming e a latência-alvo, e a configuração «Duração-alvo da parte LL (ms)» é aplicada em tempo real, sem reiniciar o fluxo.

• HTTP/3 (QUIC) — HLS, MPEG-DASH, LL-HLS e MPEG-TS over HTTP são entregues sobre QUIC em uma porta UDP própria, com 0-RTT opcional; o cliente solicita a mudança para QUIC pelo parâmetro ?h3. O QUIC só funciona sobre TLS: com o TLS desligado o listener não é levantado nem oferecido ao cliente, e o seu estado real aparece nos dados do servidor HTTP, e não apenas na configuração. As rotas administrativas permanecem somente em TCP.

• Alinhamento dos segmentos pelo IDR — o segmentador distingue o IDR do quadro I comum: em fontes com closed-GOP cada segmento começa por um ponto de entrada pleno, de modo que o player abre o fluxo a partir de qualquer segmento; em fontes com open-GOP o limite é o quadro I mais próximo.

• Proteção de conteúdo (DRM) — a distribuição OTT do fluxo pode ser criptografada: HLS AES-128 com uma chave do próprio servidor ou de um servidor de chaves externo e com rotação opcional por janelas de tempo, ou MPEG Common Encryption (ISO/IEC 23001-7) pelos esquemas cenc e cbcs para CMAF e DASH. A criptografia é executada uma única vez, no momento da formação do segmento, de modo que o arquivo DVR é armazenado criptografado e sobrevive a qualquer número de rotações de chave. Em detalhes — Proteção de conteúdo (DRM).

• Cada conexão MPEG-TS over HTTP é uma sessão própria — a lista de clientes do fluxo agora tem uma linha por conexão com o seu próprio sess-id, os detalhes ficam disponíveis em /data/stream/http-clients/<sess-id>, uma conexão isolada é fechada com POST /data/kick?sess-id=<id> e o limite max-conn é respeitado também com valores maiores que um.

• DVR (arquivo em rede) — cada canal OTT é gravado em disco em paralelo com a distribuição, com a mesma segmentação e sem um gravador separado; no modo de baixa latência o arquivo é mantido em duas linhas, MPEG-TS e CMAF, de modo que a gravação fica disponível no mesmo contêiner que a transmissão ao vivo. Em detalhes — DVR.

• Reprodução do arquivo (VOD) — o arquivo é entregue pelas mesmas URLs HLS, DASH e LL-HLS que a transmissão ao vivo: t=<tempo> ativa o modo VOD e define o início da janela, d=<segundos> — a sua duração. A playlist HLS é então fechada, o manifesto DASH é estático e as interrupções da gravação são apresentadas como períodos separados; os pacotes adaptativos reproduzem o arquivo com os mesmos parâmetros.

• Catch-up por EPG — em vez de t e d basta passar epg=<tempo>: o próprio servidor encontra no canal EPG vinculado o programa que está no ar naquele momento e toma o seu início e a sua duração como limites da janela de reprodução.

• Legendas no arquivo — as faixas WebVTT são gravadas em disco junto com os segmentos e são reproduzidas em VOD pelas mesmas URLs; as janelas sem falas não ocupam espaço em disco.

• Armazenamentos DVR — pode haver vários armazenamentos, cada um com o seu próprio limite de preenchimento e a sua própria ordem de limpeza. A profundidade do arquivo («Retenção (horas)», até 90 dias) e o mínimo protegido são definidos separadamente para cada fluxo, e a limpeza por espaço livre não toca nem no mínimo protegido nem nas janelas das sessões VOD abertas.

• Monitor de DVR — uma tela dedicada mostra o estado e o preenchimento dos armazenamentos, o volume e a profundidade do arquivo por fluxo e as latências de leitura e de gravação, enquanto o histograma de cobertura (/data/dvrstat) assinala não apenas as lacunas do arquivo, mas também a sua causa — perda da entrada, troca do PMT, embaralhamento, acionamento da limpeza. Da mesma tela são apagados o arquivo de um fluxo individual e os diretórios dos fluxos removidos.

• Uma falha de disco do arquivo não para mais o nó — um erro no atendimento ao arquivo DVR fica restrito ao armazenamento e à etapa em que ocorreu: os demais fluxos e as demais linhas de gravação continuam funcionando, e o arquivo afetado é marcado como necessitando de reconstrução.

• Alertador — novo serviço de alertas: cada falha torna-se um incidente que é gerado, atualizado e resolvido automaticamente, enquanto o conjunto ativo deduplicado mostra apenas o que está acontecendo agora. A gravidade é definida por uma escala única — da informativa à que exige intervenção do administrador; tal incidente é resolvido pela confirmação do operador. Em detalhes — Alertas (alerter).

• Catálogo de códigos de falhas — mais de cinquenta tipos de incidentes em uma única lista: os fluxos e as suas entradas e saídas, as violações da TR 101 290, os recursos do nó, os armazenamentos e a saúde da gravação DVR, a recepção DVB e CI/CAM, os transcodificadores, o OTT, os certificados e os nós do domínio. Os limiares de acionamento são configurados na seção de alertas.

• Entrega externa de alertas — os alertas saem para fora do console web: por e-mail via SMTP (STARTTLS, implicit TLS, AUTH), por mensagem no Telegram e pela execução de um comando arbitrário, ao qual o incidente é passado em variáveis de ambiente e como JSON completo na entrada padrão. Cada canal tem o seu próprio interruptor e o seu próprio limiar de gravidade.

• Alertas de todo o domínio — o operador de plantão vê os alertas de qualquer nó a partir de qualquer outro: o conjunto ativo propaga-se junto com o keep-alive e é resolvido assim que desaparece na origem, e cada linha indica o nó de origem. Os alertas de hardware e de sistema permanecem locais por padrão e são promovidos ao nível do domínio por uma configuração separada.

• Registro em banco de dados — as mensagens do serviço são gravadas em SQLite: registros tipados com a fonte e o nível de gravidade, agrupamento das repetições consecutivas em uma única linha com contador, retenção limitada por prazo e por volume. Ao contrário do conjunto ativo de alertas, o registro sobrevive a um reinício.

• Interruptor geral das notificações — com enable desligado nas configurações do alertador, o nó não gera alertas próprios nem envia nada para fora, inclusive os alertas recebidos dos seus peers do domínio; na lista e no fluxo de eventos permanecem apenas os alertas dos peers distribuídos pelo domínio.

• A gravidade de um alerta de entrada/saída segue as consequências — uma entrada que falha enquanto não está conduzindo o fluxo é marcada como Error, ao passo que uma entrada condutora, qualquer saída e uma falha sem transmissão são marcadas como Critical; a avaliação é recalculada enquanto o alerta está aberto e acompanha a comutação para a reserva.

• Cor nas notificações externas — ao texto da mensagem foi acrescentado um marcador de cor do nível (vermelho para erros, amarelo para avisos, verde para a baixa, azul para informativos), e o e-mail sai em duas variantes ao mesmo tempo: texto simples e HTML com uma faixa colorida.

• As notificações no Telegram sobrevivem a uma tempestade — os alertas acumulados são combinados no menor número de mensagens que o limite de 4096 caracteres permite, e diante de uma resposta de limitação de frequência o nó aguarda o tempo indicado e repete o envio em vez de descartar a notificação.

• O atraso da notificação passa a valer para a entrada de reserva — o aviso de que um fluxo está funcionando na sua entrada de reserva só é levantado se a situação durar mais que alert-delay, de modo que uma fonte que se recupera e cai de novo não produz mais uma sequência de aberturas e baixas; com alert-delay igual a zero o comportamento é o anterior.

• Monitor TR 101 290 — controle contínuo da conformidade do fluxo de entrada com a norma: um veredito único («Normal», «Problema», «Verificando…») e um relatório estruturado por prioridades 1, 2 e 3, no qual são indicados, para cada indicador, o item da norma, o valor medido e o limite. Um multiplex MPTS é avaliado por inteiro — por todos os PID, programas e tabelas SI. O fluxo é classificado automaticamente como CBR ou VBR, e as verificações que só fazem sentido com bitrate constante não são avaliadas em uma fonte VBR e não produzem acionamentos falsos. Em detalhes — Monitor TR 101 290.

• Deriva do oscilador de referência — o desvio sistemático da frequência de relógio da fonte é medido por regressão linear em ppm com a tolerância da ISO/IEC 13818-1 de ±30 ppm e é apresentado como uma métrica separada. Um desvio lento é tratado por microdeslocamentos suaves do ponto de sincronização («Compensação da deriva de sincronização», ativada por padrão), de modo que não há solavancos na saída.

• Modelo de buffer T-STD — análise do buffer de vídeo do decodificador de referência conforme a ISO/IEC 13818-1, com contadores de estouro e de esvaziamento para MPEG-2, H.264 e HEVC; a contagem é feita pelo relógio do PCR, e a velocidade de escoamento acompanha o bitrate real do vídeo. É ativado pela configuração «Analisar o buffer de vídeo T-STD».

• Análise para a inserção de publicidade — interpretação das seções SCTE-35 com eventos de emenda, pontos de emenda do nível de transporte com notificação antecipada configurável e indicadores de acesso aleatório. Os dados são exibidos nas estatísticas do fluxo quando a análise profunda está ativada.

• Assistente de reclamações — para um fluxo com violações persistentes é gerado um texto-instrução pronto para um chat de IA, a partir do qual este redige uma carta formal de reclamação ao fornecedor do fluxo: a lista das violações persistentes, os valores medidos, os itens da norma e o impacto sobre o decodificador. A instrução é entregue pela requisição GET /data/stream/<id>/ai-complaint-prompt; o nome do fluxo e o endereço da fonte não são incluídos no texto.

• CI/CAM (EN 50221) — host Common Interface integrado: detecção do módulo, leitura do seu nome e da lista de CA_system_id suportados, seleção dos programas para desembaralhamento e envio do CA_PMT para cada um deles. Um módulo combinado com o receptor DVB desembaralha inline os programas selecionados do multiplex recebido, vários ao mesmo tempo; o estado dos slots e o veredito de cada programa são visíveis na interface.

• Desembaralhador por software BISS-1 / BISS-E — aplica-se não apenas à recepção a partir de uma placa DVB, mas a qualquer entrada de fluxo: a chave é definida para todo o SPTS ou por programas do multiplex e é alterada em tempo real, sem reiniciar a entrada. Na recepção a partir de uma placa DVB o resultado é adicionalmente verificado no próprio fluxo, de modo que uma chave incorreta não parece um desembaralhamento bem-sucedido, mas gera um alerta específico.

• Limpeza do acesso condicional na recepção DVB — por uma configuração separada do adaptador, os PID ECM e EMM são removidos do multiplex recebido pela placa DVB, e os descritores CA dos programas abertos são removidos do PMT: adiante no percurso segue um fluxo FTA limpo. Em caso de perda da chave, a sinalização de acesso condicional é restaurada para que um receptor mais adiante na cadeia possa solicitar acesso novamente.

• Telemetria do transcodificador — para cada codificador são publicadas as informações de mídia da saída recodificada: o formato do quadro, o codec de vídeo, o conjunto de codecs de áudio e o bitrate atual, e para cada processo — a carga de CPU e a memória ocupada.

• RTMP e RTMPS — o canal é publicado em qualquer receptor RTMP, incluindo YouTube e Facebook: vídeo H.264 ou HEVC (HEVC — via Enhanced RTMP) e uma única faixa AAC; para rtmps:// o nó conecta-se como cliente TLS. No sentido inverso, a própria entrada busca o fluxo da fonte rtmp:// ou rtmps:// e remultiplexa FLV para MPEG-TS.

• Comutação de fonte sem interrupção — ao trocar a entrada ativa no emissor, os peers PS1 receptores não se reconectam: a numeração e as marcas de tempo permanecem contínuas, um pico da fila é absorvido pelo descarte dos pacotes mais antigos, e a lacuna é completada pela retransmissão comum.

• Retransmissão adaptativa PS1 — o receptor mede o RTT real até o emissor e ajusta a ele, por conta própria, os intervalos das requisições de repetição; o RTT medido, o intervalo atual de nova requisição e o indicador de latência insuficiente são apresentados nas estatísticas da ligação. A latência do túnel de recepção é definida diretamente em milissegundos, em vez do antigo múltiplo do RTT.

• Os estados «Reconectando» e «Ação do administrador» — uma entrada ou saída que perdeu a sua fonte é reaberta no lugar e permanece no estado «Reconectando» durante todo o tempo das tentativas, gerando um único aviso por episódio em vez de uma mensagem a cada tentativa. Uma causa que a repetição não elimina — porta ocupada, interface ausente, dados que não são MPEG-TS, recusa do SRT por criptografia — o nó transfere para o estado «Ação do administrador» com um alerta persistente, e a edição das configurações é aplicada imediatamente.

• Data do último erro — junto ao texto do último erro de uma entrada ou de uma saída é publicado o seu horário (last-error-ts, o mesmo campo existe também no fluxo de eventos), de modo que uma causa antiga que ficou em uma entrada pausada é vista separadamente da falha atual.

• Diagnóstico quando o conteúdo da entrada é inservível — a mensagem sobre a perda de sincronização MPEG-TS nomeia a causa provável: pacotes foram encontrados, mas estão deslocados por um número conhecido de bytes, ou não há estrutura MPEG-TS alguma; para as entradas PS1 e Pro-MPEG é acrescentada uma dica sobre a frase secreta da criptografia.

• Tamanho real do buffer de recepção — a entrada publica socket-buffer-actual, o tamanho concedido pelo kernel, ao passo que socket-buffer-size continua sendo apenas um pedido e é cortado pelo limite do sistema; a divergência passa a ser vista de imediato em vez de aparecer como perdas em bitrate alto.

• Multiplexador MPTS: identidade original — os programas podem manter os seus PID originais, e a ordem dos programas no PAT, no SDT e no NIT é definida manualmente, de modo que o multiplex é migrado para o Perfect Streamer sem alterar a identidade do fluxo para o equipamento receptor. Os programas com embaralhamento TS são migrados com as suas marcas de tempo originais.

• Numeração automática de PID para SPTS — o enable-autopid junto com o autopid-base move todo o programa para uma janela previsível de 64 identificadores, começando pela PMT e depois vídeo, áudio e os demais fluxos elementares na ordem da tabela original; um programa que não couber na janela mantém integralmente os seus PID originais.

• O tamanho do datagrama é definido em todas as saídas — a configuração packets agora se aplica não só ao SRT, mas também às saídas UDP, RTP, Pro-MPEG e RIST, e na saída para arquivo e para o fluxo padrão define o tamanho do bloco gravado. Os valores padrão coincidem com o comportamento anterior, portanto uma configuração em que a chave nunca foi definida não muda; um valor salvo diferente do padrão era ignorado pelas compilações anteriores e agora entra em vigor no primeiro reinício — verifique-o antes de atualizar.

• Integração com faturamento externo — cada sessão de espectador é autorizada em um sistema externo de faturamento ou CRM, é mantida por reautorização periódica e, ao terminar, é comunicada a esse mesmo sistema: ciclo de vida Start / Interim / Stop no estilo RADIUS; a revogação da assinatura encerra a sessão no meio da exibição. São abrangidos o OTT, o peering PS1 e as saídas SRT, e o próprio sistema de faturamento é conectado por modelos de requisição e de análise da resposta, sem modificação do software.

• Cliente ACME integrado (Let’s Encrypt) — emissão e renovação automática dos certificados para o servidor web, o servidor HTTP/OTT e o servidor EPG: o certificado é solicitado para cada nome de host configurado, a renovação é verificada diariamente e, em caso de insucesso, é gerado um alerta. São suportados uma autoridade certificadora arbitrária e a vinculação externa da conta, e o novo certificado é aplicado sem reiniciar o serviço.

• Parada rápida do serviço — a parada não espera mais por um cliente que deixou de ler os dados: sob a mesma carga o nó termina em 2–4 segundos em vez de cerca de um minuto, por isso um reinício leva segundos e não deixa a transmissão fora do ar.

• pss_lic 2.0 — o utilitário de console para gerenciar a licença passou aos comandos apply, c2v, fingerprint, recipient, keys, detach, rehost e cancel com opções longas: ele aplica uma atualização de licença recebida, exporta o estado da chave para o fornecedor e transfere a licença de um nó para outro, inclusive temporariamente, e aceita qualquer arquivo na entrada padrão e escreve na saída padrão. Em detalhe — pss_lic.

• Edição manual do arquivo de configuração — junto com a documentação é publicado um JSON Schema para pss.json (estrito e compatível) e um guia passo a passo para editar e transferir o arquivo: a configuração de um nó parado pode agora ser editada diretamente e transferida entre instalações e versões, depois de verificado o resultado pelo esquema, ao passo que antes a API HTTP era a única forma suportada. Em detalhe — O arquivo de configuração pss.json.

• Nova interface web — o gerenciamento do nó foi transferido para um novo console, que se abre no endereço do nó (caminho /admin): visão geral, fluxos, monitoramento do sistema, DVB, DVR, transcodificadores, clientes, registro, alertas e todas as configurações do servidor. Diagramas dedicados mostram a topologia do domínio Meshwork e o percurso do fluxo selecionado, das entradas às saídas. A interface anterior foi preservada no endereço /classic. Em detalhes — Interface web.

• Login único no domínio — uma conta pode receber permissão de login automático: após um único login com senha, o navegador abre o painel deste nó sem o formulário de login por 14 dias e sobrevive a uma reinicialização. Seguir um link desse painel passa a sessão para um nó vizinho do domínio se as condições da passagem forem atendidas (Servidor web e contas); um endereço de vizinho digitado à mão não passa a sessão. Um script ou um painel de terceiros apresenta a mesma chave no cabeçalho X-Auth-Token ou no parâmetro auth-token, e um administrador revoga o login automático em todo o domínio de uma só vez.

• CORS para a API administrativa — os nós de um mesmo domínio Meshwork são permitidos sem nenhuma configuração, as demais origens são listadas em web-server/cors-origin (o valor * permite qualquer origem, none desliga o mecanismo), de modo que a interface de um nó acessa a API de outro; uma requisição entre domínios precisa levar o token explicitamente — cookie e Digest não funcionam nela.

• Token da própria sessão — GET /data/auth-token devolve ao cliente o seu próprio token e o prazo absoluto de validade, e em /data/server foi acrescentado o campo web-login-expires, de modo que a interface mostra até quando o login é válido sem ler o próprio token.

• Encerramento de uma sessão de login automático — POST /data/auth-tokens/revoke?login=<login> fecha todas as sessões ativas de uma conta, e ?id=<hex> fecha uma pelo identificador da lista de sessões; na resposta vem o número de sessões fechadas, e a revogação se propaga por todo o domínio.

• Motivo da recusa ao passar para um nó vizinho — se a passagem não resultou em login automático, o nó devolve no endereço um parâmetro jump com o valor no-session, foreign-domain, autologin-off ou token-refused, em vez de mostrar silenciosamente o formulário de senha.

• Atualização em tempo real — o nó publica o seu estado como um fluxo de eventos em /data/events: na conexão chega um instantâneo completo, depois, uma vez por segundo, são atualizados os quadros dos fluxos, dos recursos do sistema, dos clientes e dos adaptadores DVB, enquanto os alertas e as mudanças de estado chegam como eventos. A interface e os painéis externos funcionam sem consulta periódica.

• Ajuda contextual — cada tela e cada janela importante da nova interface dispõem de uma chamada de ajuda que abre a seção da documentação correspondente exatamente ao que está aberto no momento: o botão geral de ajuda — para a tela, o botão «?» no cabeçalho da janela — para essa janela. A seção abre-se no idioma da interface.

• Idiomas, temas e layouts — a interface está traduzida para seis idiomas (russo, inglês, alemão, francês, espanhol, português), suporta os temas claro e escuro e ajusta por conta própria a densidade do layout ao telefone, ao tablet, à estação de trabalho e ao videowall.

• Acesso sem limite do número de conexões — os limites de conexões do destinatário ganharam um terceiro estado, «Sem limite», ao lado de «Protocolo proibido» e «No máximo» com um número; antes o acesso ilimitado era representado por um número deliberadamente grande. Zero continua significando a proibição do protocolo, de modo que o sentido das configurações salvas não muda após a atualização. Em detalhe — Usuário: adicionar e alterar.

• A edição do acesso aos fluxos não afeta sessões alheias — acrescentar um fluxo à lista de permitidos e voltar a uma lista vazia não rompem nenhuma sessão, e estreitar a lista fecha as sessões PS1 e SRT apenas nos fluxos que saíram dela. Antes, qualquer edição da lista desconectava a conta por inteiro em todos os protocolos.

• Ativação da licença pela interface web — a tela «Licença» ganhou uma seção «Ativação»: a exportação do estado da chave para o fornecedor — como arquivo C2V ou para a área de transferência — e a aplicação da chave V2C recebida, por arquivo ou colando o texto. A aplicação da chave reinicia o nó. Em detalhe — Licença.

• Aviso de vencimento da licença — o nó gera um alerta duas semanas antes do fim do prazo e o eleva ao nível que requer intervenção quando o prazo termina. O alerta é replicado pelo domínio, de modo que a licença vencendo de um vizinho é visível de qualquer nó (Alertas (alerter)).

• Uma licença considerada não autêntica para o nó — um nó cuja licença é considerada não autêntica levanta um alerta que requer ação do administrador, reinicia o serviço e a inicialização é recusada: o serviço permanece parado até que haja uma licença autêntica no nó. O alerta é replicado por todo o domínio (Alertas (alerter)).

• Retorno à última configuração operacional — o nó guarda uma cópia das configurações com que iniciou de forma limpa da última vez e, quando o pss.json é inaceitável, sobe com ela — com todos os seus fluxos, e não com as configurações padrão, que não contêm fluxos. O arquivo de arquivos rejeitados foi colocado em ordem: nomes em UTC, sufixo numérico em vez de sobrescrita quando duas falhas caem no mesmo segundo, as vinte cópias mais recentes; o alerta indica diretamente o caminho da cópia arquivada. Em detalhe — Comportamento na inicialização e em erros de configuração.

• A prioridade das entradas é editada com o mouse e pelo teclado — o administrador pode reordenar as entradas de um fluxo arrastando ou com Alt+↑ e Alt+↓, na aba «Entradas» do editor e na linha expandida da lista de fluxos (no telefone a ordem apenas é exibida); uma entrada adicionada fica sempre por último e nunca substitui a principal (Fluxos).

• O número de uma entrada é o seu lugar na lista de redundância — um mesmo número aparece agora na linha do fluxo, na linha expandida, no editor e no texto do alerta. As entradas com o mesmo valor de prioridade mantêm a ordem em que estão registradas, inclusive nas edições posteriores das configurações (Redundância de fontes).

• A falha de uma entrada abandonada lê-se como histórico — a entrada de que o fluxo saiu ao passar para a reserva é parada, mas mantém a sua causa: a interface a exibe como uma linha esmaecida com a idade, e não como uma falha atual, e o alerta sobre o erro dessa entrada é retirado. A causa é então a sua própria, de transporte, se a entrada chegou a informá-la (Redundância de fontes).

• Ordenação da lista de clientes — na tela «Clientes» o cabeçalho da coluna ordena a lista: as colunas numéricas abrem em ordem decrescente, as de texto de A a Z, e o terceiro clique devolve a ordem do nó. É ordenada toda a lista encontrada, e não a página exibida (Clientes).

• Ir para o fluxo a partir da tela de transcodificadores — a linha do decodificador e de cada codificador ganhou um botão que abre a lista de fluxos no fluxo em questão. Disponível em qualquer papel (Transcodificadores).

• O programa do demultiplexador é escolhido em uma lista também para um adaptador DVB — um adaptador em funcionamento publica o seu multiplex, e o campo «PNR» oferece os seus programas com os nomes, incluindo os programas internos T2-MI sob os seus números compostos (Demultiplexador (demuxer)). O adaptador de uma entrada dvb também é escolhido pelo nome, em vez de ser digitado como número de registro (Adaptador DVB (dvb)).

• A recepção DVB não depende mais da compilação — o tipo de entrada dvb e a seção de adaptadores DVB estão disponíveis em qualquer nó; a única condição é um frontend detectado e um driver que permita ao serviço abri-lo (Receptor DVB).

• O scanner DVB cede o sintonizador a um adaptador configurado — um multiplex encontrado pode ser aplicado sem esperar o fim da passagem: o adaptador toma o sintonizador e sobe em cerca de um segundo, enquanto a varredura termina como cancelada, mantendo os seus resultados na tela. Uma passagem é interrompida com o botão «Parar» e ao fechar a janela (Pesquisa).

• Os painéis do panorama do nó seguem a presença do subsistema — «Transcodificadores» e «Adaptadores DVB» aparecem no panorama onde existe o próprio equipamento ou as instâncias, ou onde há uma falha a relatar. Em um nó sem transcodificadores e sem sintonizador esses painéis não existem, e tampouco a entrada para as suas seções a partir do panorama (Visão geral do nó).

• Endereços das interfaces no monitor do sistema — o cartão «Rede» e os gráficos de histórico levam o endereço IPv4 da interface quando o nó o informa, incluindo as VLANs aninhadas (Monitor do Sistema).

• O caminho de um armazenamento DVR é escrito sem separador final — a interface e a API HTTP rejeitam esse valor: duas grafias de um mesmo diretório passariam pela verificação de unicidade como dois armazenamentos diferentes (Armazenamentos DVR).

• O pacote precisa do serviço de proteção 10.33 ou mais recente — o pstreamer fornece as bibliotecas de nova geração do sistema de proteção, e um aksusbd mais antigo não as aceita (Requisitos do sistema). O serviço está no mesmo repositório e é instalado junto com o pacote, mas a sua atualização é irreversível, qualquer que seja o tipo de chave — o procedimento e as consequências estão descritos nas páginas de instalação (Instalação em sistemas da família RHEL, Instalação em sistemas da família Debian).

• Seleção explícita do PLP em DVB-T2 — o campo «Stream id (ISI/PLP)» ganhou o valor «auto» (-1): nenhum filtro é aplicado, o sintonizador toma o fluxo padrão do driver, e um adaptador novo é criado exatamente assim. Um zero explícito passou com isso a ser uma seleção real do fluxo zero, e não «não definido», de modo que um adaptador com zero salvo nas configurações passará, após a atualização do nó, a receber apenas esse fluxo (Adaptadores).

• O scanner encontra os PLPs — o campo «Verificar PLP até» percorre os PLPs nos transponders DVB-T2 e exibe cada um encontrado em uma linha separada com a sua própria lista de programas; o número é transferido para o adaptador criado, e as estatísticas do adaptador ganharam uma linha «PLP / ISI» (Pesquisa).

• Busca nos catálogos do scanner — centenas de satélites e faixas regionais estão ordenados por nome e são filtrados por uma cadeia de busca; uma linha já selecionada não desaparece da lista, seja lá o que for digitado (Varredura DVB).

• Correção da referência ao PCR na PMT — uma nova configuração MPEG-TS para fontes cuja tabela não declara um PCR utilizável: o nó declara na PMT o PID em que o PCR é realmente transmitido (Modificação do fluxo).

• Reconstrução do buffer de jitter após uma queda da fonte — uma entrada que sobreviveu a uma parada da sua fonte já não segue com uma fila quase vazia, repassando às saídas cada nova falha: o nó reconstrói o buffer uma única vez, ao custo de um único corte (Sincronização).

• Modo de controle de bitrate do codificador de vídeo — o transcodificador ganhou a escolha entre uma taxa constante e dois modos variáveis: o número informado é lido como o bitrate médio (os picos chegam a uma vez e meia esse valor) ou como um teto rígido (a taxa média fica então em dois terços dele). O número continua sendo apenas um — o codificador deduz o segundo limite a partir de uma relação fixa entre pico e média de 1,5. Nos modos variáveis o codificador deixa de preencher o fluxo elementar, de modo que a economia de banda só ocorre onde o fluxo receptor não nivela o bitrate de volta (Configurações do codificador).

• O reinício do transcodificador é explicado no registro — cada reinício do processo filho indica a sua causa e o seu código de saída no nível «Notificação», e não em silêncio no rastreamento. Além disso, o nó deixou de reabrir indefinidamente um canal que não responde: após duas tentativas malsucedidas, ele solicita um novo processo (Controle do funcionamento).

• Um fluxo excluído aparece no editor aberto — se um fluxo for excluído do nó enquanto o seu editor ou o seu esquema de processamento está aberto, o nó informa isso em uma linha própria, e salvar deixa de estar disponível com a mesma razão indicada ao lado do botão. Antes, todas as listas desse fluxo simplesmente se esvaziavam, o que parecia um fluxo sem entradas e saídas configuradas (Configurar fluxo).

• Um salvamento recusado indica a sua causa — em vez de uma única frase geral para todos os casos, o formulário informa o que exatamente impediu: um tempo de espera de resposta esgotado, uma proibição por papel ou a própria recusa do nó, com as palavras dele.

• Rótulos e seleção de PID nas regras de filtragem — cada número é rotulado com o seu tipo e o seu codec e, em um multiplex, também com o programa a que pertence; a linha de adição ganhou a lista dos PIDs que a fonte realmente transporta. A entrada manual permanece: o transporte pode levar um PID sobre o qual nada foi decodificado (Editor de entrada e saída).

• As telas DVB mostram o número de programa endereçável — para um serviço dentro de uma portadora T2-MI, a lista de programas do adaptador e as suas estatísticas trazem o PNR composto, o mesmo pelo qual o programa é endereçado na seleção do demultiplexador, do BISS e do CAM. O número próprio dentro da portadora repete-se em cada portadora de um transponder com grupos espelhados e não aponta para nada (Estatísticas do adaptador).

• Um slot BISS é sempre oferecido como lista — os programas abertos entraram nela por último, marcados com · clear ·, de modo que em um multiplex sem um único programa codificado a lista já não fica vazia: a chave costuma ser informada com antecedência, e um feed de eventos fica aberto entre os eventos (Desembaralhamento).

• Das estatísticas do fluxo ao transcodificador e à sua fonte — se a entrada ativa de um fluxo foi criada por um transcodificador, o seu valor tornou-se um link para a tela de transcodificadores com a linha da instância correspondente expandida, e ao lado surgiu uma etiqueta com o nome do fluxo que essa instância decodifica. Ambos os links estão disponíveis em qualquer papel (Estatísticas do fluxo).

• Limites das execuções no registro — cada início do serviço é marcado no fluxo por uma linha própria com o momento do início e a compilação em que a execução subiu: a atual traz ao lado o seu tempo de atividade, as anteriores indicam quanto tempo a execução funcionou e quanto tempo o nó ficou parado até o início seguinte, e uma execução encerrada sem parada normal é assinalada à parte. O separador é colocado mesmo com o filtro por gravidade ativado (Registros).

• Limite de tamanho da base de estatísticas — a base de métricas é limitada não apenas pela janela de retenção, mas também pelo tamanho. O nó presta contas da última limpeza — quanto de histórico restou, qual é o tamanho da base e quanto durou a limpeza — e informa expressamente se o limite de tamanho se mostrou mais rígido do que a janela configurada (Configurações do servidor).

• Os valores ajustados ao limite durante a carga são anunciados de imediato — se o nó, ao ler as configurações, puxou um valor até o limite admissível, ele informa isso na tela logo após a inicialização, e não apenas com uma linha no registro (Comportamento na inicialização e em erros de configuração).

• Uma licença de geração obsoleta não é aceita — um nó com uma licença autêntica da geração anterior não inicia e levanta um alerta próprio. Não se trata de prazo vencido nem de falsificação: a geração 2 é aceita apenas como licença de teste temporária, por isso uma licença perpétua dessa geração é recusada de imediato, em vez de viver até a sua data (Catálogo de códigos de alerta).

• O preenchimento automático calcula o alvo pelo conteúdo — no modo automático de bitrate o nó parte da taxa real do conteúdo, e não da sua própria saída, de modo que o alvo já não sobe sem retorno e volta a descer assim que o conteúdo cabe novamente na taxa configurada (Controle de bitrate).

• A janela de compensação de deriva é proporcional ao buffer — a janela suave é limitada a um quarto do tamanho alvo do buffer de jitter, mas nunca abaixo de 100 ms: uma entrada com o buffer padrão já não trabalha sem folga, a compensação recupera a sincronização mais cedo, e a reconstrução de emergência do buffer ao esvaziar finalmente é acionada (Sincronização).

• Outras melhorias e correções de erros.