Este é um problema histórico específico de uma versão, não um requisito das configurações atuais do Jellyfin. No ZimaOS 1.2.5, a IceWhale adicionou serviços de deteção de dispositivos Windows na LAN e serviços relacionados com DLNA. Esses serviços ocupavam as portas 1900 e 1901, o que podia impedir o Jellyfin de iniciar ou reiniciar normalmente.
A solução oficial original interrompia os serviços de deteção
777-Spider identificou minidlnad.service e ssdpd.service como os serviços do ZimaOS em conflito e publicou comandos temporários para os parar e desativar. Depois de o utilizador seguir as instruções, o Jellyfin voltou a funcionar.
Como estes comandos foram publicados por membros da equipa da IceWhale para esta versão histórica específica, constituem uma fonte válida. Não devem ser tratados como uma configuração predefinida atual.
O conflito regressou após o reinício
O utilizador da fonte relatou que, depois de reiniciar o ZimaOS, o Jellyfin voltou a falhar. O erro do Docker mostrou então que a porta 1901/tcp já estava a ser utilizada.
A Zima-Jerry identificou o ssdpd como proprietário da porta 1901
A Zima-Jerry explicou que o novo serviço de transmissão de dispositivos UPnP/Windows ocupava a porta 1901 e que a operação de desativação não tinha persistido como esperado. Até à versão seguinte, o utilizador poderia ter de parar novamente o ssdpd.service após o arranque.
A IceWhale afirmou que a porta seria alterada
A resposta oficial também indicou que a porta 1901 utilizada pelo ssdpd seria alterada na próxima versão, para que o Jellyfin deixasse de entrar em conflito com o serviço de deteção.
O ZimaOS 1.3.0 indicou posteriormente o conflito de portas como corrigido
As notas de lançamento oficiais do ZimaOS 1.3.0 da IceWhale afirmam explicitamente que a ocupação das portas 1900 e 1901 foi corrigida para garantir a disponibilidade do Plex. Esta correção ao nível da versão é o limite atual importante: os utilizadores de versões modernas do ZimaOS não devem começar a diagnosticar problemas do Jellyfin desativando esses serviços antigos apenas porque um artigo de 2024 o recomenda.
Diagnostique os conflitos atuais de portas a partir do erro real
Se um contentor atual do Jellyfin falhar com address already in use, identifique a porta exata no erro do Docker e determine qual o processo ou contentor no anfitrião que a está a utilizar. Não assuma que se trata do erro histórico do ssdpd/minidlnad.
As portas de DLNA e deteção são diferentes da porta Web do Jellyfin
A interface normal do Jellyfin no navegador utiliza uma porta diferente da utilizada pela deteção SSDP/DLNA. Assim, um utilizador pode ter uma WebUI funcional enquanto as funcionalidades de deteção entram em conflito, ou um contentor pode falhar porque a definição da aplicação publica uma porta do anfitrião que já está a ser utilizada por outro serviço.
Porque é que o systemctl disable não persistiu como esperado
O utilizador relatou que os serviços regressaram após o reinício, mesmo depois dos comandos iniciais de desativação. A Zima-Jerry reconheceu que o ssdpd não permanecia realmente desativado no ambiente 1.2.5. Por isso, a solução oficial exigia continuar a parar novamente o serviço após o arranque até ser disponibilizada a correção ao nível da versão.
O erro do Docker identificou a porta exata
A falha após o reinício incluía failed to bind port 0.0.0.0:1901/tcp e address already in use. Este tipo de mensagem do Docker é a forma mais rápida de distinguir um conflito de portas de uma falha da base de dados do Jellyfin ou de permissões de acesso aos ficheiros multimédia.
Mantenha os comandos systemctl antigos associados ao ZimaOS 1.2.5
Os comandos da fonte eram oficiais para uma regressão temporária específica. Numa versão moderna do ZimaOS, parar os serviços de deteção pode remover funcionalidades sem resolver o conflito real. Verifique primeiro qual é o proprietário atual da porta e, em seguida, altere o serviço genuinamente responsável.
Perguntas frequentes históricas sobre as portas do Jellyfin
Que versão do ZimaOS tinha este conflito documentado?
ZimaOS 1.2.5.
Que serviços estavam envolvidos?
Os membros da equipa da IceWhale identificaram o minidlnad.service e o ssdpd.service.
A IceWhale corrigiu o problema posteriormente?
Sim. As notas de lançamento do ZimaOS 1.3.0 indicam que o problema de ocupação das portas 1900/1901 foi corrigido.
Os utilizadores atuais devem desativar automaticamente esses serviços?
Não. Diagnostique primeiro qual é o proprietário atual da porta.
