عادةً ما يرجع ارتفاع استهلاك Jellyfin للمعالج بعد التحديث إلى أحد أربعة أسباب: أعمال بدء التشغيل/قاعدة البيانات، أو مهام المكتبة المجدولة، أو تحويل الترميز البرمجي أو الجزئي، أو إضافة/مهمة في الخلفية غيّرت سلوكها مع الإصدار الجديد. لا تفترض أن التحديث جعل Jellyfin أثقل بشكل دائم قبل تحديد العملية والمهمة التي تستهلكان المعالج.
أسرع طريقة للتشخيص هي مقارنة التوقيت وعبء العمل. إذا كان استهلاك المعالج مرتفعًا لبضع دقائق فقط بعد بدء التشغيل، راقب سجلات بدء التشغيل والمهام. وإذا ارتفع فقط أثناء التشغيل، افحص البث النشط ومسار FFmpeg. أما إذا ظل مرتفعًا دون أن يشاهد أحد شيئًا، فتحقق من المهام المجدولة والإضافات. غيّر متغيرًا واحدًا في كل مرة، ثم أعد إنتاج الحالة نفسها لتتمكن من التمييز بين مهمة مؤقتة بعد التحديث وتراجع مستمر في الأداء.
افصل بين أعمال بدء التشغيل واستهلاك المعالج في الحالة المستقرة
أعد تشغيل Jellyfin مرة واحدة خلال فترة هادئة، وسجّل المدة التي يظل فيها استهلاك المعالج مرتفعًا. راقب سجل الخادم بحثًا عن رسائل الترحيل، أو تحسين قاعدة البيانات، أو تحميل الإضافات، أو ما يتعلق بالمكتبة، ثم انتظر حتى تستقر واجهة الويب والأعمال المجدولة قبل تقييم خط الأساس الجديد.
تتضمن المهام المجدولة ومهام بدء التشغيل الافتراضية في Jellyfin فحص المكتبة، واستخراج الإطارات المفتاحية، وتحسين قاعدة البيانات، وتنظيف ذاكرة التخزين المؤقت، وتحديث الإضافات. كما تعمل بعض المهام عند بدء التشغيل، لذا قد تكون الزيادة المفاجئة بعد التحديث أعمال صيانة لا تغيرًا مستمرًا في الأداء.
إذا عاد استهلاك المعالج إلى نطاق الخمول القديم بعد انتهاء المهام، فلا تضبط إعدادات تحويل الترميز أو تستبدل العتاد. فهذا يعني أن فرعك قد استقر بالفعل بعد انتهاء الأعمال المؤقتة في الخلفية؛ وبدلًا من ذلك، جدولة المهام الثقيلة خارج ساعات المشاهدة إذا كانت تتداخل مع التشغيل.
تحقق مما إذا كان التشغيل يستخدم المعالج الآن
إذا بدأت الزيادة في استهلاك المعالج فقط عند بدء تشغيل عميل معين، فافتح لوحة معلومات Jellyfin وحدد ما إذا كانت الجلسة تستخدم التشغيل المباشر، أو إعادة التغليف، أو تحويل ترميز الصوت، أو تحويل ترميز الفيديو. فقد يكشف تغيير في العميل أو برنامج الترميز عن مسار برمجي لم يكن مستخدمًا من قبل.
شغّل الوسائط نفسها على العميل نفسه مع إيقاف الترجمة، ثم قارن استهلاك المعالج. إذا انخفض الاستخدام بشدة، فستكون الترجمة أو مسار تحويل الترميز هي العامل الفارق. وإذا ظل مرتفعًا أثناء التشغيل المباشر، فابحث في التخزين أو الإضافات أو عملية أخرى بدلًا من إلقاء اللوم على أداة الترميز.
لإجراء فحص أعمق للتشغيل، استخدم الطريقة نفسها الموضحة في التحقق من تحويل الترميز بالأجهزة: تأكد من مسار GPU/FFmpeg النشط بدلًا من الاكتفاء بالثقة في أن تسريع الأجهزة مفعّل في الإعدادات.
قِس استهلاك عملية الحاوية بدلًا من التخمين من حمل المضيف
على خادم منزلي مشترك، تحقق من أن Jellyfin هي العملية التي تستهلك المعالج فعلًا. فقد تكون النسخ الاحتياطية، أو مفهرسات الوسائط، أو عملاء التنزيل، أو مولدات الصور المصغرة، أو صيانة نظام الملفات قد بدأت في وقت قريب من إعادة التشغيل أو التحديث نفسه.
توفر بيئات تشغيل الحاويات طرقًا لعرض الاستخدام لكل حاوية؛ وقد صُمم الأمر stats في Docker لعرض الاستخدام المباشر للموارد في الحاويات قيد التشغيل. استخدم استخدام الموارد لكل حاوية أو ما يعادله في منصتك أثناء إعادة إنتاج المشكلة.
إذا كانت حاوية أخرى هي التي تستهلك المعالج، فأوقف تلك المهمة مؤقتًا وأعد الاختبار الأصلي. وإذا كانت Jellyfin هي المالكة للاستهلاك، فتابع فحص مهام Jellyfin والتشغيل؛ أما إذا لم تكن كذلك، فقد تزامن التحديث مع حمل المضيف فقط، ولم يكن هو السبب.
عطّل مصدرًا واحدًا في الخلفية أو أعد جدولته في كل مرة
تحقق من صفحة المهام المجدولة في Jellyfin بحثًا عن مهمة قيد التشغيل حاليًا أو تُعاد باستمرار. وراجع أيضًا الإضافات التي تضيف أعمالًا مجدولة خاصة بها، أو موفري البيانات الوصفية، أو اكتشاف المقدمات، أو معالجة الترجمة، أو غير ذلك من أتمتة المكتبة.
لا تعطّل جميع الإضافات والمهام نهائيًا في خطوة واحدة. أوقف مؤقتًا مرشحًا واحدًا عالي التكلفة، وانتظر حتى يستقر استهلاك المعالج، ثم أعد إنتاج حالة الخمول أو الفحص نفسها. إذا انخفض الاستهلاك بوضوح، فقد حددت الفرع المسؤول؛ وإذا لم يتغير، فأعد تفعيله واختبر المرشح التالي.
إذا كانت المهمة مشروعة لكن توقيتها غير مناسب، فأعد جدولتها بدلًا من اعتبارها عيبًا. وإذا دخلت في حلقة، أو فشلت، أو أعادت التشغيل فورًا بعد التحديث، فاحتفظ بالسجلات ومعلومات الإضافة/الإصدار قبل تغيير ملفات قاعدة البيانات أو إعادة بناء الخادم.
أكد الإصلاح تحت حمل ما بعد التحديث الأصلي
بعد تحديد السبب، طبّق الإصلاح المناسب: اترك عمليات الترحيل تكتمل، أو أعد جدولة مهمة، أو أعد تسريع الأجهزة، أو حدّث إضافة بها مشكلة أو عطّلها، أو صحح حالة العميل/تحويل الترميز. ثم أعد التشغيل مرة واحدة وكرر الاختبار الدقيق الذي كان يرفع استهلاك المعالج سابقًا.
يعني نجاح الإصلاح أن يتوافق سلوك المعالج مع عبء العمل مجددًا: يستقر الخمول بعد بدء التشغيل، ويظل التشغيل المباشر منخفض الاستهلاك، ويستخدم أي تحويل ترميز مطلوب مسار التسريع المتوقع. ولا تكفي فترة هدوء مدتها دقيقة واحدة دون تكرار العامل المحفز.
صعّد التحقيق عندما يظل استهلاك المعالج مرتفعًا دون وجود مهام قيد التشغيل، أو تحويل ترميز، أو حاوية منافسة، ومع خط أساس نظيف للإضافات. عندها اجمع إصدار Jellyfin، ونظام التشغيل/المعمارية، وحالة المهام، ونافذة قصيرة من السجل، حتى يمكن التحقيق في تراجع خاص بالإصدار دون التعميم انطلاقًا من عملية بدء تشغيل مزدحمة واحدة.
الدعم والنصائح
المزيد للقراءة

يعمل Jellyfin عبر شبكة Wi‑Fi لكنه يفشل عبر Ethernet أو VPN
عندما يعمل Jellyfin عبر شبكة Wi‑Fi فقط، اعزل مسار الشبكة الذي تغيّر: الوجهة، والمسار، وتصنيف جدار الحماية/الشبكة المحلية، ثم تداخل VPN.

كيفية إيقاف تشغيل Jellyfin نهائيًا دون ترك بيانات غير محمية
أوقِف Jellyfin بأمان عبر الاحتفاظ بنقطة استعادة نهائية، وإغلاق مسارات الوصول، وحصر كل وحدة تخزين ونقطة تحميل ونسخة احتياطية وبيانات اعتماد.

هل ينبغي استخدام التحديثات التلقائية لـ Jellyfin على خادم منزلي؟
تكون تحديثات Jellyfin التلقائية أكثر أمانًا عند تحديد النسخ الاحتياطية ونطاق الإصدار وخطة التراجع والتحقق بعد التحديث قبل الانتقال غير المراقَب.

