Se o Plex funcionar através de um caminho de rede, mas falhar através de outro, mantenha a configuração do servidor inalterada e teste o caminho que muda.
As interfaces Wi-Fi, Ethernet e VPN podem utilizar IPs, servidores DNS, rotas, MTUs, VLANs e políticas de firewall diferentes, mesmo no mesmo cliente. Uma alteração abrangente no servidor não é o primeiro passo adequado quando os mesmos conteúdos multimédia e a mesma conta funcionam através de um dos caminhos. Compare a acessibilidade direta do servidor, a resolução DNS, a seleção de rotas e o modo de reprodução em cada interface.
Compare o endereço e a rota antes das definições do Plex
A interface com falhas pode aceder a uma sub-rede diferente ou escolher uma rota predefinida diferente. Verifique o IP e a rota do servidor a partir do cliente, em vez de confiar no nome da rede.
Quando a Ethernet e o Wi-Fi estão ativos, as métricas de rota podem fazer com que as interfaces escolham caminhos diferentes para o mesmo destino; por isso, concentre o diagnóstico inicial no encaminhamento e na política das interfaces, e não nas definições do Plex.
Faça ping ou estabeleça uma ligação ao endereço do servidor através de ambos os caminhos, compare o IP e a sub-rede do cliente e verifique a rota utilizada para a porta 32400. Se a Ethernet não conseguir alcançar diretamente o servidor, mantenha a correção na camada de rede.
Verifique o DNS e o encaminhamento da VPN separadamente
Uma VPN pode alterar tanto a prioridade das rotas como o DNS sem alterar a aplicação Plex. O tunelamento dividido também pode enviar as respostas por uma interface diferente daquela que recebeu o pedido.
O tunelamento dividido pode falhar quando o tráfego de resposta sai pela rota da VPN em vez de sair pela interface que recebeu o pedido, interrompendo um caminho Plex que, de outro modo, seria válido.
Desative a VPN apenas durante o tempo necessário para estabelecer um resultado de controlo, volte a ativá-la e compare as tabelas de encaminhamento. Corrija o encaminhamento assimétrico ou a política de tunelamento dividido antes de alterar as definições de multimédia ou da base de dados.
Teste a MTU quando os pedidos pequenos funcionam, mas as transmissões ficam bloqueadas
Um caminho pode permitir a passagem de tráfego de controlo pequeno, enquanto os pacotes maiores são fragmentados ou atingem o tempo limite. Este padrão é especialmente relevante em túneis VPN e em algumas ligações móveis ou de operadores de Internet.
A conectividade parcial pode resultar de falhas do Plex sensíveis à MTU num transporte, enquanto outro caminho funciona, tornando o tamanho dos pacotes num teste específico para bloqueios relacionados com a VPN ou com o operador de Internet.
Utilize um teste de MTU do caminho ou reduza temporariamente a MTU do túnel de forma controlada. Se a reprodução estabilizar sem qualquer alteração no Plex, mantenha o diagnóstico na camada de transporte.
Volte a testar o Plex apenas depois de a conectividade básica estar estável
Quando a acessibilidade direta, a rota, o DNS e a MTU forem consistentes, teste o mesmo conteúdo do Plex e a mesma qualidade através de cada caminho. Isto evita confundir uma correção de rede com uma alteração de transcodificação no cliente.
Antes de voltar às definições do Plex, confirme que não existem erros nem saturação na rede no caminho reparado; em seguida, reproduza o mesmo conteúdo e a mesma qualidade mantendo estável a variável de rede.
Se o caminho de rede estiver estável, mas um dos clientes continuar a falhar, prossiga com a verificação da compatibilidade do cliente ou do estado em cache. Mantenha um caminho de transmissão remota do Plex conhecido como controlo, em vez de reabrir as definições de rede abrangentes do servidor.
Suporte e Dicas
Mais para Ler

Deve fazer uma cópia de segurança do Jellyfin em funcionamento ou parar primeiro o serviço?
Prefira cópias de segurança com o serviço parado, pela sua simplicidade; utilize instantâneos em funcionamento apenas quando o estado da aplicação for capturado de...

Porque é que o Jellyfin funciona a altas temperaturas ou faz ruído quando ninguém está a transmitir?
O calor em inatividade normalmente indica atividade em segundo plano ou uma carga de trabalho de um anfitrião partilhado; por isso, identifique o processo...

Quando deve reconstruir em vez de reparar o Jellyfin?
Escolha recriar em vez de reparar quando o problema for a divergência do ambiente de execução e o estado persistente estiver salvaguardado; não «recrie»...

