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