Detta är ett historiskt versionsspecifikt problem, inte ett aktuellt krav för Jellyfin-konfigurationen. I ZimaOS 1.2.5 lade IceWhale till tjänster för upptäckt av Windows-enheter i LAN samt DLNA-relaterade tjänster. Dessa tjänster använde portarna 1900 och 1901, vilket kunde hindra Jellyfin från att starta eller starta om normalt.
Den ursprungliga officiella lösningen stoppade upptäcktstjänsterna
777-Spider identifierade minidlnad.service och ssdpd.service som de motstridiga ZimaOS-tjänsterna och publicerade tillfälliga kommandon för att stoppa och inaktivera dem. Efter att användaren följt instruktionerna fungerade Jellyfin igen.
Eftersom dessa kommandon publicerades av IceWhale-personal för just denna historiska version är de giltiga källbelägg. De bör inte betraktas som en aktuell standardkonfiguration.
Konflikten återkom efter omstart
Källan rapporterade att Jellyfin slutade fungera igen efter omstart av ZimaOS. Docker-felet visade då att port 1901/tcp redan användes.
Zima-Jerry identifierade ssdpd som den som använde port 1901
Zima-Jerry förklarade att den nyare UPnP-/Windows-tjänsten för enhetssändningar använde port 1901 och att inaktiveringen inte hade sparats som förväntat. Fram till nästa version kunde användaren behöva stoppa ssdpd.service igen efter uppstart.
IceWhale uppgav att porten skulle flyttas
Det officiella svaret uppgav också att port 1901, som användes av ssdpd, hade flyttats i den kommande versionen så att Jellyfin inte längre skulle krocka med upptäcktstjänsten.
ZimaOS 1.3.0 angav senare portkonflikten som åtgärdad
IceWhales versionsinformation för ZimaOS 1.3.0 säger uttryckligen att problemet med att portarna 1900 och 1901 var upptagna åtgärdades för att säkerställa Plex-tillgänglighet. Denna versionsspecifika åtgärd är den viktiga aktuella gränsen: användare av moderna ZimaOS bör inte börja felsöka Jellyfin genom att inaktivera dessa gamla tjänster bara för att en artikel från 2024 rekommenderar det.
Diagnostisera aktuella portkonflikter utifrån det faktiska felet
Om en aktuell Jellyfin-container misslyckas med address already in use, identifiera den exakta porten i Docker-felet och ta reda på vilken värdprocess eller container som använder den. Anta inte att det rör sig om det historiska felet med ssdpd/minidlnad.
DLNA- och upptäcktsportar skiljer sig från Jellyfins webbport
Jellyfins vanliga webbläsargränssnitt använder en annan port än SSDP-/DLNA-upptäckt. En användare kan därför ha ett fungerande webbgränssnitt samtidigt som upptäcktsfunktioner krockar, eller så kan en container misslyckas eftersom appdefinitionen publicerar en värdport som redan används av en annan tjänst.
Varför systemctl disable inte sparades som förväntat
Användaren rapporterade att tjänsterna återkom efter omstart även efter de ursprungliga kommandona för inaktivering. Zima-Jerry bekräftade att ssdpd inte faktiskt förblev inaktiverad i 1.2.5-miljön. Därför krävde den officiella lösningen fortfarande att tjänsten stoppades igen efter uppstart tills korrigeringen på versionsnivå hade släppts.
Docker-felet identifierade den exakta porten
Felet efter omstart innehöll failed to bind port 0.0.0.0:1901/tcp och address already in use. Ett sådant Docker-meddelande är det snabbaste sättet att skilja en portkonflikt från ett fel med Jellyfins databas eller mediebehörigheter.
Begränsa de gamla systemctl-kommandona till ZimaOS 1.2.5
Källans kommandon var officiella för en specifik, tillfällig regression. I en modern ZimaOS-version kan stopp av upptäcktstjänster ta bort funktionalitet utan att lösa den faktiska konflikten. Kontrollera först vem som använder den aktuella porten och ändra sedan den tjänst som verkligen orsakar problemet.
Vanliga frågor om historiska Jellyfin-portar
Vilken ZimaOS-version hade denna dokumenterade konflikt?
ZimaOS 1.2.5.
Vilka tjänster var inblandade?
minidlnad.service och ssdpd.service identifierades av IceWhale-personal.
Åtgärdade IceWhale problemet senare?
Ja. Versionsinformationen för ZimaOS 1.3.0 anger att problemet med att portarna 1900/1901 var upptagna hade åtgärdats.
Bör aktuella användare automatiskt inaktivera dessa tjänster?
Nej. Ta först reda på vem som faktiskt använder den aktuella porten.
