Si tratta di un problema storico specifico di una versione, non di un requisito per le configurazioni Jellyfin attuali. In ZimaOS 1.2.5, IceWhale ha aggiunto i servizi di rilevamento dei dispositivi Windows nella LAN e servizi correlati a DLNA. Questi servizi occupavano le porte 1900 e 1901, impedendo a Jellyfin di avviarsi o riavviarsi normalmente.
La soluzione temporanea ufficiale originale arrestava i servizi di rilevamento
777-Spider ha identificato minidlnad.service e ssdpd.service come i servizi ZimaOS in conflitto e ha pubblicato comandi temporanei per arrestarli e disabilitarli. Dopo aver seguito le istruzioni, l'utente è riuscito a far funzionare nuovamente Jellyfin.
Poiché questi comandi sono stati pubblicati dallo staff di IceWhale per questa specifica versione storica, costituiscono una fonte ufficiale valida. Non devono però essere considerati una configurazione predefinita attuale.
Il conflitto è ricomparso dopo il riavvio
L'utente ha riferito che, dopo il riavvio di ZimaOS, Jellyfin ha smesso nuovamente di funzionare. L'errore Docker mostrava quindi che la porta 1901/tcp era già in uso.
Zima-Jerry ha identificato ssdpd come proprietario della porta 1901
Zima-Jerry ha spiegato che il nuovo servizio di trasmissione UPnP/dispositivi Windows occupava la porta 1901 e che l'operazione di disabilitazione non era rimasta attiva come previsto. Fino al rilascio successivo, l'utente potrebbe aver dovuto arrestare nuovamente ssdpd.service dopo l'avvio.
IceWhale ha dichiarato che la porta sarebbe stata modificata
La risposta ufficiale indicava inoltre che, nella versione successiva, la porta 1901 utilizzata da ssdpd sarebbe stata modificata, così Jellyfin non sarebbe più entrato in conflitto con il servizio di rilevamento.
ZimaOS 1.3.0 ha successivamente indicato il conflitto di porte come risolto
Le note di rilascio ufficiali di ZimaOS 1.3.0 di IceWhale dichiarano esplicitamente che l'occupazione delle porte 1900 e 1901 è stata risolta per garantire la disponibilità di Plex. Questa correzione a livello di release rappresenta l'importante limite temporale attuale: gli utenti di ZimaOS moderno non dovrebbero iniziare a diagnosticare Jellyfin disabilitando quei vecchi servizi solo perché un articolo del 2024 lo suggerisce.
Diagnosticare i conflitti di porte attuali a partire dall'errore effettivo
Se un container Jellyfin attuale non si avvia con l'errore address already in use, identifica la porta esatta indicata dall'errore Docker e determina quale processo o container sull'host la sta utilizzando. Non dare per scontato che si tratti del problema storico legato a ssdpd/minidlnad.
Le porte DLNA e di rilevamento sono diverse dalla porta Web di Jellyfin
La normale interfaccia browser di Jellyfin utilizza una porta diversa da quella usata per il rilevamento SSDP/DLNA. È quindi possibile avere una WebUI funzionante mentre le funzionalità di rilevamento entrano in conflitto, oppure che un container non riesca ad avviarsi perché la definizione dell'applicazione pubblica una porta dell'host già utilizzata da un altro servizio.
Perché systemctl disable non è rimasto attivo come previsto
L'utente ha riferito che i servizi sono ricomparsi dopo il riavvio anche dopo i comandi iniziali di disabilitazione. Zima-Jerry ha riconosciuto che, nell'ambiente 1.2.5, ssdpd non rimaneva effettivamente disabilitato. Per questo la soluzione temporanea ufficiale richiedeva comunque di arrestare nuovamente il servizio dopo l'avvio, fino alla distribuzione della correzione a livello di release.
L'errore Docker ha identificato la porta esatta
Il problema dopo il riavvio includeva failed to bind port 0.0.0.0:1901/tcp e address already in use. Un messaggio Docker di questo tipo è il modo più rapido per distinguere un conflitto di porte da un problema del database Jellyfin o dei permessi sui contenuti multimediali.
Mantieni i vecchi comandi systemctl legati a ZimaOS 1.2.5
I comandi della fonte erano ufficiali per una regressione temporanea specifica. In una versione moderna di ZimaOS, arrestare i servizi di rilevamento può rimuovere funzionalità senza risolvere il conflitto effettivo. Verifica prima quale processo utilizza attualmente la porta, quindi modifica il servizio realmente responsabile.
Domande frequenti storiche sulle porte di Jellyfin
Quale versione di ZimaOS presentava questo conflitto documentato?
ZimaOS 1.2.5.
Quali servizi erano coinvolti?
Lo staff di IceWhale ha identificato minidlnad.service e ssdpd.service.
IceWhale ha risolto il problema in seguito?
Sì. Le note di rilascio di ZimaOS 1.3.0 indicano come risolto il problema di occupazione delle porte 1900/1901.
Gli utenti attuali devono disabilitare automaticamente questi servizi?
No. Prima è necessario diagnosticare quale processo utilizza effettivamente la porta.
