ما هو XMLTV، وما الذي يجب أن ينجو منه المحلِّل داخله

XMLTV هي الصيغة التي يُسلَّم بها تقريبًا كل دليل تلفزيوني خارج منظومة جهة البث نفسها. وهي أقدم من صناعة البث بالكامل، وهي XML عادي، ومواصفتها DTD لا مخطط له مُحقِّق يشغّله أحد.

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

الصيغة في شاشة واحدة#

العناصر التي لها أهمية عددها 2.

<tv>
  <channel id="bbc1.uk">
    <display-name>BBC One</display-name>
    <display-name lang="en">BBC One HD</display-name>
    <icon src="https://example.com/bbc1.png" />
  </channel>

  <programme channel="bbc1.uk" start="20260831180000 +0100" stop="20260831190000 +0100">
    <title lang="en">The Six O'Clock News</title>
    <desc lang="en">National and international news.</desc>
    <category lang="en">News</category>
  </programme>
</tv>

يعلن channel معرّفًا واسمًا واحدًا أو أكثر مقروءًا للبشر. ويشير programme إلى معرّف قناة، ويحمل وقت بداية ووقت نهاية عادةً، ويضم عنوانًا مع ما شاء المولِّد إدراجه من بيانات وصفية اختيارية.

تلك هي الصيغة. كل ما عدا ذلك اختياري، وعمليًّا كل ما عدا ذلك حاضر بلا اتساق.

المعرّف هو الربط كله#

channel id مفتاح ربط، وهو مفتاح الربط الوحيد. وهذا أهم شيء على الإطلاق في XMLTV.

تقول قائمة تشغيلك إن القناة هي tvg-id="bbc1.uk". وملف دليلك يحوي <channel id="bbc1.uk">. يجب أن تتطابق هاتان السلسلتان بالضبط، وإلا فلا جدول للقناة.

هما غير مشتقتَين من أي شيء. لا سجل مركزي. ولا تطبيع تفرضه الصيغة. فـ bbc1.uk وBBCOne.uk وBBC1.uk وbbc-one.uk هي 4 قنوات مختلفة في نظر أي محلِّل، ومن الطبيعي تمامًا أن تستخدم قائمة تشغيل المزوّد اصطلاحًا بينما يستخدم ملف الدليل الذي يوصي به اصطلاحًا آخر.

لهذا يكون «دليلي فارغ» عادةً مشكلة مطابقة لا مشكلة جلب ولا مشكلة تحليل. فقد يكون الملفان مكوَّنَين تكوينًا مثاليًّا وعديمَي الفائدة تمامًا معًا.

عناصر display-name لا تفيد في الربط. فهي لعرضها على الناس، وكثيرًا ما تكون عدة أسماء لكل قناة بعدة لغات، واستخدامها في المطابقة استدلال تقريبي لا قاعدة.

الطوابع الزمنية، وسبب أن أدلة كثيرة تبدو منزاحة ساعة#

الطابع الزمني في XMLTV سلسلة توقيت حائطي تليها إزاحة اختيارية:

20260831180000 +0100    six in the evening, one hour ahead of UTC
20260831180000          six in the evening UTC, per the spec's default

الإزاحة اختيارية. وهذا الخيار التصميمي الواحد يولّد أسئلة دعم أكثر من كل ما في الصيغة مجتمعًا.

أخطأنا في هذا في مسودة سابقة من هذه المقالة، وصفت الطابع الزمني المجرد بأنه غير قابل للتموضع. وهو ليس كذلك. فـ DTD صريح في أن الطابع الزمني بلا منطقة زمنية يُقرأ بوصفه UTC، فهناك افتراض معرَّف والمحلِّل المطابق للمواصفة يتبعه.

المشكلة أن المولِّد الذي يحذف الإزاحة لا ينشر UTC في الغالب. بل ينشر التوقيت الحائطي المحلي لحيث جُمع الدليل، معتمدًا على أن القارئ في المكان نفسه. ليس ذلك ما تقوله المواصفة، وهو ما تفعله ملفات كثيرة جدًّا. فيكون المحلِّل الذي يتبع DTD صحيحًا ومخطئًا بساعة أو ساعتَين في الوقت نفسه.

يأخذ محلِّلنا منطقة زمنية مفترضة من المستدعي لهذه الحالة تحديدًا، وهذا يحوّل التضارب إلى إعداد لا قرار صامت. ويترك مسارا الاستيراد على الجهاز كلاهما هذه القيمة null، فيُقرأ الطابع الزمني المجرد بوصفه UTC ولا تدخل منطقة الجهاز الزمنية في الحساب أبدًا.

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

ملف الدليل مدخلات غير موثوقة#

غير مرئي للمستخدم. وكل شيء للمحلِّل.

ملف الدليل هو XML من عنوان URL عشوائي، ولـ XML تاريخ طويل من هجمات المحلِّلات. لذا يُضبط القارئ دفاعيًّا قبل أن يقرأ بايتًا واحدًا: تعريفات نوع المستند تُتجاهَل بدل معالجتها، والمحلِّل الخارجي يُضبط على null فلا يستطيع أي كيان إحداث جلب عبر الشبكة، والتوسّع من الكيانات مسقوف عند صفر محارف.

تسدّ هذه الإعدادات الثلاثة مشكلتَي توسّع الكيانات والكيانات الخارجية الكلاسيكيتَين. وليست تحصينًا قد نخففه من أجل محلِّل أودّ؛ فعنوان URL الدليل هو بالضبط شكل المدخلات التي تستهدفها تلك الهجمات.

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

أحد عشر حدًّا، وسبب وجود كل منها#

تحصين القارئ لا يكفي، لأن المدخلات الخطرة عمليًّا ليست خبيثة. بل هي دليل فيه 40 عنصر عنوان.

depth                32       nesting
text                 64 KB    any single text node
description          4 KB     aggregate across repeats
title                1 KB     aggregate across repeats
credits              15       per programme
categories           6        per programme
alternate names      8        per channel
channel batch        512      rows written at a time
programme batch      2,000    rows written at a time
programme duration   6 hours  ceiling
retention            8 days forward, 1 day back

سقف العنوان هو صاحب السبب الأكثر إفادة. يجوز للبرنامج قانونًا أن يحمل عنوانًا واحدًا لكل لغة. والدليل الذي يُصدر 40 منها ليس مشوّهًا بل دقيق، ومن دون سقف تُلحق الـ40 كلها في عنوان مخزَّن واحد. وسقف الوصف هو القاعدة نفسها للسبب نفسه.

أحجام الدفعات مسألة إنتاجية لا أمان: الدليل الوطني مئات آلاف البرامج، وكتابتها واحدًا واحدًا هي الفرق بين دليل يُحمَّل ودليل يبدو معلَّقًا.

نافذة الاحتفاظ هي التي تفاجئ الناس. فالبرامج الواقعة خارجها تُسقَط أثناء التحليل بدل تخزينها وتشذيبها بعد ذلك. الافتراضي إلى الأمام 8 أيام وإلى الخلف 1، مثبّتان عند 14 و7. والمزوّد الذي ينشر 14 يومًا من الجدول إلى عميل مضبوط على 8 لا يفقد بيانات بسبب خلل؛ بل يُقال له إن المشغّل لا يحتاج جدول الأسبوعَين المقبلَين بما يكفي لتخزينه.

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

ثماني طرق يفشل بها الجلب#

تُصنَّف الإخفاقات في 8 أنواع بدل الإبلاغ عنها بوصفها خطأ واحدًا: لا عنوان URL، وليس XML، وشبكة، وحد الحجم، وحد فك الضغط، وحد الأمان، وأُلغي، وغير معروف. حد فك الضغط وحد الأمان منفصلان عن فشل الشبكة عن قصد، لأنها تعني أشياء مختلفة حقًّا: أحدها قنبلة ضغط، وأحدها مستند عدائي، وأحدها اتصال سيئ.

الأعطال الثلاثة التي وجدتها حزمة عيّنات#

ملفات الدليل الحقيقية أسوأ مما تسمح به الصيغة. ولدينا أرقام على ذلك لا مجرد انطباع.

كشفت حزمة عيّنات من 51 ملف دليل من العالم الحقيقي عن 3 أعطال متمايزة. كان كل منها قادرًا على تدمير دليل مزوّد كامل بسبب بايت واحد.

علامة & غير مهرَّبة في عنوان برنامج. يشترط XML كتابة &، وكثير من المولِّدات تكتب & مجردة، والمحلِّل الصارم يتوقف عند تلك النقطة. وكل ما بعدها يضيع.

ملف يعلن UTF-8 وهو يحمل بايتات Latin-1. الترويسة تقول شيئًا والمتن شيء آخر، وأول محرف بعلامة نطق في عنوان فيلم فرنسي هو حيث ينتهي الأمر.

محرف تحكم شارد في وصف. ليس XML صالحًا في أي ترميز، وهو قاتل من جديد عند النقطة التي يظهر فيها.

الأعطال الـ3 كلها تُرمَّم الآن بدل أن تكون قاتلة، والترميمات تُحصى، فالملف الذي احتاج إلى ترقيع يقول ذلك بدل أن يبدو عاملًا بصمت. وسبب نشر هذا بدل إصلاحه بصمت أنه يعاير التوقعات: إن افترضت أن ملفات الدليل حسنة التكوين، فلن يكون للإخفاقات معنى.

قبل XML: معرفة ما هو الملف أصلًا#

عنوان URL للدليل ينتهي بـ .xml.gz تلميح لا حقيقة. فالمزوّدون يقدّمون gzip من مسارات تنتهي بـ .xml، وXML عاديًّا من مسارات تنتهي بـ .gz، وكليهما من مسارات لا تنتهي بشيء على الإطلاق، وترويسة نوع المحتوى ليست أوثق من المسار.

لذا يُقرَّر الحاوي بقراءة البايتات القليلة الأولى ومقارنتها بأرقام سحرية معروفة:

1F 8B                gzip
50 4B 03 04          zip
FD 37 7A 58 5A 00    xz
anything else        treat as uncompressed

أربع نتائج، والرابعة هي المهمة: الترويسة غير المعروفة ليست خطأ، بل ملف يُفترض أنه XML عادي. وهذا هو الافتراض الصحيح، لأن الحالة الشائعة للترويسة غير المعروفة مستند XMLTV عادي، والحالة الخاطئة تفشل فشلًا نظيفًا عند المحلِّل بعد لحظة بدل أن تفشل عند فاكّ الضغط بشيء أكثر إرباكًا.

الشكل الوحيد الذي لا يساعد فيه هذا هو عنوان URL يجيب بصفحة خطأ HTML. فلا رقم سحري لها، فتُعامَل بوصفها غير مضغوطة، وتُسلَّم إلى قارئ XML، وتُرفض بوصفها ليست XML. الفشل صحيح وهو على بُعد خطوة واحدة من السبب، وهذا يستحق المعرفة عندما تشخّص عنوان URL لدليل كان يعمل من قبل.

سقفان على فك الضغط، وسبب أن أحدهما نسبة#

الدليل المضغوط أرشيف غير موثوق، والأرشيف الذي يتمدد ليملأ قرصًا هجمة قديمة لها اسم. لذا يُحدّ فك الضغط مرتَين لا مرة.

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

الحد الثاني هو المثير. فالخرج مسقوف أيضًا عند 400 مرة من البايتات المضغوطة المستلَمة فعلًا. يلتقط حارس النسبة الحالة التي يفوّتها السقف المطلق: ملف من 40 KB يتمدد نحو الغيغابايتات يُوقَف عند 16 MB، قبل أن يقارب 2 GiB بزمن طويل، لأن لا شيء في ملامح حجمه يشبه دليلًا حقيقيًّا.

يُضغط XML ضغطًا ممتازًا، لذا فإن 400 إلى 1 ليس حدًّا ضيقًا للبيانات الصادقة. بل هو النقطة التي بعدها يتوقف الملف عن أن يشبه جدولًا ويبدأ في أن يشبه حمولة.

كيف تبدو تغطية المعرّفات فعلًا#

ربط المعرّفات لا يفيد إلا إذا حملت قوائم التشغيل معرّفات، والتغطية تتفاوت أكثر مما تتمنى.

مقيسًا على مجموعة قوائم التشغيل الخاصة بنا، 2,203 مُدخَلات في المجموع:

playlist_01.m3u    308 entries    308 with tvg-id (100%)    283 group-title     0 tvg-chno
playlist_02.m3u8 1,895 entries  1,392 with tvg-id (73.5%)  1,895 group-title  1,355 tvg-chno

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

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

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

لماذا لا تستطيع الأسماء المعروضة إنقاذ ربط فاشل#

الفكرة التالية البديهية، حين لا تتطابق المعرّفات، هي المطابقة بالاسم المقروء للبشر بدلًا منها. وتلك مشكلة أصعب بكثير مما تبدو.

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

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

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

قراءة الأرقام التي يعيدها التحليل#

يبلّغ التحليل عن أكثر من النجاح. فهو يعيد 7 حقول، تجيب عن أسئلة مختلفة:

Channels           how many channel declarations were kept
Programmes         how many programme rows were kept
Dropped            how many were discarded, mostly by the retention window
BytesCompressed    what arrived over the network
BytesUncompressed  what it expanded to
ParseMs            how long it took
CompletedAtUtc     when

هذا المزيج يجيب عن أسئلة لا تستطيع قيمة منطقية أن تجيب عنها. فالدليل الذي فيه 200,000 برنامج و40,000 مُسقَط يفعل شيئًا مختلفًا عن دليل فيه 200,000 و0. وعدة تشخيصات تسقط مباشرة من تركيبات كهذه.

حجمان مضغوط وغير مضغوط متقاربان يعنيان أن الملف لم يكن مضغوطًا، وهذا لعنوان URL ينتهي بـ .gz يعني أنك يُقدَّم إليك شيء غير ما يعِد به الاسم.

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

التحليل الذي انتهى في 40 ميلي ثانية على ملف يُفترض أن يكون 60 MB لم يقرأ دليلًا. بل قرأ صفحة خطأ، ونوع الفشل سيقول ذلك.

عدد قنوات بالآلاف مع عدد برامج صفر هو شكل دليل يحمل إعلانات قنوات بلا جدول، وبعض المزوّدين ينشره بين دورات التوليد.

ما تأخذه من هذا#

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

إذا كان دليلك حاضرًا لكنه منزاح، فافحص هل يحمل الملف إزاحات.

إذا كان دليلك جزئيًّا، فافحص هل قُطع أثناء النقل، وهو فشل محدد بتوقيع محدد: دليل يتوقف في المنتصف.

وحين تستطيع الاختيار بين XMLTV مزوّدك وطرف ثالث، فاختر المزوّد، للسبب أعلاه. تسير الدليل فارغ بالتشخيص من أوله إلى آخره.