هذه مشكلة تاريخية خاصة بإصدار معيّن، وليست متطلبًا حاليًا لإعداد Jellyfin. في ZimaOS 1.2.5، أضافت IceWhale خدمات اكتشاف أجهزة Windows على الشبكة المحلية وخدمات مرتبطة بـ DLNA. وقد شغلت هذه الخدمات المنفذين 1900 و1901، مما كان قد يمنع Jellyfin من البدء أو إعادة التشغيل بشكل طبيعي.
الحل الرسمي الأصلي أوقف خدمات الاكتشاف
حدّد 777-Spider الخدمتين المتعارضتين في ZimaOS، وهما minidlnad.service وssdpd.service، ونشر أوامر مؤقتة لإيقافهما وتعطيلهما. وبعد أن اتبع المستخدم التعليمات، عمل Jellyfin مجددًا.
وبما أن موظفي IceWhale نشروا هذه الأوامر لهذا الإصدار التاريخي المحدد، فهي تُعد مصدرًا موثوقًا. لكن لا ينبغي التعامل معها كإعداد افتراضي حالي.
عاد التعارض بعد إعادة التشغيل
أفاد المستخدم الأصلي بأنه بعد إعادة تشغيل ZimaOS، تعطل Jellyfin مجددًا. وأظهر خطأ Docker حينها أن المنفذ 1901/tcp مستخدم بالفعل.
حدّد Zima-Jerry أن ssdpd هو مالك المنفذ 1901
أوضح Zima-Jerry أن خدمة بث الأجهزة الأحدث المتوافقة مع UPnP/Windows كانت تستخدم المنفذ 1901، وأن عملية التعطيل لم تستمر كما هو متوقع. وحتى صدور الإصدار التالي، ربما كان المستخدم بحاجة إلى إيقاف ssdpd.service مجددًا بعد الإقلاع.
قالت IceWhale إن المنفذ سيُنقل
ذكرت الإجابة الرسمية أيضًا أن المنفذ 1901 الذي تستخدمه ssdpd نُقل في الإصدار القادم، بحيث لا يعود Jellyfin متعارضًا مع خدمة الاكتشاف.
أدرج ZimaOS 1.3.0 لاحقًا تعارض المنافذ ضمن الإصلاحات
تذكر ملاحظات إصدار ZimaOS 1.3.0 من IceWhale صراحةً أنه تم إصلاح إشغال المنفذين 1900 و1901 لضمان توفر Plex. ويُعد هذا الإصلاح على مستوى الإصدار الحد الفاصل المهم حاليًا: لا ينبغي للمستخدمين الذين يشغلون إصدارات حديثة من ZimaOS أن يبدؤوا استكشاف أخطاء Jellyfin بتعطيل تلك الخدمات القديمة لمجرد أن مقالًا من عام 2024 ذكرها.
شخّص تعارضات المنافذ الحالية انطلاقًا من الخطأ الفعلي
إذا فشلت حاوية Jellyfin الحالية مع ظهور العبارة العنوان مستخدم بالفعل، فحدّد المنفذ الدقيق من خطأ Docker، ثم اعرف أي عملية أو حاوية على المضيف تستخدمه. لا تفترض أن المشكلة هي خلل ssdpd/minidlnad التاريخي.
تختلف منافذ DLNA والاكتشاف عن منفذ الويب الخاص بـ Jellyfin
تستخدم واجهة Jellyfin العادية في المتصفح منفذًا مختلفًا عن منفذ اكتشاف SSDP/DLNA. لذلك قد تعمل واجهة الويب لدى المستخدم بينما تتعارض ميزات الاكتشاف، أو قد تفشل الحاوية لأن تعريف التطبيق ينشر منفذًا على المضيف تستخدمه خدمة أخرى بالفعل.
لماذا لم يستمر أمر systemctl disable كما هو متوقع؟
أفاد المستخدم بأن الخدمات عادت بعد إعادة التشغيل حتى بعد تنفيذ أوامر التعطيل الأولية. وأقرّ Zima-Jerry بأن ssdpd لم يكن يتعطل فعليًا بشكل دائم في بيئة الإصدار 1.2.5. ولهذا ظل الحل الرسمي يتطلب إيقاف الخدمة مجددًا بعد الإقلاع إلى أن صدر الإصلاح على مستوى الإصدار.
حدّد خطأ Docker المنفذ الدقيق
تضمن فشل إعادة التشغيل العبارتين failed to bind port 0.0.0.0:1901/tcp وaddress already in use. وتُعد رسالة Docker من هذا النوع أسرع طريقة للتمييز بين تعارض في المنافذ ومشكلة في قاعدة بيانات Jellyfin أو أذونات الوسائط.
أبقِ أوامر systemctl القديمة مرتبطة بـ ZimaOS 1.2.5
كانت أوامر المصدر رسمية لمعالجة تراجع مؤقت ومحدد. وفي إصدارات ZimaOS الحديثة، قد يؤدي إيقاف خدمات الاكتشاف إلى إزالة وظائف دون حل التعارض الفعلي. تحقّق أولًا من الجهة التي تستخدم المنفذ حاليًا، ثم غيّر الخدمة المسؤولة فعلًا.
الأسئلة الشائعة حول منافذ Jellyfin التاريخية
ما إصدار ZimaOS الذي شهد هذا التعارض الموثق؟
ZimaOS 1.2.5.
ما الخدمات المعنية؟
حدّد موظفو IceWhale الخدمتين minidlnad.service وssdpd.service.
هل أصلحت IceWhale المشكلة لاحقًا؟
نعم. تدرج ملاحظات إصدار ZimaOS 1.3.0 مشكلة إشغال المنفذين 1900 و1901 ضمن الإصلاحات.
هل ينبغي للمستخدمين الحاليين تعطيل هذه الخدمات تلقائيًا؟
لا. شخّص أولًا الجهة التي تستخدم المنفذ حاليًا.
