يكون من الآمن مراقبة تحذير Jellyfin فقط عندما يكون نطاق التأثير معروفًا، ولا يتسع سبب التحذير، وتظل عمليات التشغيل والكتابة والاسترداد ناجحة.
هل يظهر التحذير مرة واحدة أثناء الفحص، أم يتكرر مع أخطاء قاعدة البيانات أو الملفات المفقودة أو عمليات إنهاء الذاكرة غير الكافية (OOM) أو فشل إعادة التشغيل؟ سجّل الرسالة الدقيقة والطابع الزمني والإصدار والمسار المتأثر وحِمل العمل النشط قبل اتخاذ القرار. لا تتجاهل التحذير لمجرد أن لوحة المعلومات لا تزال قابلة للوصول.
صنّف التحذير حسب العملية التي قد يتسبب في إتلافها
يمكن عادةً مراقبة التحذيرات المتعلقة بعنصر عمل فني واحد غير متاح أو بإعادة محاولة مؤقتة من العميل إذا نجح الفحص والتشغيل التاليان. أما التحذيرات المتعلقة بانخفاض المساحة الحرة أو عمليات الكتابة في قاعدة البيانات أو فقدان نقطة التحميل أو الأذونات أو الإنهاء المتكرر للعمليات، فلها نطاق فشل أكبر. وقد ارتبط امتلاء وحدة تخزين البيانات بأخطاء SQLite وفقدان سجلات المستخدمين في حوادث حقيقية لـ Jellyfin (أدلة فشل امتلاء القرص).
تحقق مما إذا كان التحذير معزولًا في السجلات أم أن العملية نفسها تغيّر الحالة. إذا أزال الفحص بيانات المكتبة أو أعاد كتابتها أثناء عدم توفر نقطة تحميل، فأوقف المهمة واستعد المسار قبل المتابعة.
بعد التشغيل الأول، قارن الرسالة نفسها بالمهمة المجدولة التالية. يكون التحذير الذي يختفي دون تغيير حِمل العمل أقل خطورة من التحذير الذي يعود أثناء العملية نفسها.
استخدم اختبارين لاتخاذ قرار المراقبة
كرّر سبب التحذير الأصلي مرة واحدة في ظروف مضبوطة، وافحص النظام الفرعي المتأثر: البايتات والـ inodes الحرة للتخزين، وmemory.events لعمليات نفاد الذاكرة، وسجلات ffmpeg للتشغيل، والملكية لفشل الكتابة. يكون التحذير الذي يختفي دون تغيير حِمل العمل أقل خطورة من التحذير الذي يعود في الخطوة نفسها.
راقب الحالة عندما ينجح التشغيل الثاني، ولا يتسع نطاق التحذير، وتتوافر نسخة احتياطية حديثة. أوقف العملية عندما يتكرر التحذير مع فقدان البيانات أو أخطاء قاعدة البيانات أو فشل الكتابة أو حلقة إعادة تشغيل. يساعد مسار تشخيص التشغيل على التمييز بين التحذير وفشل البث الفعلي.
دوّن النتيجة الدقيقة: البايتات والـ inodes الحرة، وحالة الكتابة في قاعدة البيانات، ورمز خروج العملية، أو وضع التشغيل. تحدد هذه النتيجة ما إذا كانت الخطوة التالية هي المراقبة أو الإصلاح أو التراجع.
أوقف العملية واحفظ البيانات وصعّد المشكلة بأمان
أوقف الفحص أو الاستيراد النشط، واحفظ السجلات، وتجنب التنظيف التدميري عندما تكون قاعدة البيانات أو مسار التخزين موضع الاشتباه. استعد المساحة الحرة أو نقطة التحميل المفقودة، ثم أعد التشغيل مرة واحدة بوصفه بوابة للتحقق، وليس حلًا للمشكلة. كرّر حِمل العمل الأصلي وتأكد من أن التحذير لم يعد يؤثر في العملية نفسها.
صعّد المشكلة عندما يستمر التحذير بعد الفحوص القابلة للعكس، أو يتعذر فتح قاعدة البيانات، أو يبلغ القرص أو نظام الملفات أو بيئة تشغيل الحاوية الأساسية عن أخطاء. احتفظ بآخر نسخة احتياطية ناجحة مع مسار الحالة دون تغيير.
إذا نجح الإصلاح، كرّر سبب التحذير الأصلي بعد إعادة تشغيل باردة، وتأكد من عدم عودة التحذير. لا تكفي إمكانية فتح لوحة المعلومات إذا ظل الفحص أو إجراء الكتابة نفسه يفشل.
تأكد من حدود المشكلة بعد إعادة تشغيل نظيفة
أعد تشغيل Jellyfin مرة واحدة بعد الفحص القابل للعكس، ثم كرّر عملية الفحص أو الاستيراد أو التشغيل نفسها التي تسببت في التحذير. أبقِ حِمل العمل ومسار التخزين دون تغيير حتى تكون المقارنة ذات معنى.
راقب الحالة عندما تكتمل العملية، ولا يتسع نطاق التحذير، وتظل النسخة الاحتياطية التالية قابلة للقراءة. أوقف العملية عندما يعود التحذير مصحوبًا بأخطاء في قاعدة البيانات أو التخزين أو الأذونات أو أخطاء متكررة في العمليات.
صعّد المشكلة مع السجلات المحفوظة وآخر حالة ناجحة معروفة عندما يفشل السبب نفسه بعد إعادة التشغيل، أو يتعذر فتح قاعدة البيانات، أو يبلغ نظام الملفات الأساسي عن أخطاء.
الدعم والنصائح
المزيد للقراءة

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

كيفية منع تكرار المهام أو عمليات الاستيراد في Jellyfin
ينشأ العمل المكرر عادةً بسبب تداخل أدوات الجدولة أو وجود أكثر من جهة كتابة؛ عيّن مسؤولًا واحدًا، ومسارًا واحدًا، وفحصًا واحدًا لاكتمال العمل.

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

