18.4.2022, 9:49
(Tento příspěvek byl naposledy změněn: 19.4.2022, 8:34 uživatelem JiRo.
Důvod úpravy: Doplnění informací, překlepy
)
Tak konečně zprovozněno na CE 19.4 Matrix na Beelink GT-King, dedikovaný Tvheadend 4.3 na intel PC. ffmpeg používám z repozitáře CoreELEC Add-ons. S ffmpeg byl drobný problém, addon ho nedokázal spustit, takže jsem musel v kódu udělat malou rychlou změnu a zadat tam celou cestu k aplikaci. Teď to funguje přesně tak, jak autor @mltobi popisuje.
V ukázce sleduji v Kodi Live TV jeden kanál z OTT O2TV, druhý (ze stejné služby) je zobrazován v okně přes addon pip:
To samé pohledem stavu v Tvheadend:
Ovládání mám přes DO. Jinak to ani jednoduše nejde, addon lze díky díky unikátnímu používání built-in příkazu Kodi NotifyAll posílanému do běžící service nejlépe ovládat takto. Použil jsem longpress klávesy 0. Tato klávesa je, jak známo, v Kodi Live TV nativně používána k přepínání mezi dvěma posledně navolenými programy, takže v kombinaci s longpress použitým pro ovládání addon-u pip je to docela přirozené, až návykové.
Měl jsem v plánu to ovládání nějak předělat, vylepšit ho.
Ale nakonec jsme zjistil, že v té jednoduchosti řešení, které autor zvolil, je přesně to, co člověk od takové funkce potřebuje. V kombinaci s dvojím využitím klávesy 0 na DO (normal a long-press) to prostě nemá chybu. Spíše se tedy nyní soustředím na to, použít prinip, na kterém je addon postavený, k funkci, o které tady psal @meda (viz dále).
Nyní teddy mírné OT k funkci pip, kterým bude funkce mozaiky s "live screenshoty". To co autor v addon pip vytvořil je docela dobrým základem k realizaci funkce, která sice není příliš užitečná (ve smyslu "dá se bez ní žít"), zato je ale velmi efektní. Její realizace je tedy spíše taková libůstka, nebo možná výzva, protože se v ní slučuje potřeba řešit několik problémů.
Live TV screenshot funkce, skinning, případně ukládání většího množství dat. Většinu kolem Live Tv screenshot už vyřešil @mltobi, se skiningem si poradím, zbývá (pokud k tomu řešení povede, protože tady je více možností) ona potřeba ukládání většího množství dat. Těmi daty myslím odložené screenshoty všech kanálů, které se navíc budou cyklicky přepisovat. No a pokud máte, jako já více než 150 kanálů, a chcete-li dospět k nějakému efektivnímu řešení, tzn. zajistit obnovu v nějakém rozumném čase, tedy každé cca 2-3 sekundy na kanál (víc Tvheadend nezvládne), je jasné, že datový tok bude pro ukládání na obvyklé médium (kartu) Android boxů neúměrný.
Kromě konkrétních pokusů (psaní kódu) tedy zatím probíhá analytická fáze řešení. V jejich průběhu jsme se už začal zabývat využitím RAM disku, ale tam zatím narážím (v případě *ELEC) na jisté problémy. Dá se ale předpokládat že tohle snad vyřeším později. V té souvislosti se mi otevřelo další téma, tedy úvaha nevytvářet a neukládat screenshoty jednotlivých kanálů na straně klienta, ale rovnou na serveru. Tedy stroje na kterém běží Tvheadend. V mém případě je to klasické PC, takže tam se bez RAM disku zatím objedu, SSD disk, na kterém to teď běží to množství zápisů vydrží rozhodně déle, jak ssd karta na android boxu. Kodi na klientech by pak využívaly odkazy na soubory screenshotů identifikované názvem kanálů. Takováto dekompozice řešení se zdá být perspektivnější. Na straně klienta by to v podstatě vedlo pouze na doplnění dalšího(-ch) pohledu(-ů) do PVR zobrazení kanálů. Podobně jsem tam kdysi už přidal zobrazení typu Zeď resp. Zeď extended, takže teď bych jen u všech typů zobrazení vyměnil loga za screenshoty, případně doplnil screenshoty tam, kde je na to místo, což by už byla v kontextu celého řešení jen drobnost.
V ukázce sleduji v Kodi Live TV jeden kanál z OTT O2TV, druhý (ze stejné služby) je zobrazován v okně přes addon pip:
To samé pohledem stavu v Tvheadend:
Ovládání mám přes DO. Jinak to ani jednoduše nejde, addon lze díky díky unikátnímu používání built-in příkazu Kodi NotifyAll posílanému do běžící service nejlépe ovládat takto. Použil jsem longpress klávesy 0. Tato klávesa je, jak známo, v Kodi Live TV nativně používána k přepínání mezi dvěma posledně navolenými programy, takže v kombinaci s longpress použitým pro ovládání addon-u pip je to docela přirozené, až návykové.
Kód:
<zero mod="longpress">NotifyAll(service.pip,toggle_pip)</zero>Měl jsem v plánu to ovládání nějak předělat, vylepšit ho.
Ale nakonec jsme zjistil, že v té jednoduchosti řešení, které autor zvolil, je přesně to, co člověk od takové funkce potřebuje. V kombinaci s dvojím využitím klávesy 0 na DO (normal a long-press) to prostě nemá chybu. Spíše se tedy nyní soustředím na to, použít prinip, na kterém je addon postavený, k funkci, o které tady psal @meda (viz dále).Nyní teddy mírné OT k funkci pip, kterým bude funkce mozaiky s "live screenshoty". To co autor v addon pip vytvořil je docela dobrým základem k realizaci funkce, která sice není příliš užitečná (ve smyslu "dá se bez ní žít"), zato je ale velmi efektní. Její realizace je tedy spíše taková libůstka, nebo možná výzva, protože se v ní slučuje potřeba řešit několik problémů.
Live TV screenshot funkce, skinning, případně ukládání většího množství dat. Většinu kolem Live Tv screenshot už vyřešil @mltobi, se skiningem si poradím, zbývá (pokud k tomu řešení povede, protože tady je více možností) ona potřeba ukládání většího množství dat. Těmi daty myslím odložené screenshoty všech kanálů, které se navíc budou cyklicky přepisovat. No a pokud máte, jako já více než 150 kanálů, a chcete-li dospět k nějakému efektivnímu řešení, tzn. zajistit obnovu v nějakém rozumném čase, tedy každé cca 2-3 sekundy na kanál (víc Tvheadend nezvládne), je jasné, že datový tok bude pro ukládání na obvyklé médium (kartu) Android boxů neúměrný.
Kromě konkrétních pokusů (psaní kódu) tedy zatím probíhá analytická fáze řešení. V jejich průběhu jsme se už začal zabývat využitím RAM disku, ale tam zatím narážím (v případě *ELEC) na jisté problémy. Dá se ale předpokládat že tohle snad vyřeším později. V té souvislosti se mi otevřelo další téma, tedy úvaha nevytvářet a neukládat screenshoty jednotlivých kanálů na straně klienta, ale rovnou na serveru. Tedy stroje na kterém běží Tvheadend. V mém případě je to klasické PC, takže tam se bez RAM disku zatím objedu, SSD disk, na kterém to teď běží to množství zápisů vydrží rozhodně déle, jak ssd karta na android boxu. Kodi na klientech by pak využívaly odkazy na soubory screenshotů identifikované názvem kanálů. Takováto dekompozice řešení se zdá být perspektivnější. Na straně klienta by to v podstatě vedlo pouze na doplnění dalšího(-ch) pohledu(-ů) do PVR zobrazení kanálů. Podobně jsem tam kdysi už přidal zobrazení typu Zeď resp. Zeď extended, takže teď bych jen u všech typů zobrazení vyměnil loga za screenshoty, případně doplnil screenshoty tam, kde je na to místo, což by už byla v kontextu celého řešení jen drobnost.