عادةً نعم، لكن تعامل مع الانتقال من ARM إلى x86 على أنه ترحيل مُدار للمضيف، وليس دليلًا على أن كل مكوّنات Jellyfin محايدة تجاه المعمارية. بالنسبة إلى إصدارات Jellyfin الحالية، فإن هدف ARM المعني هو ARM64؛ وينبغي أن تكون الوجهة x86 أيضًا منصة 64 بت مدعومة. أبقِ المصدر كما هو حتى تجتاز الوجهة اختبارات إعادة التشغيل وتشغيل الوسائط.
الحد الفاصل المهم تشغيلي: أوقف المصدر قبل نسخ الحالة الدائمة، ولا تسمح مطلقًا لنسختَي Jellyfin على مضيفين مختلفين بالكتابة إلى دليل البيانات النشط نفسه. لا توثّق Jellyfin الانتقال من ARM64 إلى x86-64 باعتباره مسار ترحيل خاصًا خاليًا من المخاطر، لذا احتفظ بنسخة للرجوع، وأعِد إنشاء العناصر الخاصة بالمنصة بشكل منفصل، مثل حزم FFmpeg، وتعيينات أجهزة تسريع العتاد، وتبعيات الإضافات الأصلية، والأذونات، ومسارات المضيف.
تحقّق من أن معمارية الوجهة مدعومة فعليًا
ابدأ بالتأكد من أن الوجهة منصة Jellyfin ذات 64 بت ومدعومة حاليًا. لا تفترض أن لوحة ARM قديمة أو نظام تشغيل 32 بت أو جهاز x86 قديم مقبول لمجرد أن Linux ما زال يعمل عليه.
أزال Jellyfin 10.11 رسميًا دعم ARM32، بما في ذلك armhf، ويتطلب الآن نظام تشغيل ARM64 على منصات ARM. إذا كان المصدر لا يزال يشغّل إصدار ARM قديمًا ذا 32 بت، فخطط أولًا لوجهة مدعومة ذات 64 بت بدل اعتبار بيئة التشغيل القديمة هدفًا حاليًا للترحيل.
على x86، استخدم مضيف x86-64 مدعومًا ويستوفي متطلبات إصدار Jellyfin الذي تنوي تشغيله. إذا كانت الوجهة تعتمد على حزمة غير رسمية أو نظام تشغيل غير مدعوم أو معالج قديم، فحل مشكلة المنصة أولًا قبل نقل الحالة الدائمة.
اعتبر الحالة المخزنة قابلة للنقل، لكن النشر خاصًا بالمنصة
يحتفظ نشر Jellyfin القياسي بحالة الخادم الدائمة في قاعدة بيانات، إلى جانب ملفات الإعدادات والبيانات الوصفية. بالنسبة إلى عمليات التثبيت التي تستخدم SQLite، صُمم تنسيق قاعدة البيانات على القرص ليكون قابلًا للنقل بين معماريات المعالجات، لذا فإن اختلاف عائلة المعالج وحده ليس سببًا لتحويل قاعدة البيانات بايتًا ببايت قبل الترحيل.
توثّق SQLite تنسيق ملفاتها باعتباره تنسيق قاعدة بيانات متعدد المنصات، بما في ذلك قابلية النقل بين أنظمة 32 بت و64 بت والاختلافات في ترتيب البايتات. ويدعم ذلك جانب تنسيق قاعدة البيانات من عملية النقل، لكنه لا يضمن بقاء كل إضافة في Jellyfin أو ملف تنفيذي خارجي أو برنامج تشغيل أو مسار خاص بالنشر دون تغيير.
احرص على التمييز بين الأمرين: السجلات المخزنة القابلة للنقل ليست سوى طبقة واحدة. يظل توافق إصدار Jellyfin، وشمولية بيانات وإعدادات النسخ، واتساق مسارات الوسائط، وتبعيات الإضافات، والأذونات، والوصول إلى أجهزة العتاد عوامل تحدد ما إذا كانت الوجهة ستعمل مثل المصدر.
أوقف Jellyfin قبل نقل الحالة النشطة
لإجراء انتقال مُدار بين معماريتين، أوقف عملية Jellyfin على المصدر قبل إنشاء نسخة الترحيل. يمنع ذلك تغيّر قاعدة البيانات النشطة أو حالة الكتابة المسبقة أثناء نسخ الملفات، ويوفر نقطة رجوع متسقة واحدة.
انسخ نطاق البيانات والإعدادات كاملًا بدل اختيار jellyfin.db فقط. فقد تحتفظ النسخة الجزئية بالمستخدمين، لكنها تفقد الإعدادات أو الإضافات أو البيانات الوصفية أو غيرها من الحالة التي تتوقعها الوجهة.
ينطبق هنا نموذج الحماية نفسه المستخدم في خطة النسخ الاحتياطي متعددة النسخ: أبقِ المصدر كما هو حتى تجتاز الوجهة عملية استعادة فعلية والتحقق من تشغيل الوسائط.
أعِد إنشاء العناصر الخاصة بالمعمارية على المضيف الجديد
ثبّت حزمة Jellyfin الأصلية الخاصة بالوجهة أو استخدم صورة الحاوية الصحيحة متعددة المعماريات. أعِد إنشاء تعيينات أجهزة GPU، وأذونات المجموعات، وحزم FFmpeg، وأي مسارات خاصة بالمضيف بدل نسخ الملفات التنفيذية من المعمارية القديمة.
راجع الإضافات بعد التشغيل الأول. قد تتطلب الإضافات التي تعتمد على مكتبات أصلية أو ملفات تنفيذية مضمّنة أو ملفات تنفيذية خارجية إصدارًا يطابق المعمارية الجديدة. عطّل أي إضافة مشكوك فيها أثناء التحقق الأول إذا كانت تمنع التشغيل، ثم أعد إضافتها فقط بعد التأكد من توافقها.
إذا اختلفت مسارات الوسائط بين المضيفين، فحافظ على المسارات نفسها من خلال نقاط التحميل حيثما كان ذلك عمليًا. وإلا فخطط لترحيل مسارات مدعوم بدل تعديل سجلات قاعدة بيانات Jellyfin الداخلية يدويًا.
تحقّق من الترحيل قبل إعادة استخدام المصدر
شغّل نسخة الوجهة فقط، وتأكد من المستخدمين والمكتبات وحالة المشاهدة والرسومات والمهام المجدولة، ومن تشغيل وسيلة واحدة عبر التشغيل المباشر ووسيلة أخرى تتطلب تحويلًا للترميز. افحص السجلات بحثًا عن مكتبات أصلية مفقودة أو فشل في الأذونات أو مسارات لا تزال تشير إلى المضيف القديم.
أعد تشغيل الوجهة مرتين وكرّر اختبار تشغيل الوسائط حتى يكون النجاح مستمرًا لا مجرد تشغيل ناجح لمرة واحدة. إذا فشلت الوجهة، فأوقفها واستعد نسخة الترحيل أو عد إلى المصدر غير المُعدّل، بدل السماح للنسختين بالكتابة إلى الحالة نفسها.
يكتمل الانتقال فقط عندما يصمد المضيف الجديد أمام إعادة التشغيل والاستخدام المنزلي المعتاد. إذا أردت إبقاء الجهاز القديم متاحًا، فامنحه نسخة مستعادة منفصلة أو اتركه مطفأً؛ ولا تستخدم دليل بيانات Jellyfin حيًا واحدًا كتخزين نشط مشترك بين خوادم ARM وx86.
الدعم والنصائح
المزيد للقراءة

هل ينبغي لـ Jellyfin استخدام حساب مشترك واحد أم حسابات منزلية منفصلة؟
اختر حسابات منزلية لـ Jellyfin وفقًا لحدود الهوية والوصول والرقابة الأبوية والاسترداد التي تحتاجها.

لماذا يظل استخدام ذاكرة Jellyfin مرتفعًا بعد اكتمال العمل؟
افصل نمو عملية Jellyfin عن ذاكرة التخزين المؤقت في Linux، ولا تُجرِ تحقيقًا إلا عندما تستمر الذاكرة في الارتفاع أو تتسبب في ضغط فعلي.

علامات تحوّل تخطيط تخزين Jellyfin إلى خطر على الاسترداد
راجع أدوار تخزين Jellyfin، وافصل الحالة الحية عن النسخ الاحتياطية والبيانات القابلة لإعادة البناء، ثم أثبت صحة التخطيط بإجراء استعادة.

