iVysílání - Verze k tisku

iVysílání - Verze k tisku

+- XBMC-Kodi.cz (https://www.xbmc-kodi.cz)
+-- Fórum: KODI - Doplňky (https://www.xbmc-kodi.cz/forum-kodi-doplnky)
+--- Fórum: Live TV & PVR (https://www.xbmc-kodi.cz/forum-live-tv-pvr)
+---- Fórum: Tvheadend (https://www.xbmc-kodi.cz/forum-tvheadend)
+---- Téma: iVysílání (/prispevek-ivysilani--13377)

Stran: 1 2 3 4

RE: iVysílání - JiRo - 10.8.2025

@martinchromy1985: Tak definitivně potvrzená plná funkčnost EPG iVysílání+.

[Obrázek: 5wn6Rkg.png]

Pokud problém přetrvává, bude to nějaký lokální problém. Prošel jsme si to a nic, co by mohl být jen potenciálně problém, tam nevidím.

RE: iVysílání - martinchromy1985 - 12.8.2025

Ahoj
I me uz to bez jakehokoliv zasahu jede. Asi erupce na slunci ci co. Dekuji za rychlou odezvu a omlouvam se za vyruseni u more.

RE: iVysílání - 100karel - 22.11.2025

Dloudodobě nejedou:
CH_MOB_01
CH_MP_07
CH_MP_08

Nově jsou tam:
CH_33
CH_34
CH_35
CH_36

Kvůli tomu, že jsem je neměl v playlistu a configu, tak padalo epg.py

RE: iVysílání - JiRo - 22.11.2025

@100karel: Díky, mrknu co nejdříve na to.

Přiznám se, že si už moc nepamatuji, jak jsem to dělal. Editovat tabulku mapování kanálů v config.py jsi nezkoušel?

RE: iVysílání - 100karel - 22.11.2025

Ano samozřejmě jsem udělal editaci playlist.m3u8 a config.py
Píšu to, protože to jinak dnes končilo hláškou viz níže a epg se nevygenerovalo. Z toho jsem pochopil, že mu chybí kanál CH_33. Jakmile jsem přidal do playlistu a configu CH_33 tak byla hláška s KeyError: 'CH_35' Takže jsem to zkusil a zjistil, že je tam ještě CH_34 a CH_36. Jak jsem to přidal, tak se epg rozjelo.

Kód:
File "/ivysilani/epg.py", line 72, in <module>

    services, channelsWithEpg, channelsWithoutEpg = getServicesAndChannels(source, mappingServices)

                                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  File "/home/pi/scripts/ivysilaniplus/epg.py", line 46, in getServicesAndChannels

    channelsWithEpg.append(mapping[service])

                           ~~~~~~~^^^^^^^^^

KeyError: 'CH_33'

RE: iVysílání - JiRo - 22.11.2025

@100karel: Díky za informaci. Musím se na to podívat důkladněji, abych si osvěžil paměť. Pak tak opravím, aby to při podobné události, pokud by ještě nastala, už minimálně nepadalo.

Mohl bych to ještě upravit důkladněji, před časem jsem o tom shodou okolností přemýšlel. Tabulku vytáhnout do souboru, generovat playlist na základě uživatelského nastavení, a pokud by se v Tvheadend nastavil i bouquet, tak by to mohlo všechno probíhat víceméně automaticky. Takže o tomhle typu vylepšení budu ještě přemýšlet a jestli to půjde tak, jak si myslím, že by mělo, tak vyrobím novou verzi.

RE: iVysílání - 100karel - 12.2.2026

Nemáme nějaký jiný zdroj pro EPG pro ČT Sport Plus?

Kód:
https://hbbtv.ceskatelevize.cz/online/services/data/online.json

Tohle bohužel nějak zamrzlo na 10.2.2026 a zatím se nepohnulo dál

RE: iVysílání - JiRo - 12.2.2026

@100karel: Já už tady nic publikovat ani udržovat nebudu. A navíc, mám tohle teď řešeno už jinak.

Takže jediné co se dá k tomu napsat je, že se ta data dala také poměrně jednoduše vycucnout z api Graphql. Měl jsem to kdysi jako výchozí variantu řešení, než mi tady @pbk: poradil HbbTV. Inspirujte se u @waladir:.

RE: iVysílání - Marthinius - 12.2.2026

Je to opravdu škoda, někteří neumí zřejmě ocenit tu snahu a hlavně "čas", který tomu musel autor věnovat. Každopádně za sebe mohu poděkovat, i když už to není funkční...

RE: iVysílání - JiRo - 13.8.2026

Protože se chystám projekt iVysílání obnovit, věnoval jsem se včera po západu zatmělého Slunce analýze toho, jaké možnosti má dvojice Tvheadend - Kodi k tomu, aby šlo dynamicky ovládat zobrazení kanálů. Jak jsem tady už dříve popsal mé dosavadní řešení, používal jsem k ovládání zobrazení kanálů v Kodi jejich nastavení enabled/disabled v Tvheadend. Mělo to ale svá úskalí, protože změna stavu se do Kodi bez dalších kroků automaticky nepřenesla. Řešil jsem to malým scriptem v Kodi, který dokázal zjistit, jestli nějaký kanál změnil svůj stav a pokud ano a neprobíhalo právě nějaké přehrávání PVR obsahu, restartoval jsem Kodi PVR. Pokud v té chvíli přehrávání PVR běželo, proběhl restart až po jeho ukončení. Mělo to ale jedno zásadní úskalí. Restart PVR je velmi "choulostivá akce", která zcela náhodně a jen někdy skončí zamrznutím Kodi. Ostatně, patrně kvůli tomu team Kodi zřejmě vnitřní příkaz RestartPVR() kdysi zrušil.

Vyzkoušel jsem tedy pár dalších postupů, jak to vyřešit, aby to bylo co nejméně "bolestivé" a bez rizik, a abych i pro ostatní identifikoval potenciální možnosti řešení a jejich výsledné chování, tak tady je jejich stručný popis (včetně toho původního, tedy enable/disable kanálu:

enable/disable kanálu - do Kodi se sice občas nějaká změna stavu enable/disable dostane, ale je to zcela náhodné, asi tak v poměru 1:20 (úspěch:neúspěch), což je pro praktické použití zcela nedostačující. Doplnění výše uvedeného scriptu v Kodi sice tento problém odstraní, ale zase tam přidá jiný, občasné zamrznutí Kodi. Tak je poměr trochu jiný, a opačný, cca 1:30 (kodi zamrzne:nezamrzne).
dynamická změna tag-u kanálů - kdy kanálům, které v Kodi nechci zobrazit, smáznu jejich tagy a nastavím jim zvláštní tag Skrytý. V Kodi to pak znamená trochu přeparametrovat skupiny kanálů. Potíž je ale v tom, že i když to vypadá na první pohled dobře, tak se změna tagu a z ní plynoucí přeřazení ze skupiny do skupiny do Kodi spolehlivě dynamicky nepřenese. V podstatě je to stejný problém jako u předchozího případu.
dynamické mapování kanálů - tady to byla jen idea, kterou jsme ani nezkoušel, protože její podmínkou bylo, že najdu odpovídající funkce v Tvheandend Json api. To se mi ale nepodařilo. Ručně, přes webgui, se mi ten proces podařilo nasimulovat a fungoval správě i na straně Kodi, ale to bylo pro praktické použití málo.
dynamická generace playlistu - bylo tedy to poslední, co jsem vyzkoušel a potvrdilo se, že to jediné může fungovat spolehlivě. Ve svém důsledku to vlastně vede ke stavu, jako v předchozím bodě, jen je celé řešeno pouze na úrovni primárních dat, tedy playlistu, ale celý proces zrušení/vytvoření kanálu je zcela v režii Tvheadend a co je hlavní, nepřináší téměř žádná rizika a má jen jeden drobný nedostatek.

Takže k vlastnímu popisu konečného řešení

Primárním krokem je dynamické vytváření obsahu playlistu podle toho, které kanály chci, aby se v Kodi zobrazily. Pak musí následovat nastavení Tvheadend takové, aby se:

playlist testoval v dostatečně krátké periodě. Toho se dosáhne vhodnám nastavení v network, která danou službu (iVysílání) přijímá. Konkrétně jde o parametr Re-fetch period (mins). Je zjevné, že nastaven by měl být v souladu s nastavení periody aktualizace EPG.
při změně obsahu playlistu (přidání/odebrání kanálu) provedl řetezec následných kroků: vytvoření/odebrání muxu, vytvoření/odebrání service a nakonec i vytvoření/zrušení kanálu. Toho se dosáhne snadno s pomocí vytvoření, a pro danou network správným nastavením, bouquets.

Stav kanálu, vytvořen/zrušen, se pak do Kodi přenese vždy spolehlivě, což ale neznamená, že by toto řešení nemělo háček. V okamžiku, kdy se nový kanál vytváří a probíhá jeho scan, může se stát, že neproběhne správně. Takový kanál se pak do celého řetězce, tedy service - kanál - Kodi, nepropíše. Všichni to známe, že scan nemusí dát vždy 100% výsledky, i když zdroj je v pořádku. Tady je většinou pomoc snadná, stačí v network natáhnou hodnotu parametru Maximum timeout (seconds). Pro network iVysílání ji teď mám nastavenou na 20 vteřin a zdá se, po několika desítkách pokusů, že scan všech přidaných kanálů teď proběhne vždy správně.

Tady to asi vyžaduje ode mne jisté vysvětlení, protože každého napadne, proč jsem tento postup nepoužil hned zpočátku. Důvodem byl můj špatný odhad toho, co je a co není důležité nebo podstatné. Ze zkušenosti s Tvheadend vím, že proces vytváření kanálu může být rizikový a také nějakou chvíli trvá. A mě v té souvislosti napadlo, že místo toho použiji jednoduché, spolehlivé a rychlé enable/disbale kanálu. Špatná úvaha, která vedla ke komplikovanému a jak se nakonec ukázalo i výrazně horšímu řešení, i když spíše díky vlastnostem Kodi, než Tvheadend. A mně pak chvíli trvalo, než jsem si to připustil a hlavně, než jsme se pustil do předělání této části řešení. Bouquets jsem používal kdysi, v začátcích používání Tvheadend pro příjem kanálů prvních OTT služeb. Pak jsem ale celý komplex řešení příjmu OTT postavil na známém konceptu tří scriptů: login - playlist - streamer, a bouquets přestal používat. Teď se ukázalo, že své místo stále má.

Toto řešení má pak ještě jednu zajímavou konsekvenci. A ta se může (ale nemusí) projevit v případech, kdy se Tvheaend používá jako zdroj TV kanálů v jiné aplikaci než Kodi. Tam je jakákoliv přímá vazba, kromě té základní zdrojové, tzn. playlist a xmltv, praticky nemožná. Samozřejmě záleží na tom jak a zda vůbec dokáže taková aplikace "vstřebat" časté změny ve zdrojové části poskytované Tvheadend, ale to je už věc jiná.

Závěr

Jak jsem již vícekrát uvedl, snažím se k projektu iVysílání vrátit a i kdybych to nakonec nedotáhl do konce, myslím, že to uvažování a závěry, které jsme tu popsal, mohou někomu, kdo by se chtěl tomuto nebo podobnému projektu věnovat, hodit. Ono takových případů, kdy existují kanály využívané jen někdy a které po většinu času nemají žádný obsah ani EPG, a je tedy na místě je v příslušném klientovi skrývat, je více. Oneplay Sport mutidimenze, Canal+ Sport 4 - 8, Niké Liga, ...

RE: iVysílání - JiRo - 13.8.2026

Nové postupy na straně aktualizace EPG a zobrazení/skrytí kanálů sice daly naději, že by obnovení projektu nemuselo být zas tak nereálné, ale další kroky a zjištění/potvrzení staus quo mé nadšení trochu ochladily. Ukazuje se, že rčení: "Maminka má vždycky pravdu!" je třeba poopravit na "Maminka a @waladir:" mají vždycky pravdu."

Stále se totiž potvrzuje to, co dotyčný napsal zde, resp. co jsme pak diskutovali v následujících příspěvcích. Já jsem z toho nakonec vybruslil díky doporučení @pbk: použít data z webu https://hbbtv.ceskatelevize.cz/online/services/data/online.json. To byl samozřejmě velký game changer, který umožnil použít to řešení, které nakonec projekt iVysilani posunul až k celkem relativně jednoduché a životaschopné verzi.

Tomu je ale od 10. února 2026 konec, protože server hbbtv.ceskatelevize.cz skončil, resp. jím poskytovaná data zamrzla v čase toho dne. Tak se tento den stal vlastně koncem projektu iVysilani v jeho tehdejší podobě. Já jsem pak pátral po tom, co se vlastně stalo a z interních zdrojů spojených s autory pracujících pro ČT jsme se dozvěděl, že HbbTV i v tom případě přešlo plně na zdroje a databázi iVysilani.

A tam se přiřazení pořadu ke konkrétnímu kanálu iVysílání skutečně provádí až těsně před, nebo současně se zahájením jeho streamování. Takže i když je např. EPG kanálů ČT Sport Plus někdy známo i několik dní dopředu, tak to, na jakém interním kanálu iVysílání (CH_25, ...) ten který přenos poběží, se dříve nedozvíme. Tedy já to, zda vůbec a případně jak, nevím. Pokud někdo dokáže poradit, budu vděčný.

Tak určitě to není ještě konec snah o obnovení projetu iVysilani. Jen to znamená zamyslet se na celé struktuře řešení resp. na relaci mezi datovým modelem streamů a EPG na straně serverů iVysílání a jeho vývojem v čase a datovým modelem streamů a EPG na straně Tvheadend. Dosud mezi těmito modely existovala vzájemná relace opřená o identifikaci kanálů iVysílání, nyní je třeba najít relaci/relace jinou/jiné. Tak nebude to nic složitého, jen je to třeba vymyslet nějak smysluplně, aby to ve výsledku, tedy co uvidí uživatel v Kodi, a funkcích, které bude mít k dispozici, bylo nějak rozumné. Znamená to vrátit se v designu projektu jeden, dva či více kroků zpátky, navrhnout nové řešení a naprogramovat ho. Nic víc a nic méně.

RE: iVysílání - JiRo - 13.8.2026

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...

RE: iVysílání - JiRo - 15.8.2026

Odvolávám co jsem odvolal, slibuji co jsem... Ne, až takhle jednoduché to není. Ale pravdou je, že co jsem se pustil do realizace iVysílání verze 1 (ta poslední funkční měla tuším verzi 0.3.0), byla to divoká jízda. Ostatně, snažil jsem se to tu v několika posledních příspěvcích popsat. Ale realita byla, naštěstí, nakonec jiná. Daleko jednodušší. Při diskusi s @waladir: jsem byl upozorněn, že v poledních verzích GRAPHQL rozhraní, a jeho dat pro EPG, by snad měla existovat i jednoznačná relace mezi vysílanými pořady a interními kanály iVysílání, a to i pro budoucí pořady a dokonce v rozsahu běžném i pro ostatní kanály ČT. A skutečně, relace tam existuje a je jednoduše dostupná. Takže zpátky na stromy, nová verze iVysílání dostane místo nového kabátu zase jen ten starý, ale přešitý, vyčištěný a vyžehlený. Tak vydržte, dělám na tom...