Přihlásit se na XBMC-Kodi.cz

@Jaffa: Možná zná někdo lepší způsob. Já ti mohu jen poradit, abys film odskákal až k závěrečným titulkům a ty potom nechal dojet. Film bude pak "regulérně" dokoukaný a smázne se. U seriálů je možný stejný způsob. To se, bohužel, netýká seriálů, kde jsou některé díly nedostupné. To ti tam zůstane viset.

@jkmh: Nebo stačí označit jako zhlédnuté a taky se smázne. U takto označených filmů, pak ale někdy přemýšlím, o čem že to bylo, než si uvědomím, že jsem ho vlastně neviděl. A některé seriály, jak píšeš, tam zůstávají viset.

@Jaffa: @jkmh: Přesně problémy o kterých mluvíte mě raději přiměly tuto funkci skrýt. Bohužel, schovala se dokonale. Od té doby nejdou skryté zobrazit. Co skryto jest, skryté zůstane.

@Tomik68: Pak je ještě jedna možnost. Vrátit se na verzi 1.11.17. Tedy pokud v ní není něco jiného špatně. To je poslední verze bez této funkce. A zakázat aktualizace.

@Tomik68 Pkračovat ve sledování zatím vyhodili a ve skrytých je chyba. Jinak ano, jsou v SCC funkce, které jsem hned poté, co jsem se s nimi a logikou jejich funkce seznámil, skryl nebo je nepoužívám, protože mám o nich pochybnosti. Pokračovat ve sledování a TV program jsou ty hlavní z nich...

@JiRo: Přesně, jak píšeš, tyto dvě (pro mne zbytečné) funkce jsem skryl.

@Tomik68 Což ale neznamená, že by nemohly škodit i tak a tím se dostáváme k dalšímu mýtu.

Addon mám nainstalovaný, ale vůbec jsem ho nespustil a přesto...

Velmi často se nějak addon "zblázní" a začně škodit. Jako třeba v současné době SCC. Ale často, když se uživatelů v případě nějakých problémů ptám, co se dělo, odpoví "Ale já jsem plugin vůbec nespustil a přesto...", a uvedou nějaký problém, který se s daným addon pojí. To, že daný plugin nespustíte ještě neznamná, že spuštěn, či alespon jeho část, být nemohl. V podstatě mohou nastat dvě situace.

Widget

Zdrojem dat widgetu může být obsah načtený z databáze Kodi, to je prapůvodní a jediný způsob, který byl ale v průběhu vývoje Kodi doplněn o možnost načtení obsahu prostřednictvím spuštění pluginu. Některé skiny tuto možnost mají zpřístupněnou v rámci své parametrizace, a tak si mnohdy ani člověk neuvědomí, když v takové parametrizaci jako zdroj zadá plugin, že spuštěním Kodi, kdy se widgety poprvé načítají, se spustí (často poprvé) i plugin. A aby to nebylo tak jednoduché, díky tomu, jak addons v Kodi fungují, je možné, pokud je takových widgetů více, že se plugin spustí i vícekrát.

Service

Některé addon, a je jich poměrně dost, mají část svého kódu obsaženu v části, které se říká service. Je to část, která se v Kodi spustí hned po jeho startu a běží, vůči vlastnímu pluginu, nezávisle a asynchronně. Jejich vzájemní vazba je velmi volná, v podstatě spolu mohou, za pomoci některých konstrukcí a funkcí v knihovnách Kodi, sdílet soubor nastavení, ale jinou vazbu si už musí programátor definovat explicitně. Problémem je, že původně byly service zamýšleny jako podpora nějaké omezené množiny funkcí v rámci addon, někteří autoři z nich ale udělal jakési jádro funkce pluginu. Platí to například pro addon Netflix a také (a tam ve značné míře) pro SCC. Tam service zajišťuje poměrně zásadní množinu funkcí pro vlastní plugin, probíhá tam zpravidla komunikace na bázi socket nebo se data vyměňují prostřednictvím jiných technik. Často tak dochází k sitiuacím, kdy service, pokud není ve 100% kondici a nedodá data pro plugin včas, jeho funkci paralyzuje.

Widget + Service

V některých případech se mohou tyto dva aspekty negativně propojit a vystavit tak uživatele, stejně jako autory v případě, pokud si nebezpečí nepřipustí, problémům. Myslím tím situaci, kdy se po startu Kodi spustí service a zároveň jednotlivé widgety začnou spouště jednu instanci plugun-u za druhou. Service nestač data pro plugin připravovat a..., problém je na světě. Dělo se to kdysi právě u SCC, pamětníci si vzpomenou na workardound, který posouval spuštění skinu po spuštění Kodi a umožnil tak service, aby se správně incializovala. Bez této úpravy někomu SCC vůbec nefungovalo.

Co si z toho vzít za ponaučení

Autorům jen jedno doporučení, "Buďte obezřetní". Nechci říkat, že by service neměly používat, ale musí počítat s tím, že čím budou jeho funkce v rámco addon významnější a rozsáhlejší, tím více se mohou případné problémy eskalovat. Nechci být jak Sheldon Cooper, a napsat "Já jsem to říkal", ale říkal jsem to. V době, kdy ten masivní přesun funkcí addon SCC do části service proběhl jsem varoval (a tady na fóru o tom s hlavním autorem SCC diskutoval), že to nemusí mít jen pozitivní stránky a že to bude, v mnoha případech zdrojem potenciálních problémů, a autory to bude udržovat v neustálé pohotovosti. Tím více, čím se do service přesune více funkcí. A stalo se. Minimálně 2x ve větším (téměř masovém) měřítku a několikrát v menším (problémy s nastavením SCC, které tomuto fenoménu můžeme také přičíst). V případě těch dvou velkých, poprvé u již zmiňovaného problém po startu Kodi, a nyní, kdy běh service s chybou projevující se rekurzivním volání funkce, vyčerpá operační paměť. Ona ani v jednom případě není chyba v tom, že je to service, ale díky tomu, že to service je, to má takové důsledky a dopady.

Uživatelům pak to, že je potřeba být obezřetný. Je mi jasné, že ne vždy a ne všichni uživatelé úplně přesně vědí, co dělají, když například využívají parametrizační možnosti některých skinů (mimochodem, některé skiny, aby mohly dobře fungovat, instalují si addon typu service, ale to je už téma na další díl seriálu Mýty a fakta). A také vědět, co jsem se tu dnes snažil vysvětlit. Že i když plugin nespustí, může běžet bez jejich aktivity na základě nějakého jiného nastavení, například zmíněných widgetů. A pak také to, že proste někdy část service addon může běžet bez jakéhokoliv dalšího vlivu a kromě jeho deaktivace mu v tom nezabrání nic.

Ahoj prosím o radu , mam novou TV samsung 4k + teslou box na Kodi. Při sledování jakých kolik filmů, se mi film seká a točí kolečko net mám od 02, tažený kabelem i do tv , net rychlost 250/25 což by mělo stačit. Film 2gb nebo 90gb je jedno seká se několikrát za film nevíte co s tím? Co by pomohlo ? Moc díky

Je lepší Meson IR nebo AmRemote?

Častá otázka těch, kteří se rozhodnou zprovoznit v *ELEC systému IR DO, tedy dálkové ovládání s přenosem informací pomocí inračerveného záření. V řadě diskusí se vysvětlují postupy a podmínky, podle a za kterých lze jak jedno, tak druhé řešení, použít. Většinou se preference přiklání na stranu AmRemote, přičemž z celé řady důvodů pro a proti  tomuto řešení většinou padne zásadní argument: AmRemote je lepší, protože umí dlouhý stisk.

Pravda je taková, že AmRemote dlouhý stisk sám o sobě "neumí", jen pro něj v Kodi vytváří správný předpoklad, a to především tím, že se jeho rozhraní v Kodi prezentuje (a tím pádem také mapuje) jako vstupní zařízení typu klávesnice (keyboard), zatímco dálkový ovladač zpracovávaný v systému prostřednictvím Messon IR jako dálkové ovládání (remote). A jak známo, dlouhé stisky při mapování pro zařízení typu remote se v Kodi, na rozdíl od zařízení typu keyboard, zpracovávat neumí.

Mohli bychom tu vypočítávat celou řadu dalších rozdílů, jak ve složitosti řešení jedním či druhým způsobem, tak například v možnostech, které jedno či druhé řešení nabízí pokročilým uživatelům. Obecně se dá říci, že čím méně je uživatel zkušenější, čím více používá nějaký standardní ovladač, pro který má AmRemote připravený konfigurační soubor, tím výhodnější je použít právě AmRemote. Pokud ale chcete například připojit DO, které v současné nabídce řešení pro AmRemote není, je to mírně složitější. A už vůbec je to zásadně složitější, či skoro nemožné, použít AmRemote v případě, pokud chcete zpracovávat stisky na DO ještě před tím, než je dostane Kodi.  V takovém případě bude jednodušší použít Meson IR.

Jednoznačně tedy platí to, co už bylo řečeno v úvodu, že v první fázi rozhodování o výběru použité metody, Meson IR nebo AmRemote, chcete-li spolehlivě používat v Kodi při vašem mapování tlačítek dálkového ovladače tzv. longpress, tedy dlouhý stisk, musíte si vybrat AmRemote. A dálkový ovladač pak mapovat jako keyboard. Pokud si vyberete Meson IR, tak dlouhý stisk velmi pravděpodobně (či spíše téměř jistě) nebudete moci použít. To je, v dnešné době používání minimalizovaných ovaděčů s pár tlačítky, téměř jistě pro výběr jedné z obou možných metod poměrně zásadní kritérium.

Mýtů a faktů je kolem dálkového ovládání v Kodi a jeho instalacích hodně a já se pokusím se jim tady věnovat postupně poněkud více. Jako další se nabízejí témata:

• Zapínání/probouzení a uspávání/vypínání Kodi/systému. Jaký je mezi tím z hlediska DO rozdíl?
  
• Mám DO jehož některá tačítka komunikují přes IR, jiná přes RF/BT. To asi v Kodi nemůžu použít?
  
• Mé DO s RF/BT způsobem přenosu posílá kódy, které Kodi nezná a nijak na ně nereaguje. Asi ho můžu vyhodit, ne?
  

Mýty a fakta o Trakt.tv (1) - Seznam ke shlédnutí (Watchlist) a seriály
 

---

Nejdříve stručný úvod k plánovanému miniseriálu...

Trakt.tv je webový server, služba, která o sobě říká (parafrázováno):

Zaznamenejte, které tituly jste již sledovali, přidávejte zajímavé tituly, které plánujete sledovat, do seznamů, objevujte co je zajímavé, zjistěte kde je možné něco získat ke sledování, zajímejte se, co se připravuje, získejte doporučení od jiných a mnoho dalšího!

---

Jedním z velmi důležitých seznamů, které Trakt svým uživatekům nabízí, je tzv. Seznam ke shlédnutí, v originále Watchlist. Já osobně tento seznam, a jeho začlenění do Kodi a vybraných doplňků, považuji za jednu z vůbec nejpřínosnějších funkcí. Hned za funkcí, která umožní v Trakt zaznamenat to, co jsem už sledoval.

V doplňku Stream Cinema Community, kde jsou funkce Trakt přímo integrovány do samotného doplňku, je vytvořena poměrně významná funkce. Tou je možnost přidávat automaticky přidávat obsah Seznamu ke shlédnutí do knihovny Kodi (to si ale nechám na nějaký další díl tohoto miniseriálu). To rozšiřuje základí možnost si analogický seznam prohlédnout i v samotném doplňku, v menu Trakt.tv. No a tady se dostáváme k řadě mýtů, které tuto skupinu funkcí provází. Obecně se tyto mýty dají charakterizovat jako: funkce Trakt v Kodi i doplňku SCC nefungují nebo nefungují správně... Zkusme si to tedy rozebrat jedno po druhém.

Ve Watchlist v Trakt.tv mám více titulů, než kolik jich vidím, v Seznamu ke shlédnutí v SCC.

Pochopitelně! V SCC totiž uvidíte pouze ty tituly ze seznamu Watchlist v Trakt.tv, které jsou v dané chvíli v databázi SCC.

Některé tituly v SCC nemají v kontext menu položky Trakt (Trakt.tv Menu nebo Trakt Označit za zhlédnut)

Ano, to se stát může, ale není to chyba doplňku, ale chyba v datech databáze SCC. Prostě tento titul nemá v databázi odpovídající vazbu na Trakt, chybí mu Trakt Id. Může to být proto, že tento titul v Takt.tv vůbec ještě není, což se stává málokdy, častěji u exotických titulů, často těch domácích nebo obecně z menších a méně významných produkcí,  viz Pozn. A nebo ho tam to prostě správce datbáze SCC zapomněl vložit.

Pozn. Stav, kdy titul není v Trakt.tv nastává v okamžikú, kdy psrávce databáze většinou vytváří nový záznam v  některé z databázi. Pro to, aby nějaký titul v Trakt.tv měl záznam, je totiý podmíéna, aby měl už záznam buď TMDB, IMDB nebo TheTVDB. Takže pokud ho v žádné z nich ještě neměl, tak ho nemohl mít ani v Trakt.tv.

Pořadí titulů v Seznamu ke shlédnutí v SCC neodpovídá pořadí titulů ve Watchlist v Trakt.tv

To má (může mít) dva důvody. V tomto případě tedy první z nich:

Rozhraní (api) Trakt.tv který využívá i SCC, vždy předává data ze seznamu do doplňku seřazená podle atributu Rank. Tzn. že nezáleží, jak máte seznam seřazený na webu, v SCC ho vždy uvidíte, máte-li nastaveno Výchozí řazení, seřazené podle Rank. Tohle platí obecně, takže se to týká všech seznamů z Trakt.tv.

Když si seřadím seznam v Kodi (SCC) podle vybraného atributu, tak se mi v případě, že je seznam rozdělen na více stránek, seřadí (nebo mohu seřadit) pouze každá stránku zvlášť.

Ano, tohle je vlastnost Kodi, kde řazení funguje v rámci jednoho kontejneru. V případě doplňků, které své seznamy rozdělují po stránkách, je pro každou stránku vytvořen a naplněn vždy nový kontejner, takže případné změny v jeho zobrazení se provedou vždy jen pro aktuální stránku. Tento "problém" se dá, do jisté míry eliminovat tím, že si v SCC nastavíte velikost stránky na co možná největší hodnotu (500). Tím ten porblém, alespoň pro seznamy, které mají míně než tento limit, odpadne. Ovšem, za cenu delšího načítání jednotlivých seznamů.

Ze Seznamu ke sledování v Kodi (SCC) mi občas zmizí seriál. A když se to stane, tak ho nenajdu ani ve Watchlist v Trakt.tv. Stává se to jen u seriálů, ne u filmů.

Ano, tohle je vlastnost Trakt.tv. Seriály jsou z Watchlist v Trakt.tv odstraněny v okamžiku, kdy je alepsoň u jedné z epizod nastaven příznak shlédnuto. U filmů k žádnému automatickému odstranění nedochází. Tak prostě Trakt.tv funguje.

Čas vložení položky do Seznamu ke sledování v Kodi někdy neodpovídá (ale je zajímavé, že někdy ano) času vložení položky do Watchlist v Trakt.tv

Pochopitelně! Záleží totiž na tom, zda v databázi SCC, v okamžiku, když titul vložíte do Watchlist v Trakt.tv, už titul je a nebo ještě není. Pokud už tam titul je, tak se čas vložení do Kodi (SCC) bude shodovat s časem vložení do Trakt.tv. Pokud v databázi SCC ale ještě není, tak čas vložení do Kodi (SCC) bude odpovídat času vložení do databáze SCC.

Jak nejlépe nastavit video cache - <readfactor>

O tom, jak nejlépe nastavit videocachce se vedou nikdy nekončící debaty. V první řadě o tom, jak vůbec nastavení provést, a pak o tom, jak velkou pamět pro cache vymezit. To ale dnes (prozatím) nechám stranou a zaměřím se pouze na parametr, který obvykle většině lidí uniká pozornosti, parametr <readfactor>. Je to možná proto, že ne úplně všichni chápou, jaký je jeho význam a pak také proto, že v návodech, jak cache nastavit, se u toho parametru píše, že i když ho zvolíte jakkoliv vyšší než je default, tak to stabilitu běhu vašeho Kodi neohrozí. A známe to, pokud v tom není nějaký problém a nebezpečí, volí lidé přirozeně přístup "čím více, tím lépe". Možná, že se při tom řídí oním proslulým "Čím víc proužků, tím víc Adidas". 

Jaký je tedy význam tohoto prametru. <readfactor> neříká logice funcke video cache nic jiného, než to, jako rychlostí, oproti aktuální bitrate právě přehrávaného streamu, má načítat data do cache. Ta rychlost samozřejmě není neomezená, limitem je propustnost celého komunikačního řetězce mezi Kodi a zdrojem dat. Pokud je tedy nastavena hodnota hodně vysoká, nic se neděje, stejně větší rychlosti komunikace, než je maximálně možná, dosáhnout nelze.

Každý z nás samozřejmě chce, aby se data do Kodi načítala co možná nejrycheji a aby kapacita cache byla co možná největší. Tetelíme se radostí, když vidíme, jak se cache na začátku přehrávání filmu naplní na maximální kapacitu a jak se tam pak po celou dobu přehrávání drží. Přiznám se, že i mně se to vždycky líbilo. Otázkou dneška však je, zda je to správně. Odpovídm na ni, není! A zvláště ne v tom případě, který jsem popsal, tedy že se cache naplní a pak se po celou dobu přehrávání drží na maximální hodnotě. To je zbytečné a žádný přínos ani efekt to nemá. To je ale jen jeden aspekt. Ten druhý je, jak rychle se ta cache naplní. A to právě určuje parametr <readfactor>.

V současné době, kdy jsou tak často diskutované problémy při přehrávání streamů např. z SCC v prime time, se totiž stává, že zejména v čase, kdy se ze statistického hlediska dochází nejčastěji ke spuštění nějakého filmu, dochází zároveň ke zbytečnému, téměř skokovému, nárůstu zatížení komunikace, často až na několikanásobek potřebné kapacity. Pokud se sejde v jeden čas (někdy po 20 hodině večer) statisticky větší množství uživatelů (a můžeme vycházet z toho, že to tak pravděpodobně opravdu je), a každý s parametrm <readfactor> nastavený na hodnot 20 (nebo více), začne se všem načítat poměrně velkou rychlostí cache. Ta rychlost může být klidně rovna maximu dostupné rychlosti, což se samozřejmě projeví tím, že se příslušné profily dostanou na okamžik na hranici absolutní propustnosti. Toho si samozřejmě provideři všímají a tak jim nakonec nezbyde nic jiného, než začít rychlost omezovat (různými způsoby a různě agresivně). Paradoxem je, že při velmi vysoké hodnotě <readfactor> (běžné používané hodnoty jsou 20, ale mnoho z nás používalo a stále ještě používá i 40) i přehrávání filmu z rozumným bitrate (např. 10 Mbps), dokáže po spuštění vygenerovat tok rovnající se i maximu tarifu. A to zcela zbytečně.

Chceme-li se tedy chovat odpovědně, měl by se každý zamyslet nad tím, jaké nastavení je pro něj skutečně nutné. Obecně se dá říci, že např. hodnota <readfactor> 2 by měla být v drtivé většině případů dostačující. Zkušenější uživateé by si měli svá nastavení čas od času v reálu zkontrolovat, např. s použitím funkce Kodi Player Debug Info, aby viděli, jak se jim v reálu plní cache, jak pak vypadá při přehrávání a jakou hodnotu (v %) má buffer přehrávače.

Nechci samozřejmě tvrdit, že optimalizace nastavení hodnoty <readfactor> je všelék, ale každý "kamínek" může do celkové mozaiky přispět. V tomto případě bohužel jen tehdy, pokud se výše uvedeným doporučením budou řídit všichni nebo alespoň pokud možno co nejvíce z nás. Ono tady to známé české "Ať mi ostatní vlezou na záda, já si to nastavím jak budu chtít", může vést v konečném důsledku k tomu, že si nakonec filmy z SCC nepustí nikdy nikdo. Přemýšlejte o tom.

Jak nejlépe nastavit video cache - <memorysize>

Všichni známe obvyklou poučku, podle které se má volit hodnota <memorysize>, tedy stanovení maximální bezpečné velikost paměti video cache. Spočítá se jako 1/3 volné paměti po spuštění Kodi. Navíc se ještě doporučuje, ponechat pro vypočtěnou hodnotu nějakou "vatu" a proto se spočítané hodnota násobí ještě koeficientem, jehož hodnota se doporučuje někde v rozmezí 0,9 - 0,85. Kromě toho, a to se samozřejmě explicitně neuvádí, je třeba myslet i na to, co za procesy v systému, ve kterém běží Kodi, ještě běží také a může být, asynchornně a na pozadí, spuštěno kdykoliv po startu Kodi. Týká se to zejméně těch systémů, u kterých ke spuštění nějakého procesu, který si může alokovat významné množství paměti RAM, může dojít. A tím spíše, čím je ta případná alokace větší. Tak takhle to známe a řídíme se tím, stejně jako řada nástrojů, které nám onu doporučovanou maximální hodnotu <memorysize> vypočtou nebo dokonce i nastaví. Je to skutečně tak? V současné aktulní verzi, tedy Kodi 20, a tím spíše pak ve verzi následující, Kodi 21? Není! Ono je to, s velikostí stanovení maximální hodnoty <memorysize>, pravděpodobně trochu jinak.

Pokud se totiž, při stanovení nutné paměti pro <memorysize> hovoří o trojnásobku, týká se to toho, kolik může video cache požadovat maximálně paměti. To číslo 3 je ale pozůstatek z požadavku starších verzí Kodi, kde byla v rámci přehrávání definovaná video cache jako trojice bufferů označovaných jako history buffer, current buffer a lookahead buffer. To už ale tak úplně neplatí, protože to rozdělení a správa video cache je teď už trochu jiná. Nicméně ten trojnásobek v požadavcích zůstal, byť ho fakticky Kodi už nevyžaduje. Z dlouhodobého testování se potvrzuje, že video cache u posledních několika verzí Kodi je limitována pouze volnou pamětí, případně absolutním limitem 1 GB, což mimochodem potvrzuje i verze Kodi 21, kde je i tento absolutní limit v nastavení vidět. Samozřejmě si uživatel musí nechat nějakou rezervu, protože obsazení paměti se v průběhu běhu Kodi a jeho doplňků může měnit. To platí neustále, aniž by ale bylo řečeno, jak velká ta rezerva musí být. To totiž závisí na celé řadě dalších okolností, z nichž řada může být řešena (asynchronně, tedy bez závisloti na tom, co se v Kodi právě děje, jaká funkce je tam spuštěna) mimo Kodi (viz předchozí odstavec).

A jak tedy vlastně video cache funguje dnes? Můžeme si ji představit jako cyklický či kruhový buffer, do kterého se po spuštění videa začnou načítat data. Zároveň si z něj data čtou. To provádí Kodi player. Zatímco data se do bufferu videocache zapisují rychlostí čtení ze zdroje, ta rychlost je násobkem (<readfactor>) rychlosti (bitstream) přehrávaného streamu, player je čte rychlostí odpovídající právě hodnotě bitstreamu. Algoritmus obsluhy cyklického bufferu je nastaven tak, že v něm zůstává uložena část dat již přehraného streamu. Pro tuto část je vyhrazeno maximálně 25 % velikosti video cache. Zbytek, pak je vyhrazen pro data, která jsou do video cache přednačítána. Zatímco té první části se říká zpětný (backward) buffer, té druhé dopředný (forward) buffer. Ve zdrojové kódu Kodi je pak pevně je definováno, jaká maximální velikost aktuálně nastavené velikosti video cache bude vyhrazena pro zpětný (backward) buffer. To je dnes 25 %. Pro dopředný (forward) buffer je pak vždy alokován rozdíl 100 % mínus aktuální obsazení zpětného bufferu. V průběhu přehrávání, na jeho počátku, nebo po velkém skoku v přehrávání vpřed a nebo zpět, tak může krátkodobě dojít k tomu, že dopředný buffer obsadí více než 75 %. To se stane v případě, když rychlost načítání dat do video cache je mnohem vyšší, než rychlost čtení z ní. Ta, jak jsme si už řekli, odpovídá hodnotě bitstream přehrávaného streamu. V tomto případě pak záleží jednak na nastavené hodnotě <readfactor> a pak samozřejmě na limitu rychlosti čtení dat ze zdroje dat absolutně. A abych to celé dosadil do praktické roviny, aktuální velikost dopředného bufferu můžeme v reálu, při přehrávání, vidět, pokud si v Kodi spustíme Player Debug Info (ctrl+shift+o) jako hodnotu položky forward. Tam si také můžeme ověřit, po ustálení hranice mezi dopředným a zpětným bufferem, že obsazení toho dopředného skutečně odpovídá 75 % alokované velikosti pro video cache, tedy hodnotě uložené v <memorysize> nebo hodnotě v nastavení (u Kodi 21).

Já sám jsem měl s tím, pochopit současnou funkci video cache, dost problémy. Měl jsem plno otázek, které jsme si při svých pokusech s přehrávání v Kodi a nastavením video cache kladl. Bohužel mi na ně nikdo, ani zde, ale ani na fóru kodi.tv nedokázal odpovědět. Až teprve řada testů a analýz zdrojového kódu Kodi mi na ně dala, neříkám, že absolutně správnou, ale spíše nejpravděpodobnější odpověď. Pokud někoho zajímá, jak jsem v této oblasti postupně dospíval ke konečnému poznání, může se podívat na Strategie využívání video cache.

A pokud někoho, při čtění mých úvah, napadla určitá spojitost se zmiňovaným historickým členěním video cache na history buffer, current buffer a lookahead buffer a dnesním rozdělením na backward a forward buffer, myslím, že jste na dobré cestě to pochopit. Celé to pak do sebe do určité míry zapadá. A tím spíše je pak jasné, odkud se vzala ona trojka (či jedna třetina) v onom stále ještě existujícím doporučení na to, jak parametry video cache nastavit.

Text v příspěvku věc vyřešil a tedy jej měním na REZERVA.

Je vidět, že se díky tobě ve znalosti Kodi posouváme. Tady mám všetečnou otázku.

Citace:.....je limitována pouze volnou pamětí, případně absolutním limitem 1 GB.....

Ta hodnota je fixní bez ohledu na velikost RAM nebo si Kodi osáhne HW a maximum patřičně sníží/zvýší?

@jkmh Tak to by mne taky zajímalo.

Zatím mám Kodi 21 pouze na Windows, bohužel s 40 GB operační paměti a tam tedy ten limit bohužel nevyzkouším. Mohl bych na virtuálce, kde by šlo zmenšit paměť, ale žádnou s Windows teď práve nemám. Mám jen LibreELEC s Kodi 21, ale je to jen Nightly a u té poslední verze, co se dá stáhnout, ta funkce nastavení video cache ještě není.

---

Tak jsem se přehlédl. LibreELEC s Kodi 21 mám. Vyzkoušel jsem to, když stáhnu RAM na 1GB a spustím to, tak se nabídka nastavení velikosti video cache nezmění. A když zkusím pustit video, tak se vůbec nespustí. Takže to ten limit nijak nekontroluje a bude to opět na uživateli, aby si hodnotu vybral sám.

Ale tak je to pořád jen nightly, takže kdo ví, jak to nakonec bude.

Počkáme na finál. Ale kdyby to bylo nekontrolované, mohla by to být pro neznalé pěkná past. Např. u boxů 2/16 či TV.

Inovoval jsem instalaci LibreELEC Omega Beta2 verze z 18.1.2024 -na RPi4 2GB.
Položka v menu Služby/Caching mi posloužila na potvrzení vašich teorií @JiRo: @jkmh: - že Kodi neumí omezit nastavení nevhodné hodnoty. Omezení jsem se také pokusil v použitém HW a SW propočítat.
https://www.xbmc-kodi.cz/prispevek-libre...#pid127042

Tak jsem se samozřejmě také snažil na otázku @jkmh najít odpověď a doplnit tak zjištění @meda: a podařilo se. Nově jsem vytvořil na virtuálce další LibreELEC 11, aktualizoval ho na LibreELEC 12 Nightly (Kodi 21). A testoval přehrávání streamu pomocí SCC při kombinacích velikosti RAM a video cache:

1. RAM 4 GB, memorysize 1GB - přehrávání OK
   
2. RAM 2 GB, memorysize 1GB - přehrávání OK
   
3. RAM 1 GB, memorysize 20 MB - přehrávání OK
   
4. RAM 1 GB, memorysize 1 GB - stream se nespustí, chyba Kodi Přehrávání selhalo a v logu je vidět chyba týkající se cache...
   

Takže předběžný závěr je, že Kodi nijak při nastavení video cache nerespektuje skutečnou velikost volné paměti a nechá ji uživatele dokonce nastavit i v případě, když je hodnota volné paměti nižší, jak nastavená velikost video cache. Dobrá zpráva je, že Kodi při tom asi nespadne, ale streamy se prostě nespustí. Chová se to prakticky úplně stejně, jako když jsem u Kodi při podobných pokusem "přepískl" velikost video cachce v nastavení <memorysize> v advancedsettings.xml. 

Těch pokusů s různými kombinacemi RAM a video cache jsem ale udělal jen pár. Možná, že se to trochu jinak bude chovat pokud velikost nastavení video cache nebude tak zásadně větší než aktuálně volná paměť. Bude-li se hodnota video cache jen blížit k hranici volné paměti, může být chování Kodi méně jednoznačné. Například se stream jednou spustit může, ale Kodi začně protestovat až poté, co se video cache naplní nebo dokonce až při dalším pokusu o přehrání dalšího streamu. Tohle všechno zkoušet chce čas. Pokud se k tomu někdy dostanu, popíši to.

Každopádně tedy u Kodi 21 platí, že v možnosti nastavení video cache se nerespektuje aktuální volná paměť Kodi a klidně vás to nechá nastavit hodnotu, při které už Kodi při přehrávání správně fungovat nebude. Je tedy na vás, nastavit takovou velikost video cache, abyste měli jistotu, že to bude hodnota s rezervou bezpečně nižší, jak volná pamět v Kodi. O kolik, to se dá obecně těžko říci (viz mé předchozí příspěvky). Určitě neuděláte chybu, když to bude např. 85-90% volné paměti v Kodi.

Samozřejmě všechny zjištěné skutečnosti a závěry z nich odvozené je třeba brát s rezervou, protože u Kodi jde o beta2 verzi a u LibreELEC, na které jsme to testoval já, dokonce nightly Generic verzi. Takže u finálních verzí to nakonec může být i jinak. Ale na to si musíme počkat.

Víceméně jsem takovou odpověď tušil. O této funkci jsem zatím nenašel v Kodi wiki i fóru žádnou zmínku. Vyjma Kodi 21.0 "Omega" Beta 2 | News | Kodi, kapitola Video. Ještě prolezu git. Ale je to jen beta, uvidíme co final.

@jkmh Ani já jsem nikde nic nenašel. Ale na aktualizaci dokumentace je také asi ještě hodně brzo.

Mě osobně překvapilo, že se po změně nastavení video cache nevyžaduje restart. To znamená, že ta správa paměti alokované pro video cache je skutečně dynamická. To by samozřejmě nahrávalo možnosti dynamicky změnit hodnotu alokované paměti těsně před přehráváním videa podle okažitého obsazení paměti. Strategie toho nastavení by mohla být pak různá. Ale to je jen vize, ne praktické doporučení. Nic takového, v současné době v nastavení video cache, bohužel možné není.

Nicméně, stejně jako naše tady na našem fóru, tohle určitě bude předmětem úvah a návrhů uživatelů na kodi.tv, jak to nastavení vylepšit. Zvlášť, když je možné ho měnit dynamicky. Rozhodně by ale mezi těmi návrhy mělo jako první být omezení limitu nastavení podle aktuální hodnoty paměti nebo dokonce podle akuální hodnoty volné paměti. Jinak by to, v současné podobě nastavení, jak píše @jkmh: "...mohla by to být pro neznalé pěkná past."