لماذا يتعطّل Plex بشكل متقطع عند البث على أجهزة متعددة في الوقت نفسه؟

إيفا وونغ هي كاتبة تقنية و ومهندسة هاوية في ZimaSpace. مهووسة بالتكنولوجيا مدى الحياة ولديها شغف بالمختبرات المنزلية والبرمجيات مفتوحة المصدر، تتخصص في تبسيط المفاهيم التقنية المعقدة إلى أدلة عملية وسهلة الفهم. تؤمن إيفا بأن الاستضافة الذاتية يجب أن تكون ممتعة وليست مخيفة. من خلال دروسها، تمكّن المجتمع من تبسيط إعدادات الأجهزة، بدءًا من بناء أول نظام تخزين شبكي NAS وحتى إتقان حاويات Docker.

عادةً ما يصبح تشخيص أعطال Plex المتقطعة مع عدة عملاء أسهل عند مراقبة أي تدفق يتغير أولًا: التحويل، أو النطاق الترددي، أو عمليات الإدخال والإخراج في التخزين، أو مسار خاص بعميل واحد.

قد يظل الخادم مستقرًا عند تشغيله على تلفاز واحد، لكنه يفشل عندما يبدأ هاتف ومتصفح بعيد وتلفاز ذكي تشغيل ملفات مختلفة في الوقت نفسه. وقد لا يطلب العملاء الحمل نفسه: إذ يمكن لأحدهم استخدام التشغيل المباشر، بينما يفرض آخر تحويل الفيديو، أو دمج الترجمة، أو المرور عبر شبكة WAN. أعد إنتاج العطل بإضافة العملاء واحدًا تلو الآخر، واستخدم لوحة معلومات Plex لتسجيل ما تفعله كل جلسة فعليًا قبل تغيير الحدود أو العتاد.

أنشئ خط أساس لبث واحد قبل اختبار التزامن

ابدأ بمزيج العميل والملف الذي يتعرض للعطل غالبًا، لكن شغّل بثًا واحدًا فقط. سجّل ما إذا كان Plex يبلّغ عن تشغيل مباشر، أو تدفق مباشر، أو تحويل، ولاحظ سلوك وحدة المعالجة المركزية ووحدة معالجة الرسومات والشبكة والقرص. إذا فشل البث بمفرده، فالتزامن ليس السبب الرئيسي، ويجب إيقاف بقية الاختبار.

توضح Plex أن سعة البث في الخادم تكون مقيدة أساسًا بـقدرة المعالجة والنطاق الترددي للشبكة عند استخدام التحويل أو التشغيل عن بُعد. ويهم هذا التمييز لأن الخادم قد يتعامل مع العديد من جلسات التشغيل المباشر، لكنه يبلغ حدوده سريعًا عندما يطلب عدة عملاء تحويل المحتوى.

إذا كان خط الأساس سليمًا، فأضف عميلًا ثانيًا دون تغيير الأول. واصل إضافة عميل واحد في كل مرة حتى يحدث أول عطل يمكن ملاحظته. فالتيار الذي تضيفه عند نقطة الانهيار أكثر إفادة من رسالة خطأ عشوائية، لأنه يوضح أي حمل جديد غيّر حالة الخادم.

استخدم لوحة المعلومات للفصل بين ضغط التحويل وضغط الشبكة

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

يفيد دليل ZimaSpace لتسريع العتاد في فهم سبب نقل عدة تدفقات العمل من وحدة المعالجة المركزية إلى مسرّع متاح، وسبب حاجة الخادم مع ذلك إلى هامش كافٍ لمهام NAS الأخرى. فتسريع العتاد لا يثبت إمكانية التزامن غير المحدودة؛ بل يمثل مسارًا واحدًا من الموارد يجب التحقق منه.

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

تحقق مما إذا كانت الحاوية أو المضيف يصلان إلى التشبع عند نقطة الفشل

راقب حاوية Plex والمضيف أثناء إضافة التدفقات. يمثل بلوغ وحدة المعالجة المركزية حدها، أو تشبع محرك الفيديو في وحدة معالجة الرسومات، أو ضغط الذاكرة، أو ارتفاع انتظار الإدخال والإخراج في عدد العملاء نفسه الذي يظهر عنده العطل، دليلًا أقوى من متوسط الاستخدام الذي تلاحظه بعد الفشل. ابحث عن المورد الذي يبلغ حده أولًا.

يمكن لـأمر إحصاءات الحاوية في Docker عرض استخدام الحاوية لوحدة المعالجة المركزية والذاكرة والشبكة وعمليات الإدخال والإخراج على الكتل أثناء إجراء الاختبار. اقرن ذلك بعرض الجلسات في Plex لتحديد ما إذا كانت قفزة الموارد تخص Plex، وأي إجراء من العميل تسبب فيها.

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

-15% OFF

طبّق أصغر إصلاح مناسب وأعد الاختبار بمزيج العملاء نفسه

عند تأكيد وجود حد للتحويل، قلّل عمليات التحويل غير الضرورية، وتحقق من تسريع العتاد، أو عيّن حدًا مدروسًا لعدد التحويلات المتزامنة يترك NAS مستجيبًا. وعند تأكيد وجود اختناق في الرفع، اضبط جودة التدفقات البعيدة أو زد النطاق الترددي المتاح للرفع. أما في حالة عمليات الإدخال والإخراج في التخزين، فاختبر مساري الوسائط والتحويل المؤقت كلًّا على حدة قبل نقل أي شيء.

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

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

الدعم والنصائح

المزيد للقراءة

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.