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

Ja som na Androide 4 GB  skúsil 1 GB a z SCC to nespustilo film, nižšiu hodnotu 768 MB spustilo v pohode

pod androidom omega je problém z cache SCC i SC ide to úplne zle, forward sa snaží načítať do pamäte ale spustený stream mu to hneď zhltne a video sa sekne, pod windows i coreelec tam tam to ide ok i pod nexusom je to ok v androide

@JiRo: @jkmh: Mám tu takový ideový problém. Cache Forward a procenta. Červeně opravy podle Jiro.
LE/Kodi 20.2 Nexus na RPi4 2GB, SCC 2.3.5.
Cache neovlivněna přes advancedsettings.xml, tedy je defaultní velikost 20MB, Buffermode 0, Readfactor 4.

Najdu stream, kupříkladu Otec Brown, s9e2, H264, 3.16Mbitps. (Také to teď vysílala TV.)

Spustím, vyvolam informace Shift+Ctrl+O:
Forward se drží 14.88MB a údaj 100%.
Po minutě přehrávání zapauzuji na 1 minutu.
Po spuštění se za asi 5 sec dorovná Forward 14.88MB a údaj 15%.
Procenta Buffer se drží na 15 a hodně pomalu stoupají.

Po dlouhém čase se dorovnají na 100%.
Pokud ale ovládáním skočím vpřed, například o 2 minuty, údaj se z 15 hned změní na 100%. To znamená, že výpočet se restartuje.

Do očí bije rozpor mezi plnou pamětí Forward a stavem %.
Špatně chápu, o čem čísla vypovídají? Procenta tedy nemluví o naplnění Forward cache. Zde mne opravil JiRo, že jde o Buffer playeru.

Logická úvaha o výpočtu říká, že průměrný tok přehrávání se na počátku sníží o zapauzovaný čas vícenásobně, než když udělám pauzu ke konci videa.
Pak se i koeficient Readfactor projeví na počátku videa víc, ten přepočet omezuje přísun dat ze streamu.
(Ano, ke konci videa se opravdu procenta nesníží o tolik.)

Plnému Forward neodpovídá 100%.
Takže ta procenta neukazují naplnění paměti - ale přepočet v procentech, jakou Rychlost krát Readfactor je v této chvíli povolený maximální tok dat streamu.
Ale chyba v logice.

To by bylo i vysvětlení, proč si někteří stěžují na spadnutí videa po dlouhém (hodina?) zapauzování. Přepočet sníží tok dat na nepřijatelnou hodnotu.
Proto není vhodné při přepnutí TV na jiný vstup HDMI nebo tuner mít od CEC nastavenou Pause ale je vhodné Stop.

Samozřejmě, pokud Readfactor nastavíme na 40, bude přepočet příznivější. Pokud souvisí Forward a Buffer.
Popsal jsem fakt nebo jsem vytvořil další mýtus?

@meda Údaj za forward: v MB udává zaplnění dopředného bufferu video cache. Následující údaj v % pak udává zaplnění bufferu přehrávače. Takže to myslím odpovídá na Tvé otázky "Špatně chápu, o čem čísla vypovídají? Procenta tedy nemluví o naplnění Forward cache."

Hezky je to vidět v případě, kdy přehráváš stream, který video cache nepoužívá (např. adaptivní protokol HLS/MPEG-DASH nebo z PVR nebo když si cache úplně vypneš) tak se forward drží na 0.00 B a hodnota v % se mění hodně dynamicky a může klesat až hodně blízko k 0. U PVR streamů, a hodně to záleží na zdroji, se mi např. u TV Sledování běžně pohybuje někde kolem 70 %, u jiných zdrojů i méně (např. DVB-T kolem 30 %). A např. u 4K videí z Youtube (MPEG-DASH) klesá až téměř k 0 %, u některých pak až v 0 % skončí a pak samozřejmě přehrávač začne "bufferovat".

Musím ale připustit, že u posledních verzí Kodi se i mně zdá, že se ten údaj v %, tedy obsazení bufferu přehrávače, chová nějak divně. Ani jsem si nevšiml od kdy.

Dříve to bylo tak, že například při konci filmu běželo přehrávání už jen z video cache, tedy údaj v MB z maximálního naplnění klesal postupně na 0, a když tam dospěl, tak pak se pak začala snižovat i hodnota v%, tedy bufferu přehrávače, také až k 0, kdy přehrávání skončilo. Nyní platí jen to první, tedy ke konci filmu se snižuje jen údaj v MB a když tam dospěje, tak přehrávání skončí, i když je hodnota bufferu stále 100 %.

Jiného zvláštního chování jsme si všiml dnes, když jsem při přehrávání v Kodi 20.3 na Windows (video cache nastavená na default) dosáhl stavu, kdy video cache byla na maximu, přehrávání běželo plynule a buffer přehrávače se stále držel na 1 %. Pak jsem ale film pustil znova a už se mi to nepodařilo zopakovat, buffer byl stále na 100 %. Buď je to chování dáno nějakým novým algoritmem spolupráce mezi video cache a bufferem přehrávače nebo je to možná nějaký bug, možná jen při zobrazení Player Debug Info (ctrl+shift+o), protože přehrávání i při bufefru 1 % běželo bez problémů. Hodně se to podobá tomu, co jsi popisoval u přehrávání tohot Otce Browna. Stav, kdy je cache naplněná a buffer přehrávače nemá 100 % je docela zvláštní. Možná také, že to souvisí s hodnotou readfactor, o čemž ivažuješ i Ty. Většinou jsem já ty minulé pokusy dělal při nastavení hodně vysoké hodnoty (20 nebo dokonce 40), taže je možné, že při nízkých hodnotách, kdy je rychlost přednačítání dána součinem aktuální bitové rychlostí streamu a hodnoty readfactor, to zafunguje takto. Je totiž otázka, jaká je hodnota aktuální bitové rychlosti streamu. Pokud je hodně nízká (což při nějaké scéně může být), tak je nízká i její hodnota násobená nízkou hodnotou readfactor.

To padání přehrávání po dlouhé pauze s tím ale asi nesouvisí. Možná je to důsledek (tady alespoň u SCC/Webshare) už také kdysi diskutované událosi a to je to, že po dlouhé pauze proběhnou nějaké timeouty v jejímž důsledku se nepodaří znova načíst stream. Dělal jsem nějaké pokusy s odpojením ethernet konektoru na boxu při přehrávání z SCC/Webshare. Po odpojení přehrávání běželo dál z video cache, když se vyčerpala, tak se zastavilo. Pokud jsem síť připojil do nějaké doby, tak se přehrávání zase rozjelo, ale pokud to trvalo déle, tak to spadlo. Nijak dál jsem to ale nezkoumal. Možná tedy, že dlouhé pauzy mají stejný efekt.

@meda: Nemohu se vyjádřit k chování v Kodi 20, mám už jen K21. Tam jsem si všiml podobného chování, jak popisuje @JiRo: Někdy je buffer na 0% a nepřibývá. A přesto náročný stream z SCC jede plynule. Pokud stream tentýž stopnu a pak pustím pokračovat od, začne se buffer chovat podle známého vzorce chování. Pokujd dám jen pauzu, buffer se nenačítá. Vysvětlení nemám. Zatím jsem se po tom jevu blíže nepídil, protože a) K21 ještě není finál a b) požadované chování není zatím nikde popsáno a ani nějaké reakce na fóru Kodi.

@jkmh Mně se to ale takhle "pošahaně" chová i na Kodi 20.3, ale jen pod Windows. Bohužel to ale není 100% reprodukovatelné.

@JiRo: U K20 je to divné. A že to je selektované jen na jeden OS je ještě divnější. Tam není řízení cache integrováno do systému. Nebo do K20.3 už ano? U K20.2 (CE20.2) si na tento jev nevzpomínám.

@jkmh Možná, že je to dáno i tím, že na těch Windows mám videco cache v defautním nastaveí, a tedy i nízkou hodnotou readfactory i memorysize. Což člověk normálně nemívá. Navíc, jak jsem už psal, některé stavy se mi nepodaří vždy reprodukovat. Když se mi to naposledy stalo, buffer se stále držel na 1%, video cache byla na maximu a přehrávání běželo plynule bez porblémů, a stream jsem pak stopnul a znova spustil, už se mi toho stavu nepodařilo dosáhnout.

@JiRo: @jkmh: Ano, to je právě ten rozdíl v plnění bufferu přehrávače s defaulními hodnotami v Kodi (20MB, 0, 4x).
SCC
Po STOP a novém spuštění i od zapamatovaného času se vždy drží na 100%.
Po PAUSE (je to víc vidět po začátku videa, minuta Play, minuta či víc Pause, pak Play) se procenta začnou držet na nízké hodnotě.

---

EDIT: Ještě ke všemu je rozdíl mezi doplňky (při defaultním nastavení Cache, Kodi 20.2 na RPi4).

Pokud spustím doplněk YouTube, video (Kosmonautix) "Žive: Falcon 9 (Ax-3)(2024)" plní se Forward na 7.39MB.
(Naplní se na chvíli přes tuto mez ale pak se vrátí.)
Chování, jako kdyby Cache nebyla 20MB ale 10MB.
Vyzkoušel jsem po 1 minutě Play dát Pause 5 minut. Po stisku Play procenta naplnění Bufferu skočila ze 100% na 8%.

Doplněk Prima+ naproti předchozímu vůbec nevyužije Cache, Forward je stále 0.00MB, Buffer 99-100%.
Manipulace s Pause a Play vůbec naplnění Bufferu neovlivní, stále 99-100%.
Zkoušel jsem na jednom z dílů Autosalon.

Sosáč nevyzkouším - respektive jen první minutu, než spadne stream.
Ještě hledám, co je ve výpisu nad Buffer položka PC:
U Sosáče je tam "None", u ostatního naskočí "1" ... našel jsem: pc:1 - Pullup correction pattern length
Takže "délka vzorku korekce"? Přírůstku?

---

@JiRo: Pokud si čtu ve wiki a ve fóru, jsou tam tyto údaje, které nevysvětlují rozdíl mezi pojmy Cache a Buffer Playeru.
Ve wiki je napsáno: forward:0 B - Cache amount in MB; 100% - Percentage of cache in use. https://kodi.wiki/view/Player_process_in...Debug_Info
Ve fóru je napsáné "velikost mezipaměti v MB a % mezipaměti" https://forum.kodi.tv/showthread.php?tid...pid2563813

@meda V těch popisech to chápu jako možná rezidua minulých verzí Kodi a také to, že to v popise moc nerozlišují. Vždycky tomu říkají cache nebo buffer bez ohledu na to, o co se jedná. V minulosti byla cache organizována trochu jinak (viz jeden z mých předchzích postů a history buffer, current buffer a lookahead buffer). Každopádně, ať se tomu říká jakkoliv, tak fakticky je ten buffer svázán právě s přehrávačem. Proto asi vzniklo ono pojmenování buffer přehrávače, protože lépe vystihuje jeho podstatu a funkci na rozdíl od video cache. Důležité je, že buffer přehrávače je k dispozici vždy. A to i tehdy, když je vlastní cache úplně vypnutá nebo když je zdroj videa takový, že se pro něj Kodi cache nepoužívá (live stream, adaptivní protokol, zdroj typu PVR).

Mimochodem, doplněk si nerozhoduje o tom, jestli video cache použije nebo ne. To je dáno tím, jakého typu je zdroj, který právě přehrává (a také, jak je cache nastavená, viz. <buffremode>). V případě Primy jsou streamy (ať už live stream, VOD nebo archiv) přenášené protokolem HLS. Vidím v jejich zdrojových adresách zásadně jen adresy typu manifets HLS.
 
Tady je např. obsah jednoho z pořadů v archivu:
 
A při přehrávání takového streamu se samozřejmě video cache nepoužije, takže jediné místo, kde se něco ukládá je právě ten buffer přehrávače.

Jak už jsem dříve psal, to zobrazení obsazení bufferu přehrávače (jsem tak zvyklý mu říkat, budu to tedy používat dál) se mi taky u posledních verzí Kodi nějak nepozdává. Jak to 1% o které jsi psal, tak např. to, že když si pustím video z doplňku Prima+ např. video z archivu a vytáhnu ethernet konektor, tak se přehrává chvíli dál (než se vyčerpá buffer přehrávače), ale % zaplnění bufferu přehrávače neklesá a drží se stále na 100%. Když totéž udělám u PVR (Tvheadend) tak se to chová podobně, jen s tím rozdílem, že buffer klesá postupně až k 0%, kdy se přehrávání zastaví. Možná, že bude problém v případě adaptivních protokolů. Z Tvheadend to jde HTSP protokolem (i když původní video z OTT služby je také HLS, ale ffmpeg na vstupu TVheadend to přeskládá), zatímco z doplňku Primy to jde až na přehrávače jako HLS.

A pokud je ve fóru napsáno "velikost mezipaměti v MB a % mezipaměti", tak je celkem jednoduché si ověřit, že to v praxi tak není, že mezi těmito dvěma hodnotami většinou (při běžném přehrávání) žádná jasná relace není. Když si pustíš video, vidíš, že MB obsazení dopředné paměti narůstají, až nakonec dosáhnou 75 % hodnoty <memorysize>,  ale hodnota v % jsou většinou naplněná hned na 100 %. A naopak. Když si video cache úplně vypneš, hodnota dopředného bufferu v B je rovna 0.00, ale je vidět, jak ty % lítají mezi 100 % a nějakou hodně nízkou hodnotou, případně 0 %. To, že je něco s tím něcoo v nepořádku také vidíme v tom, jak málokdy dochází k tomu, že se na obrazovce objeví právě symbol načítání buferu přehrávače, případně hlášky o pomalém zdroji. Dříve se to chovalo celkem predikovatelně, teď to tak ale není.

---

Ještě jsme se zběžně podíval na Github xbmc a tam jsem definici cache a také jejího dopředného a zpětného bufferu , která přesně odpovídá získaným zkušenostem a tomu, jak jsme to tu popsal (strategie rozdělení a chování při jejm plnění). Ale nenašel jsem tam nic dalšího, co by odpovádali tomu, čemu já říkám buffer přehrávače. Naopak, v části core, kde je, kromě jiného i část týkající se videoplayer-u, obsahuje definice bufferu. Neříkám, že to něco dokazuje, ale poměrně přesně to odpovídá dosud zjištěným skutečnostem. Nechce se mi procházet celý kód, to je už na mne hodně náročné, ten způsob, jak je celé Kodi naprogramováno je bez diskuse nad mé praktické i teoretické schopnosti.

@JiRo: Díky za rozbor, tvé vysvětlení je logické a postačuje.

Rozlišení a snímková frekvence

V tomto příspěvku se budu věnovat citlivému tématu. Citlivému zejména proto, že se dotýká fenoménu, který dnes hýbe světem médií. Tedy tomu, přehrávat video v co nejlepším rozlišení a s co nejlepší snímkovou frekvencí a využít tak na 100 % (nebo i více ) investice vložené do nákupu TV, ke které je HW na kterém běží Kodi připojeno, případně na které Kodi běží (v případě Android nebo WebOS TV). Hned na začátku musím upozornit na to, že většina mých znalostí a prakticky ověřených zkušeností vychází z používání Kodi na CoreELEC verze 20.3. A je tedy třeba i říci, že v tomto tématu je systém, na kterém Kodi běží, hodně důležitý. V jiných systémech může být výsledný efekt, myšleno v posuzování celého řetězce při přehrávání videa, tzn. zdrojové video - Kodi - HW - operační systém - TV, trochu jiný, a tam mě musíte brát s rezervou. V jiných systémech a na jiných verzích se může chování více či méně lišit. Budu pak samozřejmě rád, pokud mé informace v takovém případě doplníte o vaše znalosti a zkušenosti.

Co je tedy mýtem v tomto případě?

Nic jiného než to, že parametr Rozlišení a Obnovovací frekvence v Nastavení > Systém určuje pouze rozlišení a obnovovací frekvenci GUI Kodi, ne rozlišení a obnovovací frekvenci při přehrávání videa. Tento mýtus vznikl na základě popisu popisu v Kodi Wiki. A jako celá řada dalších informací ve Wiki Kodi, ani tento není úplně přesný. Uvedeným nastavením se řídí zobrazení a obnovovací frekvcence jak při zobrazení GUI Kodi, tak při přehrávání videa.

Ve druhém případě však můžeme zobrazení a obnovovací frekvenci při přehrávání videa změnit, a to pomocí nastavení přehrávače Upravit obnovovací frekvenci obrazovky, v Nastavení > Přehrávač > Videa. V tomto případě volbou Při spuštění / Zastavení nebo Při spuštění dosáhneme toho, že se rozlišení a obnovovací frekvence připojené TV nebo monitoru upraví podle parametrů přehrávaného videa. Musí být při tom ale splněna podmínka, a to, že se rozlišení i obnovovací frekvence přehrávaného videa shodují s jedním z kombinace parametrů, které jsou v Nastavení > Systém uvedeny v nabídkách položek Rozlišení a Obnovovací frekvence.

Uživatel si navíc může z nabídky možných kombinací rozlišení a obnovovací frekvence vybrat ty kombinanece, které chce používat a vytořit si tzv. whitelist. Jeho vytvoření provede také v Nastavení > Systém, výběrem z možných kombinací v položce Seznam povolených. Pokud tento seznam není prázdný, upravuje se při přehrávání videa rozlišení a obnovovací frekvence jen pro ty kombinace, které jsou jeho obsahem. Navíc si k tomu ještě může přidat ty obnovovací frekvence zobrazení, jejichž hodnota odpovídá podílu 3:2 nebo násobku 2 obnovovací frekvence přehrávaného videa. Tuto možnost si volí ve dvou položkách, Povolit 3:2 snížení obnovovacích frekvencí a Povolit dvojnásobné obnovovací frekvence.

Nabízí se tedy některé hypotetické otázky:

1. Co se stane, když si při přehrávání videa, u kterého došlo k přepnutí rozlišení a obnovovací frekvence (a jsou tedy jiné, než platí pro GUI) a GUI zobrazím současně (přehrávání běží v okně nebo na pozadí)? V takovém případě zůstává v platnoti přepnutí na hodnoty rozlišení a obnovovací frekvence videa a zobrazený skin se "rescaluje" na tyto hodnoty.
   
2. Co když v nabídce rozlišení a obnovovací frekvence nebo ve whitelist-u kombinace rozlišení a obnovovací frekvence přehrávaného videa není? Pak se výstup přehrávače a celého Kodi nastaví právě na rozlišení GUI.
   
3. Jak to tedy, že u Kodi v Android box-u, když v Rozlišení mám uvedeno pouze 1920x1080, současně mám v nastavení přehrávače parametr Upravit obnovovací frekvenci obrazovky nastaven Při spuštění / Zastavení, a přehrávám video ve 4K, vidím že i připojená TV dostává z boxu 4K video? Podle toho, co je uvedeno v tomto příspěvku výše by do TV mělo přeci jít video pouze v rozlišení 192x1080? Tady bychom neměli zapomínat na to, že video z Kodi zpracovává Android a ten ho, pokud je v něm nastaven výstup na 4K, může upscalovat video 1980x1080 přicházející z Kodi na toto rozlišení. V tomto případě tedy probíhá celý proces možná následovně (viz Poznámka pod čarou): zdrojové video 4K -> Kodi přehrávač ho downscale-uje na 1920x1080 -> Android ho upscale-uje na 4K -> TV.
   

---

Poznámka: S problematikou v Android nemám větší zkušenosti. Takhle jsem si chování Kodi v Android na několika boxech ověřil. Všechny měli v nabídce Rozlišení uvedeno pouze 1920x1080 a všechny se chovaly stejně. Budu tedy rád, když mi někdo s většími zkušenostmi s Kodi v Android systému s nabídkou rozlišení pouze 1920x1080 tuto zkušenost potvrdí nebo vyloučí. Pokud se ve svých závěrech mýlím, rád to uvedu na pravou míru.

Pochybnosti o 4K na Androidtv, kde v KODI nelze nastavit jiné rozlišení než 1920x1080/60, trvají roky. A vždycky byla odpověď, že je to jen rozlišení uživatelského rozhraní (jak je psáno přímo v KODI i na wiki) a vrstva 4K videa je samozřejmě ve 4K.
I když v CoreELEC jde nastavit i vyšší rozlišení, stejně mám nastaveno jen 1920x1080, videa jsou dle PlayerProcessInfo 4K. Může to být v Androidu jinak?
Tak jsem po 4 letech na CoreELECu přepnul box na Androidtv (Mecool KM3, atv 9) a PlayerProcessInfo ukazuje 1920x1080! Přišlo mi absurdní, že by KODI snižovalo 4K rozlišení na FHD, vyrobil jsem si tedy 4K video s 1 pixelovými čarami a otestoval. A je to OK, video zůstalo ve 4K!
Vlastně se mi nepovedlo nastavit KODI v atv tak, aby bylo video degradováno - rozlišení GUI měnit nejde, v seznamu povolených je jen FHD, nastavení úpravy frekvence obrazovky nemá vliv...
Můžete otestovat na jiných boxech, systémech i v TV s androidtv a konečně mýtus potvrdit či vyvrátit? TestVideo:
https://webshare.cz/#/file/ns19ebV1L4/4k-test-cz-mp4

@LadMc Po dalších diskusích i mimo toto fórum je jisté, že se Android i Android Tv (ATV) můžou chovat různě a je třeba mezi nimi rozlišovat. Já Android TV nemám a mé závěry v bodě č. 3 příspěvku se týkají pouze Android, které mám k dispozici (hodně stará verze). Je jasné, že teprve použití testovacích 4K obrazců může dát absolutní jistotu, protože systémy Android a Android TV týkající se všech variant parametrů rozlišení a obnovovací frekvence nejsou schopny předávat do Kodi tak, jako to dokáží ostatní systémy (Linux, Windows) a jak to Kodi předpokládá. Jiné je to až u posledních verzí, případně u speciálních Android verzí (např. Shield) verzí.

@JiRo: Mám na tebe prosbu týkající se zobrazení Player Debug Info.
Zobrazení po Ctrl+ Shift+ O.
Mám zařízení ovládané D.O, ke kterému klávesnici nepřipojím. Poznámka ve Wiki o použití D.O. přes CEC nevede na řešení, nebo jsem se špatně zacyklil.

Poradil bys mi, jak tuto volbu (název položky?) získat přes Keymap Editor,
nebo jaké instrukce vepsat přímo do souboru /keymaps/gen.xml ?
Děkuji

@meda: Nejsem sice JiRo , ale v souboru gen.xml mám tyto řádky:
 
Key id musíš, pochopitelně nahradit tebou požadovanými tlačítky . V aktuálním vzorku u TV Samsung se SmartDO to jsou Šipka vpravo a vlevo po stisku Pause/Play.

V řeči appky je to u mě:
Keyboard Editor -> Fullscreen Video/Other -> Player Process Info a Player debug.
Ale můžeš asi použít i
Keyboard Editor -> Global/Other -> Player Process Info a Player debug
Keyboard Editor -> Videos/Other -> Player Process Info a Player debug
Keyboard Editor -> Virtual Keyboard/Other -> Player Process Info a Player debug

@jkmh: Díky To tak někdy přijde, že jsem raněn slepotou. Pro fullscreen ideální.

Jak nejlépe nastavit video cache - <readfactor> v Kodi 21

Navazuji na téma <readfactor> uvedené v tomto příspěvku s aktualizací, která se týká pouze Kodi 21 Omega. V této verzi kodi se možnost změnit defaultní nastavení video cachce přestěhovalo ze souboru advancedsettings.xml přímo do nastavení Kodi. Najdete ho v Nastavení > Služby > Caching. Pozitivem této změny je to, že již není třeba editovat soubor advancedsettings.xml, případně používat dopňky, které to provádí, ale je to možné provést pohodlně z prostředí Kodi a navíc, po změně nastavení není třeba Kodi restartovat. Negatovem pak to, že parametry nastavení už Kodi nijak nekontroluje a pokud např. překročíte (s ohledem na veliikost vaší volné paměti) velikost nastavené <memorysize>, nebude v Kodi správně fungovat přehrávání video obsahu, při kterém se video cache využivá.

Zajímavou změnou v nastavení hodnoty <readfactor> je to, že je možné, kromě nastavení konkrétního hodnoty tohoto parametru, zvolit režim Adaptive. Jak tento režim funguje?

Při spuštění přehrávání začne Kodi načítat data maximální možnou rychlostí. To ale trvá jen krátce, a jen do doby, než získá první infomaci o tom, jaký bitrate má přehrávané video. V tom okamžiku začně rychlost načítání přizpůsobovat tomuto bitrate tak, aby na jedné straně měl vždy dostatek přednačetných dat a aby se míra zaplnění cache postupně zvyšovala, zároveň ale, aby načítání dat nezatěžovalo komunikaci nad nezbytně nutnou míru. Algoritmus přitom porovnává bitrate videa a zaplnění video cache. V případě, když (po zaplnění video cache na 100 %) začne její zaplnění klesat, zvýší rychlost načítání, aby se ten pokles vyrovnal.

Algoritmus tedy funguje tedy tak, aby optimalizoval využití komuniiace a zátěž zdrojových serverů. V okamžiku, když přenosová schopnost nebo schopnost serverů dočasně klesne pod aktuální bitrate přehrávaného videa (tzn. že se začnou čerpat přednačtená data z cache), zvýší hodnotu <readfactor> a když zaplnění cache začne zase růst, hodnotu <readfactor> zase sníží.

Podle mne tento adaptivní algoritmus může přispět ke snížení nárazů zatížení komunikace a serverů v prime time, kdy si statisticky významné množství uživatelů spouští přehrávání videa v podobný čas a kdy je (díky načítání cache s vysokou hodnotou <readfactor>) požadavek na dodávku a přenos dat krátkodobě enormní. Může to být až několikanásobně větší hodnota toku dat, než je suma bitrate přehráváných videí. Aby to ale tak bylo, je potřeba, aby si adaptivní režim nastavení <readfactor> zapnulo co možná nejvíce uživatelů. Přemýšlejte o tom.

Jak nejlépe nastavit video cache - <readfactor> v Kodi 21 - porovnání průběhu

Abych úvahu uvedenou v předchozím příspěvku ještě doplnil, uvádím pro porovnání průběh rychlosti komunikace mezi Kodi a serverem Webshare pro dva případy. První je při nastavení <readfactor> na hodnotu 50x a druhý, při nastavení Adaptive. Myslím, že to popisovanou problematiku hezky dokresluje.
   
Je vidět počátečný "náraz" (rychlost odpvovídá maximu tarifu, tj. 150 Mbps) komunikace, který trvá tak dlouho, dokud se nenačte celá video cache (575,9 MB). K tomu v tomto případě dojde dojde zhruba po 34 vteřinách.
   
I tady na začátku přijde náraz, ale je krátký, kdy je potřeba, aby si algoritmu nastavil "výchozí parametry" svého chování, hned na to ale začně fungovat optimalizace, která sníží rychlost na "nezbytně nutnou" k tomu, aby se ještě přednačítala data do video cache. Z porovnání bitrate videa a rychlosti komunikace je vidět, že se <readfactor> ustálí přibližně na hodnotě dvojnásobku. Přednačítání tím pádem trvá déle než v prvním případě, je dobře vidět, že ani po třech minutách záznamu průběhu rychlosti není video cache načtená celá (348,2 MB).
Nabízí se otázka k diskuzi, který případ je vlastně pro zátěž komunikace a serverů optimálnější. Zkuste mi k tomu něco napsat...

Jak nejlépe nastavit video cache - <readfactor> v Kodi 21 - nastavení Adaptive a přerušení komunikace

Ještě jedna věc mě zajímala, a to, jak se algoritmus při nastaveném <readfactor> na Adaptive zachová při přerušení komunikace. To jsem nasimuloval prostým vytažením ethernet konektoru z boxu. Výsledek je vidět na následujícím obrázku.
   
Je vidět, jak se komunikace přerušila i to, jak se okamžité po jejím obnovení krátkodobě navýšil <readfactor> a rychlost komunikace se navýšila. Ale jen do té doby, než se hodnota zaplnění videocache vrátila na očekávanou úroveň. Na průběhu rychlosti je pak vidět, jak se srovnala do trendu před simulovaným výpadkem komunikace.