امنع تكرار مهام Jellyfin وعمليات الاستيراد بمنح كل عملية مُجدولًا واحدًا، وكاتبًا واحدًا، ومسارًا واحدًا للمراقبة، وإشارة إكمال واحدة.
هل تتكرر عمليات الفحص أو الاستيراد أو مهام البيانات الوصفية بعد إعادة التشغيل أو إعادة إنشاء الحاوية أو إضافة أتمتة جديدة؟ سجّل اسم المهمة ووقت البدء ومعرّف الحاوية والمُجدول والدليل المراقَب والمخرجات قبل تعطيل أي شيء. يزيل الإصلاح الآمن تداخل الملكية بدلًا من إخفاء الإدخال المكرر.
اعثر على كل مُجدول يمكنه بدء العمل نفسه
تحقق من المهام المجدولة في Jellyfin، وخطافات إعادة تشغيل الحاويات، ومهام cron أو مؤقتات systemd على المضيف، والمعالجة اللاحقة في مدير التنزيلات، وأي خدمة جانبية تستدعي واجهة API. قارن الطوابع الزمنية ومعرّفات العمليات لتشغيلين. إذا بدأت المهمتان عند الحدث نفسه، عطّل المشغّل الثانوي واترك المهمة الأساسية دون تغيير.
يمكن لمهام Jellyfin أن تعمل دوريًا أو يدويًا، وقد تُنفَّذ مهام بدء التشغيل قبل أن تصبح مشاركة الشبكة جاهزة (مرجع توقيت المهام). تعامل مع جاهزية نقطة التحميل باعتبارها متطلبًا أساسيًا بدلًا من السماح باستيراد ثانٍ للتعويض.
تحقق مما إذا كان التكرار يظهر بعد بدء التشغيل أو خطاف ويب أو إعادة محاولة يدوية. يحدد المشغّل الجهة المالكة التي يجب تعطيلها؛ إذ إن إيقاف كل المهام المجدولة يخفي السبب دون منع تكراره.
امنح كل مسار كاتبًا واحدًا وهوية مستقرة واحدة
تأكد من أن أداة تنزيل أو استيراد واحدة فقط تنقل الملفات إلى المكتبة، ومن أن كل حاوية ترى المسار الأساسي نفسه. قد تستورد حاويتان لهما عمليات ربط مختلفة الملف نفسه باعتباره هويتين مختلفتين. قارن رقم inode وقيمة checksum والمسار والملكية لزوج واحد مكرر قبل حذف أي شيء.
إذا أُعيدت تسمية الملف المصدر أو أُعيد تنسيقه، فقد يرى Jellyfin عنصرًا جديدًا بدلًا من تحديث. نفّذ نقلًا مضبوطًا، وأجرِ فحصًا واحدًا، وتحقق من عدد العناصر المتوقع قبل إعادة تمكين الأتمتة.
قارن تسميات الحاويات النشطة والمسارات المراقَبة، وليس ملف الإعدادات الموجود على القرص فقط. فقد تواصل حاوية قديمة تشغيل مراقب متقادم بعد نشر جديد.
تحقق من الوقاية أثناء إعادة التشغيل وإعادة المحاولة
بعد تغيير مشغّل واحد، أعد تشغيل الحزمة وانتظر حلول نافذة الجدولة مرة واحدة. أكد وجود عملية واحدة، وحدث استيراد واحد، وتغيير واحد في قاعدة البيانات، وملف نهائي واحد. ثم كرر تشغيلًا فاشلًا أو متقطعًا للتحقق من أن إعادة المحاولة لا تطلق نسخة ثانية.
صعّد المشكلة عندما يستمر التكرار رغم وجود مُجدول واحد ومسار واحد، أو تحتوي قاعدة البيانات على هويات متعارضة، أو تعيد إضافة برمجية إنشاء المهام مرارًا. احتفظ بالوسائط الأصلية ونسخة احتياطية من قاعدة البيانات حتى ينجح اختبار التنظيف والوقاية.
بعد إزالة الكاتب الثانوي، نفّذ استيرادًا عاديًا واحدًا وإعادة محاولة واحدة لتشغيل متقطع. النتيجة المتوقعة هي حدث واحد في قاعدة البيانات وملف نهائي واحد لكل عنصر مصدر.
أكد قاعدة الوقاية بعد إعادة التشغيل
أعد تشغيل الحزمة وانتظر طوال نافذة مجدولة واحدة مع تمكين المُجدول المختار فقط. سجّل العملية والمسار وحدث قاعدة البيانات حتى تصبح حدود الملكية قابلة للرصد.
أبقِ الإعدادات كما هي عندما لا تطلق إعادة المحاولة استيرادًا ثانيًا وتحتوي المكتبة على عنصر صالح واحد. أعد تمكين خدمة أتمتة واحدة في كل مرة إذا كانت هناك حاجة إلى خدمة أخرى.
صعّد المشكلة عندما يعود التكرار رغم وجود كاتب واحد، أو تحتوي قاعدة البيانات على هويات متعارضة، أو تعيد إضافة برمجية إنشاء المهام المعطلة.
الدعم والنصائح
المزيد للقراءة

كيفية تحسين اتصالات قاعدة بيانات Jellyfin للحاويات المتزامنة
ابدأ بمالك واحد لقاعدة البيانات، وقِس سلوك القفل في SQLite؛ ولا تُضف واجهة خلفية مختلفة إلا عندما يبرّر التزامن والاسترداد هذا التعقيد.

كيفية إصلاح Jellyfin بعد امتلاء وحدة تخزين قاعدة البيانات الخاصة به
أوقف عمليات الكتابة، وحافظ على قاعدة البيانات وملفات WAL، وحرّر مساحةً دون حذف الحالة عشوائيًا، ثم تحقّق من السلامة والتكامل ومن عبء العمل الأصلي.

لماذا يعيد Jellyfin إنشاء الملفات المفقودة بمالكٍ غير صحيح؟
عادةً ما ينشأ خطأ الملكية من عدم تطابق الهوية أو استخدام مسار استيراد مختلف؛ تحقّق من مستخدم الحاوية النشط قبل تغيير الأذونات.

