This is a historical version-specific issue, not a current Jellyfin setup requirement. In ZimaOS 1.2.5, IceWhale added Windows LAN device discovery and DLNA-related services. Those services occupied ports 1900 and 1901, which could prevent Jellyfin from starting or restarting normally.
The Original Official Workaround Stopped Discovery Services
777-Spider identified minidlnad.service and ssdpd.service as the conflicting ZimaOS services and posted temporary stop/disable commands. After the user followed the instructions, Jellyfin worked again.
Because these commands were posted by IceWhale staff for this exact historical release, they are valid source evidence. They should not be treated as a current default configuration.
The Conflict Returned After Reboot
The source user reported that after restarting ZimaOS, Jellyfin failed again. The Docker error then showed port 1901/tcp was already in use.
Zima-Jerry Identified ssdpd as the Port 1901 Owner
Zima-Jerry explained that the newer UPnP/Windows device broadcasting service occupied port 1901 and that the disable operation had not persisted as expected. Until the next release, the user might need to stop ssdpd.service again after boot.
IceWhale Said the Port Would Be Moved
The official reply also said the 1901 port used by ssdpd had been moved in the upcoming release so Jellyfin would no longer collide with the discovery service.
ZimaOS 1.3.0 Later Listed the Port Conflict as Fixed
IceWhale's ZimaOS 1.3.0 release notes explicitly say that occupation of ports 1900 and 1901 was fixed to ensure Plex availability. That release-level fix is the important current boundary: users on modern ZimaOS should not begin troubleshooting Jellyfin by disabling those old services merely because a 2024 article says so.
Diagnose Current Port Conflicts from the Actual Error
If a current Jellyfin container fails with address already in use, identify the exact port from the Docker error and determine which host process or container owns it. Do not assume it is the historical ssdpd/minidlnad bug.
DLNA and Discovery Ports Are Different from the Jellyfin Web Port
Jellyfin's normal browser interface uses a different port from SSDP/DLNA discovery. A user can therefore have a working WebUI while discovery features collide, or a container can fail because the app definition publishes a host port that another service already owns.
Why systemctl disable Did Not Persist as Expected
The user reported that the services returned after reboot even after the initial disable commands. Zima-Jerry acknowledged that ssdpd was not really staying disabled in the 1.2.5 environment. This is why the official workaround still required stopping the service again after boot until the release-level fix shipped.
The Docker Error Identified the Exact Port
The reboot failure included failed to bind port 0.0.0.0:1901/tcp and address already in use. That kind of Docker message is the fastest way to distinguish a port collision from a Jellyfin database or media-permission failure.
Keep the Old systemctl Commands Tied to ZimaOS 1.2.5
The source commands were official for a specific temporary regression. On a modern ZimaOS build, stopping discovery services can remove functionality without solving the actual conflict. Check the current port owner first, then change the service that is genuinely responsible.
Historical Jellyfin Port FAQ
Which ZimaOS version had this documented conflict?
ZimaOS 1.2.5.
Which services were involved?
minidlnad.service and ssdpd.service were identified by IceWhale staff.
Did IceWhale fix it later?
Yes. ZimaOS 1.3.0 release notes list the 1900/1901 occupation issue as fixed.
Should current users disable those services automatically?
No. Diagnose the actual current port owner first.
