[JiRo]

Udělal jsme si monitorovací script, abych pochopil, jak se iVysílání chová. Výsledek je i není pozitivní. Začnu negativem, který spočívá v tom, že jiné pořady, než ČT Sport Plus nebude (alespoň v této fázi řešení) možné přijímat. Není to zas taková tragedie. Co si budem povídat, stejně to všechno dělám právě jen kvůli tomu sportu, a pokud něco ostatní nezískám tak nějak mimochodem, tak se o to mermomocí snažit nebudu. Pozitivem je, že jsem snad už odchytal logiku toho, jak iVysílání pracuje. Abych měl přímou vazbu a srovnání s webem, napsal jsme si malý parser pro získání EPG přímo z webu. Předpokládám, že ho následně vyměním za zdroj z oficiálního api rozhraní ČT serveru. Ale pro tuto chvíli mi přímá vazba mezi tím, co se děje na webu a tím, co z toho vytvářím v mém scriptu, připadá užitečnější. Mám přímé srovnání. Vím, že i web server si ta data bere s příslušného api GRAPHQL, takže by budoucí změna zdoje EPG neměla být problémem.

A jak se to tedy vlastně chová. Data EPG (TV program na stránce iVysílání) pro Sport Plus obsahují základní informace o jednotlivých programových relacích. Je v nich v podstatě všechno, co je pro EPG v Tvheadend potřeba. Kromě jediného, a to je identifikace interního kanálu, na kterém se bude daná relace "vysílat". Ta se tam zpravidla objeví až v poslední minutě před ohlášeným začátkem vysílání. Neznamená to, že by se v tom okamžiku daná relace spustila. Většinou se spustí jen přehrávání videosmyčky daného interního kanálu a vlastní přenos začne s nějakým zpožděním. Ale to je celkem pochopitelné. Dává to ale poměrně jasný návod k tomu, jak to celé v Tvheadend řešit. Bude to sice o trochu složitější, jak tradiční vytvoření statické vazby mezi EPG a interním kanálem, ale zároveň to dává možnost, jak tuto vazbu vytvořit virtuálně a v dané chvíli, kdy je už identifikátor kanálu známý, ji nahradit tím skutečným.

Popisem v závěru předchozího odstavce jsem vlastně vytvořil specifikaci toho, jak se změní funkce scriptu (streamer-u), který bude zajišťovat předání streamu (metodou pipe) pro Tvheadend v okamžiku, když si uživatel (nebo úloha nahrávání) spustí přehrávání daného kanálu:

• pokud se přehrávání spustí ještě v době, kdy identfikace interního kanálu není ještě k dispozici, pustí script lokálně do pipe Tvheadend pouze statickou video smyčku s infromacemi, že daný kanál ještě nemá stream k dispozcii,
  
• pokud se přehrávání spustí v době, kdy už je identifikace interního kanálu k dispozici, spustí se stream z daného kanálu,
  
• specifické řešení bude ale třeba ještě dořešit pro přechodové stavy:
  • kdy se například spustí přehrávání v době, kdy identfikace interního kanálu není ještě k dispozici, ale přehrávání přeteče do času, když už identifikace k disposzici je,
    
  • nebo pro případ, kdy sice přehrávaný stream skončí ale nedojde k ukončení přehrávání.
    

Ona zmíněná specifická řešení budou trochu oříšek, ale snad se podaří najít nějaké smysluplné řešení. Vzhledem k tomu, že streamer script bude napsán v python, není důvod, že by to napsat nešlo. Klíčové ale bude, jak se zachová Tvheadend při změnách zdrojů streamů směrovaných rourou na jeho stdin. S tím zatím žádné zkušenosti nemám. Uvidíme...