11.10.2020, 16:04
(Tento příspěvek byl naposledy změněn: 11.10.2020, 16:05 uživatelem JiRo.
Důvod úpravy: Překlepy
)
@Husnak Tady je každá rada drahá. Mohu na to zareagovat krátce nebo dlouze.
Nejdříve krátce...
Konkrétně ti neporadím. Nevím, jak vývoj skinu Estuary SC2 pokračuje. Shodou okolností jsem se na to dnes na Skype zeptal jeho autora @Gargy007 , ale odpověď jsem ještě nedostal. V podstatě máš dvě cesty. Buď tu, o které se tady i na fóru SCC už psalo, tzn. zkusit odložit náběh skinu nebo použít některý ze skinů, který se současnou verzí SCC funguje dobře. V tom druhém případě ti doporučuji opět fórum SCC, kde tě určitě na takový skin navedou.
A teď dlouze, ale předem tě varuji, řešení tu nenalezneš. Spíše shrnutí toho, proč se někteří do problémů s SCC dostali a někteří ne...
S novými verzemi SCC jsme se dostali do situace, že správná funkce addon a skinu je (víceméně) závislá na náhodě. Zní to možná divoce, ale je to tak. To, že někdy a někomu to funguje bez problémů, jinému jen občas a někomu vůbec závisí, na několika faktorech. Nejdůležitější z nich jsou:
ad. 1 Wigety (resp. jejich containery) se plní tak, že se zavolá addon s příslušnými parametry podle typu obsahu, a ten naplní příslušný container. Čím více widgetů má člověk definováno, tím je tato fáze po spuštění KOdi, resp. nábehu sksinu, delší. Je také (většinou) delší u addon, které pracují ve dvojici client/server, kde klientskou částí je vlastní addon Kodi, server je kdesi na internetu a data z něj se přes ten internet tahají. Hezky je to vidět, když si u nějakého takového addon pustíš nějakou funkci. Většinou se chvíli točí kolečko (nebo se "hýbe jiný grafický prvek" indikující "že Kodi pracuje..."), pak se kolečko přestane točit a po chvíli se zobrazí příslušný výsledek. Točící se kolečko indikuje, že se stahují data z internetu (nebo získávají nějak jinak - například z lokální cache, cachujícího proxy serveru, ...), jakmile se kolečko přestane točit, znamená to, že addon ze stažených dat sestavuje obsah containeru. Je jasné, že tahle fáze je hodně závislá na dvou věcech - jak máš rychlou síť (LAN, WAN a služby providera a vůbec, celou cestu až k serveru) a pak také, jak máš rychlý HW, hlavně CPU a obsluhu všech relevantních částí (např. síťové rozhraní, disk/karta, ...). Tady je jeden z klíčových prvků náhody, třeba v tom, že většinou lidé sledující výkon GPU, ale o CPU a zejména další operace jim až tolik nejde a dojde jim, že sice mohou přehrávat bez problému 4K HDR obsah, ale CPU jejich stroje je bída a utrpení.
ad. 2 Pořadí widgetů... Widgety, které se spouští dříve jak jiné, se mohou po startu dostat do křížku s jinými funkcemi Kodi a zejména addon, které jsou aktivní (nebo významně aktivnější) právě krátce po startu. O to více pak probíhá soupeření o zdroje a pokud je těch požadavků více než je zdrávo, může se stát, že gui data pro zobrazení funkce (v tomto případě zobrazení widgetu) nedojdou v limitu. Přesunem jádra funkcí SCC, které se jinak vykonávaly v rámci každého volání addon (tedy v rámci každého volání pro naplnění widgetu), do service modulu běžícího na pozadí, došlo k tomu, že po krátce po startu addon není schopen na běžná volání odpovědět tak rychle, protože ještě nedoběhla iniciální fáze service, kterou pro to potřebuje. Proběhne tedy timeout, a po něm už se widget nenaplní. Hezky to ilustruje konkrétní případ v SCC, kdy pouhé přesunutí pořadí widgetů, kdy se jako porvní spouštěl widget TV Programu, se porblém vyřešil (alespoň pro danou chvíli). Bylo to proto, že tento widget, respektive tato funkce služby service modulu pro svůj běh nepožadovala. Čas načtení a zobrazení tohoto widgetu pak stačil k tomu, aby inicializace service doběhla a další widgety, které už ji pro svou funkci potřebovaly, se už načetly v pořádku.
ad. 3 Typ skinu je hodně důležitý. V podstatě existujuí dva základní typy. První, kterým je kupř. Estuary, které pro svou funkci nepožaduje žádné další pomocné addons. Vše, co je v tomto skinu realizováno je relizováno pouze funkcemi gui a jeho enginu. Druhý, to jsou skiny typu ANS, Estuary MOD 2, rodina Titan, Arctit Zephyre, rodina Aura, apod. jsou skiny, které pro své funkce využívají širokou rodinu tzv. Helperů, což jsou addons, které pro skin vykonávají celou řadu pomocných funkcí. Mezi jinými i takové, které přednačítají data pro widgety. Část z nich má i svou část service. Tyto service se někdy mohou dostat se service addons, které zajišťují data pro volání addon pro widgety, do jakési interference, která se (a v tom je ona v úvodu zmíněná náhoda) někdy projeví pozitivně, jindy zase negativně. Někdy prostě ta data pro widgety dostane Kodi včas, jindy ne. Jistou roli v tom ještě může sehrát to, zda funkce addon používají lokální cache a jak je jejich obsluha zajištěna. Ale zahrnout do popisu chování ještě temto aspekt, to by už vydalo na ještě hutnější text.
ad. 4 Jak pracuje addon... To už bylo v podstatě zmíněno. Má-li addon svou service část na které jsou funkce běžného volání závislé, tak záleží zejména na tom, jak rychle po startu jsou tato běžná volání, která plní widgety, dostupná. A opět. Nedá se to nijak pregnatně definovat, proto píšu o tom prvku náhody.
Suma sumárum, těch aspektů je celá řada, ty čtyři jsou jen jakýmsi rámcovým okruhem, působí současně, některé z nich v pozitivním, jiné v negativním směru (s ohledem na požadavky jednotlivých funkcí) a ukočírovat to vždycky a za všech okolností a pro různou skladbu parametrizace Kodi (používané základní funkce, včetně např. PVR, velikost knihoven, skladba a typy addons, používaný skin, ...) a prostředí na kterém je provozováno (HW, systém, standalone instalace vs společná databáze, ...) není jednoduché. To je ostatně důvod k tomu, že když jsem se seznámil s novou verzí řešení jádra SCC, tak jsem z používání addon doma raději vycouval. Bohužel to neplatí absolutně, protože část lidí, kterým se o Kodi starám, na něm trvají. Neříkám, že je to špatný nápad. Jsou addon, které to řeší podobně, a jsou to ty addon, se kterými jsem už nějaké zkušenosti nasbíral. Pozitivní i negativní. Proto ten despekt či spíše opatrnost. Ono je vidět, že nějaký vývoj tyto verze SCC už za sebou mají a postupně se to zlepšuje. Je otázka, zda to povede k sitiuaci, kdy to problém nebude u nikoho, bez ohledu na použitý skin, skladbu addons, typ instalace, HW a systému. Na druhou stranu, pokud je pro někoho (a takových lidí je asi většina), rozhodující kombinace Kodi + SCC, stačí si vybrat ten skin, který si s SCC rozumí, a je po problému. Ale to už jsem napsal výše...
Nejdříve krátce...
Konkrétně ti neporadím. Nevím, jak vývoj skinu Estuary SC2 pokračuje. Shodou okolností jsem se na to dnes na Skype zeptal jeho autora @Gargy007 , ale odpověď jsem ještě nedostal. V podstatě máš dvě cesty. Buď tu, o které se tady i na fóru SCC už psalo, tzn. zkusit odložit náběh skinu nebo použít některý ze skinů, který se současnou verzí SCC funguje dobře. V tom druhém případě ti doporučuji opět fórum SCC, kde tě určitě na takový skin navedou.
A teď dlouze, ale předem tě varuji, řešení tu nenalezneš. Spíše shrnutí toho, proč se někteří do problémů s SCC dostali a někteří ne...
S novými verzemi SCC jsme se dostali do situace, že správná funkce addon a skinu je (víceméně) závislá na náhodě. Zní to možná divoce, ale je to tak. To, že někdy a někomu to funguje bez problémů, jinému jen občas a někomu vůbec závisí, na několika faktorech. Nejdůležitější z nich jsou:
- kolik a jakých widgetů máš definováno
- v jakém pořadí se widgety načítají
- jaký typ skinu používáš
- jak pracuje addon, kterými widgety plníš, obecně i konkrétně, co se týče SCC
ad. 1 Wigety (resp. jejich containery) se plní tak, že se zavolá addon s příslušnými parametry podle typu obsahu, a ten naplní příslušný container. Čím více widgetů má člověk definováno, tím je tato fáze po spuštění KOdi, resp. nábehu sksinu, delší. Je také (většinou) delší u addon, které pracují ve dvojici client/server, kde klientskou částí je vlastní addon Kodi, server je kdesi na internetu a data z něj se přes ten internet tahají. Hezky je to vidět, když si u nějakého takového addon pustíš nějakou funkci. Většinou se chvíli točí kolečko (nebo se "hýbe jiný grafický prvek" indikující "že Kodi pracuje..."), pak se kolečko přestane točit a po chvíli se zobrazí příslušný výsledek. Točící se kolečko indikuje, že se stahují data z internetu (nebo získávají nějak jinak - například z lokální cache, cachujícího proxy serveru, ...), jakmile se kolečko přestane točit, znamená to, že addon ze stažených dat sestavuje obsah containeru. Je jasné, že tahle fáze je hodně závislá na dvou věcech - jak máš rychlou síť (LAN, WAN a služby providera a vůbec, celou cestu až k serveru) a pak také, jak máš rychlý HW, hlavně CPU a obsluhu všech relevantních částí (např. síťové rozhraní, disk/karta, ...). Tady je jeden z klíčových prvků náhody, třeba v tom, že většinou lidé sledující výkon GPU, ale o CPU a zejména další operace jim až tolik nejde a dojde jim, že sice mohou přehrávat bez problému 4K HDR obsah, ale CPU jejich stroje je bída a utrpení.
ad. 2 Pořadí widgetů... Widgety, které se spouští dříve jak jiné, se mohou po startu dostat do křížku s jinými funkcemi Kodi a zejména addon, které jsou aktivní (nebo významně aktivnější) právě krátce po startu. O to více pak probíhá soupeření o zdroje a pokud je těch požadavků více než je zdrávo, může se stát, že gui data pro zobrazení funkce (v tomto případě zobrazení widgetu) nedojdou v limitu. Přesunem jádra funkcí SCC, které se jinak vykonávaly v rámci každého volání addon (tedy v rámci každého volání pro naplnění widgetu), do service modulu běžícího na pozadí, došlo k tomu, že po krátce po startu addon není schopen na běžná volání odpovědět tak rychle, protože ještě nedoběhla iniciální fáze service, kterou pro to potřebuje. Proběhne tedy timeout, a po něm už se widget nenaplní. Hezky to ilustruje konkrétní případ v SCC, kdy pouhé přesunutí pořadí widgetů, kdy se jako porvní spouštěl widget TV Programu, se porblém vyřešil (alespoň pro danou chvíli). Bylo to proto, že tento widget, respektive tato funkce služby service modulu pro svůj běh nepožadovala. Čas načtení a zobrazení tohoto widgetu pak stačil k tomu, aby inicializace service doběhla a další widgety, které už ji pro svou funkci potřebovaly, se už načetly v pořádku.
ad. 3 Typ skinu je hodně důležitý. V podstatě existujuí dva základní typy. První, kterým je kupř. Estuary, které pro svou funkci nepožaduje žádné další pomocné addons. Vše, co je v tomto skinu realizováno je relizováno pouze funkcemi gui a jeho enginu. Druhý, to jsou skiny typu ANS, Estuary MOD 2, rodina Titan, Arctit Zephyre, rodina Aura, apod. jsou skiny, které pro své funkce využívají širokou rodinu tzv. Helperů, což jsou addons, které pro skin vykonávají celou řadu pomocných funkcí. Mezi jinými i takové, které přednačítají data pro widgety. Část z nich má i svou část service. Tyto service se někdy mohou dostat se service addons, které zajišťují data pro volání addon pro widgety, do jakési interference, která se (a v tom je ona v úvodu zmíněná náhoda) někdy projeví pozitivně, jindy zase negativně. Někdy prostě ta data pro widgety dostane Kodi včas, jindy ne. Jistou roli v tom ještě může sehrát to, zda funkce addon používají lokální cache a jak je jejich obsluha zajištěna. Ale zahrnout do popisu chování ještě temto aspekt, to by už vydalo na ještě hutnější text.
ad. 4 Jak pracuje addon... To už bylo v podstatě zmíněno. Má-li addon svou service část na které jsou funkce běžného volání závislé, tak záleží zejména na tom, jak rychle po startu jsou tato běžná volání, která plní widgety, dostupná. A opět. Nedá se to nijak pregnatně definovat, proto píšu o tom prvku náhody.
Suma sumárum, těch aspektů je celá řada, ty čtyři jsou jen jakýmsi rámcovým okruhem, působí současně, některé z nich v pozitivním, jiné v negativním směru (s ohledem na požadavky jednotlivých funkcí) a ukočírovat to vždycky a za všech okolností a pro různou skladbu parametrizace Kodi (používané základní funkce, včetně např. PVR, velikost knihoven, skladba a typy addons, používaný skin, ...) a prostředí na kterém je provozováno (HW, systém, standalone instalace vs společná databáze, ...) není jednoduché. To je ostatně důvod k tomu, že když jsem se seznámil s novou verzí řešení jádra SCC, tak jsem z používání addon doma raději vycouval. Bohužel to neplatí absolutně, protože část lidí, kterým se o Kodi starám, na něm trvají. Neříkám, že je to špatný nápad. Jsou addon, které to řeší podobně, a jsou to ty addon, se kterými jsem už nějaké zkušenosti nasbíral. Pozitivní i negativní. Proto ten despekt či spíše opatrnost. Ono je vidět, že nějaký vývoj tyto verze SCC už za sebou mají a postupně se to zlepšuje. Je otázka, zda to povede k sitiuaci, kdy to problém nebude u nikoho, bez ohledu na použitý skin, skladbu addons, typ instalace, HW a systému. Na druhou stranu, pokud je pro někoho (a takových lidí je asi většina), rozhodující kombinace Kodi + SCC, stačí si vybrat ten skin, který si s SCC rozumí, a je po problému. Ale to už jsem napsal výše...