• Vítejte na XBMC-Kodi.cz
  • Česko-slovenská komunita fanoušků XBMC/Kodi
Vítejte návštevníku! Přihlášení Registrace


Hodnocení tématu:
  • 0 Hlas(ů) - 0 Průměr
  • 1
  • 2
  • 3
  • 4
  • 5
Strategie využívání video cache
#1
V poslední době jsme si všiml některých zvláštností při přehávání videí a toho, jak Kodi využívá video cache oproti tomu, jak mám strategii chování Kodi zafixovanou z dřívějška. Konkrétně mi jde o přehrávání obsahu z WS pomocí addon SCC.

Dříve, a to bezezbytku, se Kodi chovalo tak, že při zahájení přehrávání začalo obsah videa načítat maximální možnou rychlostí, což v mém případě bylo cca 140 -150 Mbps (mám připojení 150/10 od UPC/VF). Tak to probíhalo až do chvíle, kdy se načetl celý maximální obsah cache a pak se rychlost stahování snížila a měnila se podle aktuálního datového toku přehrávaného videa a to tak, že se obsazení cache udržovalo na tomto maximálním obsahu.

V poslední době jsme si všiml, že se tato strategie, a to u jen některých videí, změnila. Začátek probíhal stejně jako v předchozím případě, v okamžiku, kdy se cachce zaplnila, stahování na nějakou dobu ustalo úplně, po tuto dobu zaplnění cache postupně klesalo a když dosáhlo jisté hodnoty (cca kolem 80 % půvoodního maxima) pokles se zastavil, video se začalo opět načítat, rychlost stahování se snížila a opět se měnila podle aktuálního datového toku přehrávaného videa a to tak, že se obsazení cache udržovalo na naposledy dosažené hodnotě.

No, a nyní jsme odhalil další modus chování. Video se okamžitě po spuštění začne stahovat rychlostí, která je o něco vyšší než rychlost aktuáně přehrávanému obahu. Cache se tak plní pomaleji, ale opět až do maximální velikosti. Pak vše pokračuje jako v předchozích případech.

Zatím jsem po tom nijak detailně nepátral, nezkoušel měnit nastavení cache ani nesledoval, zda a jak to závisí na typech streamů nebo některých dalších atributech. Vlastně k tomu nemám důvod., protože všechna videa (i ta nejobjemnější, resp. ta s největším datovým tokem) se mi přehrávají vždy bez problémů. Takže to možná nechám plavat, nicméně by mě přesto zajímalo, zda s tím má někdo ze zdejších znalců podobné zkušenosti, případně zda dokáže popsané rozdíly v chování Kodi vysvětlit. Bohužel to zpětně nedokáži přiřadit verzím Kodi a ani jsem nezkoušel to ověřit u jiných typů instalací. To co popisuji se vesměs týká CoreELEC. Jak píši, není to pro mne, z hlediska funkce Kodi, nijak kritické, takže se mi s tím nechce ztrácet čas. Na druhou stranu mě to samozřejmě zajímá, takže přivítám nějaké názory nebo zkušenosti.

Situaci popisovanou ve třetím odstavci jsem před časem zveřejnil i na kodi.tv, žádné odpovědi ani vysvětlení se mi tam zatím nedostalo.
 
Citovat
#2
Cache mi nedává spát. Tedy není to nic tak vážného, ale občas mě chování Kodi překvapí. Od samotného počátku Kodi, což už pomalu bude více než 13 roků, respektuji doporučení na to, jak cache dimenzovat. Nyní jsem si řekl, poté, co jsme zjistl, že se cache nechová tak, jak jsem i vždycky myslel (viz můj předchozí příspěvek), že to podrobím dalšímu zkoumání. Začal jsem tím, že jsem nastavil hodnotu cache nad obvyklé meze, tedy takto (volnou paměť Kodi mám po jeho startu cca 3 GB):
 
Kód:
    <cache>
        <buffermode>2</buffermode>
        <memorysize>2000000000</memorysize>
        <readfactor>40</readfactor>
    </cache>
Za normálních okolností by tohle Kodi při přehrávání videa velmi brzy položilo. V mém případě ne. Přehrávání titulu z SCC běží, cache se začala plnit a plnění se zastavilo na hodnotě 1,73 GB. Viz screenshot:
   
Pravda, v logu se objevila zajímavá hláška, ale vše jinak běží dál:
 
Kód:
2022-07-03 08:59:17.597 T:4339  WARNING <general>: CFileCache::Process - <http://11.dl.wsfiles.cz/7011/X8qGZL89Op/524288000/eJw1jktrwzAQhP_LHnIStqyXJUHoMYcG+1QaiqHI1poaktiVHwWX_vduCr3NDDs73zcE8GBEJpTOnMqEBAYDeM5gAV8YXXIurXMMNrIMVvC60AzmPzeBX9KKDO70JPCCupEUD85EzqOyhTLCKIvG8RaFsDKaUqLWfWf6tnuc0wpsQ8TxfV4ShhtliaIvbOePkDDr9ibvhys2+cV+nt7O1tVTkz9hSmM6vlTPVf1aHcYj1Zb0TzPv4CVhCsJX6ucXgOk9pQ/548eecc175b612a28501cd5c3ad574e139ae7977/a01> source read returned 0! Will retry
2022-07-03 08:59:19.597 T:4339  WARNING <general>: CCurlFile::FillBuffer - Reconnect, (re)try 1
Zkouším v přehrávaném videu skákat sem a tam, cache se vždy vyprázdní a pak se začně znova plnit. A vše zdá se funguje tak jak má.

Pak se ale jeden problém přeci jen objevil. Jeden z mých service addon (který volá systémové aplikace) skončil s chybou alokace paměti:
 
Kód:
2022-07-03 08:52:45.344 T:4051    ERROR <general>: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--
                                                    - NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!
                                                   Error Type: <class 'OSError'>
                                                   Error Contents: [Errno 12] Cannot allocate memory
                                                   Traceback (most recent call last):
                                                     File "/storage/.kodi/addons/script.speedmeter/service.py", line 9, in <module>
                                                       addon.start()
                                                     File "/storage/.kodi/addons/script.speedmeter/resources/lib/service.py", line 177, in start
                                                       rx_bytes = int(subprocess.Popen(RX_BYTES, stdout=subprocess.PIPE, shell=True).stdout.read().rstrip())
                                                     File "/usr/lib/python3.8/subprocess.py", line 858, in __init__
                                                     File "/usr/lib/python3.8/subprocess.py", line 1639, in _execute_child
                                                   OSError: [Errno 12] Cannot allocate memory
                                                   -->End of Python script error report<--
K pádu addon došlo poté, co se cache naplnilo na cca 1/3 velikosti volné paměti? To asi náhoda není...

A problémům není konec. Po úplném zastavení přehrávání a pokusu o nové spuštění stejného titulu mi SCC hlásí, že soubor, ze kterého jsem titul naposledy přehrával, teď na serveru WS nemůže najít. Pomůže až restart, po kterém se to vše vrátí do normálu.

Napsal jsem toto delší sdělení proto, aby snad někdo, kdo ať už omylem nebo cíleně vyzkouší to, co já, tedy zvětšit cache nad doporučovaný limit, nepředpokládal, že to Kodi neublíží. Sice se na první pohled může zdát, že ne, ale opak je pravdou. Takže s cache opatrně, nenechte se unést! A já se pokorně vracím k doporučenému limitu, či spíše hluboko pod něj. Kvalita mého připojení, která ostatně dokáže většinu titulů z většiny zdrojů přehrát i s vypnutou  cache, mi to umožňuje.
 
Citovat
#3
Napadá mě, že k "regulaci" toku dat může docházet ze strany poskytovatele obsahu (WS). Vzhledem k tomu, že se zvyšuje počet lidí s velmi vysokým downloadem tak se toto musí negativně projevovat na zátěži jejich linek. Je to jen má teorie, ale když si představím jaké datové špičky vznikají při zaplňování cache, tak bych s tomu vůbec nedivil.
T95X/S905X, Tanix TX9s/S912, HK1/S905X3, CoreElec 19.5
 
Citovat
#4
@delfin-chikago Ano, to mě napadlo také a je dost pravděpodobné, že to tak je. A bylo by to ze strany WS celkem pochopitelné. Tedy to, že ten tok omezí na hodnotu, která je jen o něco vyšší, než průměrný bitrate titulu. Aby to ale fungovalo, měli by mít nějaké info o tom, jaký ten bitrate je. Možná by k tomuhle mohli něco říci pánové z SCC teamu. Ale nebudu do toho šťourat. Pokud to omezování postačí k přehrávání, tak proč ne.

Trochu jiná věc je ale to, co ve svém prvním příspěvku popisuji jako první. Tedy ten případ, kdy se po jistém čase ten datový tok úplně zastaví. Jak jsem dnes dodatečně zjistil, je to na straně Kodi spojené s hláškami, které jsme uvedl v už předchozím příspěvku:
 
Kód:
2022-07-03 08:59:17.597 T:4339  WARNING <general>: CFileCache::Process - <http://11.dl.wsfiles.cz/7011/X8qGZL89Op/524288000/eJw1jktrwzAQhP_LHnIStqyXJUHoMYcG+1QaiqHI1poaktiVHwWX_vduCr3NDDs73zcE8GBEJpTOnMqEBAYDeM5gAV8YXXIurXMMNrIMVvC60AzmPzeBX9KKDO70JPCCupEUD85EzqOyhTLCKIvG8RaFsDKaUqLWfWf6tnuc0wpsQ8TxfV4ShhtliaIvbOePkDDr9ibvhys2+cV+nt7O1tVTkz9hSmM6vlTPVf1aHcYj1Zb0TzPv4CVhCsJX6ucXgOk9pQ/548eecc175b612a28501cd5c3ad574e139ae7977/a01> source read returned 0! Will retry
2022-07-03 08:59:19.597 T:4339  WARNING <general>: CCurlFile::FillBuffer - Reconnect, (re)try 1
Otázkou je, jestli je to způsobeno tím, že WS přestane na nějakou dobu dodávat data. Ty hlášky tomu nasvědčují. Takže i když jsem si původně myslel, že za to může Kodi, možná to tak není ani v tomto případě, a ten prvotní impuls k tomu, že se se cache přestane plnit úplně, jde také od WS. Kodi v tomto případě pak čeká, až proběhne nějaký timeout, kdy nedostává  data (přehrávání to nevadí, protože v cache je dat stále dost) a pak se pokusí o reconnect (CCurlFile::FillBuffer - Reconnect, (re)try 1). Trochu záhadou je, proč se od této chvíle plní cache na nižší hodnotu, než před tím. Za tohle WS určitě nemůže, to je už záležitost čistě Kodi.

1 No, zatím si tedy, i s přispěním názoru od @delfin-chikago, vytvářím konspirační terorii, že na straně WS běží algoritmus který, pokud zjistí velký datový tok u souboru, který je videem (to asi problém není, WS moc dobře ví, kdo ty request-y zprostředkoval) a buď zná nebo si dokáže zjistit jeho průměrný bitrate, tak ten tok prostě omezí na nějakou mírně vyšší hodnotu. V případě, že tohle nedokáže/nezjistí, tak ten tok, při nějaké vyšší než limitní hodnotě, po nějakou nastavenou dobu na chvíli zařízne... No, berte mě z rezervou. Jak funguje taková služba jakou je WS netuším. A jak píši, je to jen teorie. Konspirační!
 
Citovat
#5
@Nemyslím si, že to WS omezuje na mírně vyšší hodnotu než je průměrný tok. Tím netvrdím, že to WS nějak neomezuje. Mám zjištěno, že než se naplní videocache, měl jsem datový tok na tom "tvém" streamu kolem 55 Mb/s. To už je asi hraniční možnost mého připojení. Čili 5x vyšší než je průměr a to po každém skoku, je jedno jestli vpřed nebo vzad. A stalo se mi v pátek vizuelně něco podobného, když jsem se potřeboval strefit do určitého místa a to mám cache v povolených mezích. Bohužel nepodíval jsem se do logu.
Těch 55Mb/s mi ukazuje shodně (s ohledem na rychlost vzorkování) můj addon i router, který funkci měření rychlosti má vestavěnou "z výroby". Takže tomu věřím.
Takže přidávám další konspirační teorii. Nemůže to spíš dělat nekorektní četnost requestů?
X96max plus 4/32 + CE 21 RC2 + skin Confluence SCC / TV Samsung QE55Q6FNA
X96max plus 4/32 + CE 20.5 + skin Confluence SCC

AVR Denon 1600H / Dali Spektor 5.1
Win10pro + Kodi19.5
NAS Synology 215j 3TB Raid1
Router Turris 1.1
 
Citovat
#6
@jkmh Jak jsem napsal v 1. příspěvku tématu, kromě obvylého a očekávaného chování odpovídajícího tomu, jak cache v Kodi znám, jsem (a to opakovaně) zjistil dva další mody chování. Pro jistotu to tedy zopakuji všechno:
  • normální, obvyklý a očekávaný - po startu jede načítání max. rychlostí připojení až do zaplnění cache, pak zpomalí na rychlost odpovídající aktuálně přehrávanému streamu (do cache se dočítají další data rychlostí odpovídající tomu, co se z něj aktuálně přehrává - Kodi drží její obsazení na 100 % nastavené velikosti), takhle to funguje i při skocích (vpřed i vzad), kdy se cache vždy vyprázdní a začne načítání nanovo,
  • prodleva po prvním zaplnění cache - začátek je stejný jako v předchozím případě, po zaplnění cache se ale načítání na nějakou dobu úplně zastaví (zpravidla kolem 2 min), zatímco přehrávání běží dál a data streamu se čerpají z cache, její obsazení klesne na nižší hodnotu (odhadem cca kolem 80-90 % původní velikosti, přesně jsem to ale nezjišťoval) a poté se načítání zase rozjede a běží, stejně jako v předchozím případě, rychlostí odpovídající aktuálně přehrávanému streamu. Jak se to pak chová při skocích jsem v tomto případě zatím nezkoušel (ale udělám to),
  • s limitem mírně převyšující bitrate streamu - okamžitě po startu se data načítají rychlostí, která jen mírně převyšuje aktuální bitrate. Rychlost načítání je v relaci k aktuálně přehrávanému streamu, ale je vždy o něco vyšší, protože cache se plní, ale s daleko menší rychlostí jak v předchozích případech. K zaplnění cache do maximální hodnoty dojde po velmi dlouhém čase.
V současné době se setkávám se všemi třemi mody chování. Zatím jsme nezjistil nějaké silné zákonitosti, kdy (tedy u jakého streamu) je ten který  "mod" použit, takže na závěry se ještě necítím. Zkusím zpětně dohledat a ověřit, u kterých streamů a za jakých podmínek se tak děje a zda je to reprodukovatelné. Bohužel jsem tomu zpočátku nepřikládal nějakou váhu, takže jsme si to nezdokumentoval. Pokusím se to tedy napravit. Dalším důvodem, proč jsem tomu nevěnoval nějakou zásadní pozornost je i to, že mě to vlastně, z uživatelského hlediska, zas tolik netrápí. Ve všech třech mod-ech běží přehrávání plynule a nenapsat si addon Speedmeter, který mi v Kodi on-line zobrazuje záznam průběhu rychlosti na eth rozhraní za poslední 3 minuty, tak jsem na to pravděpodobně ani nepřišel. 11

Úplně jsme nepochopil co znamená to "nekorektní četnost requestů". Myslíš překročení limitu počtu requestů v daném čase? Tady se přiznám, že vlastně ani nevím, jak na této úrovni ta komunikace probíhá. Faktem je, že jak jsem uvedl výše, v jistých chvílích tam k jakémusi obnovení spojení dochází, což signalizuje, že tam k nějakému problému došlo. V log-u KODI je to hláška uvedena s atributem WARNING, takže normální chování to není, ale zase to není nic tragického. 1
 
Citovat
#7
@JiRo: Jo přesně to jsem měl s těmi requesty na mysli. 6
X96max plus 4/32 + CE 21 RC2 + skin Confluence SCC / TV Samsung QE55Q6FNA
X96max plus 4/32 + CE 20.5 + skin Confluence SCC

AVR Denon 1600H / Dali Spektor 5.1
Win10pro + Kodi19.5
NAS Synology 215j 3TB Raid1
Router Turris 1.1
 
Citovat
#8
Opakovaně jsme testoval chování cache s důrazem na výše uvedené varianty. Ve většině případů chování odpovídá popsanému stavu, tedy je ve výše uvedeném seznamu modu chování označen jako normální, obvyklý a očekávaný. Čas sod času (ale spíše výjimečně) se objeví i mod prodleva po prvním zaplnění cache, na poslední nich, s limitem mírně převyšující bitrate streamu se mi nepodařilo za měsíc sledování narazit ani jednou. Přikláním se tedy k názoru, že změny v chování jsou způsobeny nějakým nespojitostmi buď v chování Kodi, nebo chybou z kategorie, o které tu psal @jkmh.​​

​​​​​Najít chybu a identifikovat ji pro případ, že by problém byl někde v Kodi se mi moc nechce. Jednak pro to nemám dost podkladů a získat je, by znamenalo další zkoumání, jednak by to stejně bylo nepoužitelné, protože bych pro to musel použít Kodi s instalovaným SCC a to při hlášení bug-u na kodi.tv ze známých důvodů nemohu. Navíc, funkci Kodi ani přehrávání to nijak neomezuje, takže k tomu to řešit vlastně není žádný důvod. Krom toho, přijít tomu na kloub, čehož se ale klidně vzdám. 1

Tak nakonec jen zajímavá infomace. Ze studijních důvodů provozuji nyní hlavní obývákové Kodi s video cache nastavenou na 0B. Už mi to tak běží více než měsíc a ani jednou jsem nenarazil na to, že by mi přerávač "zabufferoval". Buffer přehrávače se pohybuje mezi 75 a 100 % a to i v "prime time" a i pro "fláky" s průměrným datovým tokem kolem 80 Mbps. Připojení - UPC/Vodafone 150/10 Mbps v Praze na Barrandově. "Zřejmě slušnej oddíl."

Za sebe tedy pokládám toto téma, alespoň pro tuto chvíli, za uzavřené.
 
Citovat
#9
Příležitostně jsem se opět setkal s uvedeným "divným" chování cache. Myslím tím stav, kdy se po spuštění videa načte určitý objem dat (je vidět při zobrazení Player Deboug Info v položce forward).

Po krátém zkoumání kódu (resp. komentářů v něm) jsem si vylepšill znalosti, jak vlastně cache funguje. Jednak je zřejmé, že způsob využití cache záleží na typu kontejneru a jednak jsem si opravil názor na to, jak se s celým objemem paměti určené pro cache pracuje. Většinou se totiž předpokládá, že celá alokovaná paměť je věnována dopřednému bufferu, do které se přednačítá přehrávaný obsah, ale podle všeho je pro dopředný (forward) buffer věnována pouze část paměti (75 %), zbytek pak je určen pro zpětný (back) buffer. Logika rozdělení mezi back a forward je taková, že po spuštění přehrávání, kdy back buffer není třeba, se pro forward využije celých 100 % a jak se postupně přehrává video, tak se back buffer začně plnit na úkor forward bufferu.

To by tedy patrně vysvětlovalo chování, které jsme v předchozím postu označil jako prodleva po prvním zaplnění cache, při které se zároveň postupně sníží hodnota v položce forward. Není to sice na 25 %, ale je otázka, jak ve skutečnosti a v detailech ta funce řízení video cachce funguje. Na to mi totiž nikdo nebyl schopný dát jednoznačnou odpověď.

Co se týče stavu, kdy maximální rychlost klesne na výrazně nižší hodnotu a drží se na ní, tak to přičítám pravděpodobně snižení průchodnosti profilu od Webshare ke mně. Dlouhodobě jsme to sledoval a od jisté chvíle už se to nestává. Je pravda, že u mne se obecně zvýšila maximální rychlost komunikace, které je téměř trvale na 98 % maxima tarifu (UPC/Vodafone, 150/10). Stabilita rychlosti je taková, že si dokonce mohu dovolit přehrávat i poměrně velká videa (prům. dat tok kolem 50 Mbps) s video cache nastavenou na hodnotu 0.
 
Citovat
#10
Uvedená zjištění v předchozím postu také umožní lépe pochopit číslo obsazení paměti v položce forward v zobrazení Player Debug Info.

Uvedu příklad:

Zadaná hodnota v položce <memorysize> nastavení <cache> v advancedsettings.xml: 700000000 byte, tedy 667,6 MB
Nejnižší hodnota vyhrazená pro dopředný (forward) buffer (75 % z maximální hodnoty - viz. Pozn.) by tedy měla být 500,7 MB
Při přehrávání videa se hodnota forward v zobrazení Player Debug Info ustálí na konečné hodnotě 500,6 MB, což je v daném kontextu dokonalá shoda.
   
Pozn.
Maximální hodnota, kterou Kodi skutečně vyhradí pro buffer video cache závisí jednak na typu instalace, ale hlavně na zadané hodnotě <memorysize> v advancedsettings.xml. Pokud příliš nepřekročí doporučenou hodnotu (1/3 volné paměti), tak je maximální hodnota rovna zadané. V současné chvíli (empiricky ověřeno na CoreELEC) je možné nastavit hodnotu cache na nezvykle vysokou hodnotu a Kodi se normálně spustí. Maximální hodnota je ale v takovém případě limitována podle vnitřního nastavení. U HW s 4 MB RAM a CoreELEC 20.2, zadám-li například 4500000000, tak maximální hodnota forward bufferu nepřekročí 1,5 GB, což je ale už nad doporučenou hudnotou. Kodi se pak při přehrávání chová prapodivně a podle typu přehrávaného kontejneru to buď vede k tomu, že se video vůbec nespustí, začnou se prapodivně chovat na pozadí běžící doplňky nebo i jiné aplikace v operačním systému (např. Tvheadend) alokující si dynamicky větší objemy paměti nebo využívající socket komunikaci nebo to může vést až k havárii aplikace, která je někdy i doprovázena přepnutím do safe mode. Takže doporučení pro výpočet nastavení, které tu už existuje nějakou dobu, tedy 1/3 volné paměti * (0,8 až 0,9) se vyplatí dodržovat!
 
Citovat
#11
(13.8.2023, 21:58)JiRo Napsal(a): Co se týče stavu, kdy maximální rychlost klesne na výrazně nižší hodnotu a drží se na ní, tak to přičítám pravděpodobně snižení průchodnosti profilu od Webshare ke mně. Dlouhodobě jsme to sledoval a od jisté chvíle už se to nestává. Je pravda, že u mne se obecně zvýšila maximální rychlost komunikace, které je téměř trvale na 98 % maxima tarifu (UPC/Vodafone, 150/10). Stabilita rychlosti je taková, že si dokonce mohu dovolit přehrávat i poměrně velká videa (prům. dat tok kolem 50 Mbps) s video cache nastavenou na hodnotu 0.

Teď reaguji na jeden z dřívějších postů, věnující se citovanému stavu. Dnes jsem dělal jiné pokusy související s problémy jednoho uživatele s přehráváním obsahu jednoho seriálu z SCC (ben 10_ Alien Force 1x01). Opět došlo k situaci, kdy po spuštění přehrávání v době, kdy se plní video cache, poklesne rychlost stahování na cca méně než 50 % běžné maximální rychlosti. Ta maximální je u mne cca 147 Mbps (mám tarif 150/10 Mbps). Došlo k tomu, že se, po zaplnění bufferu na větší hodnotu než 75 % alokované cache, stahování zastaví a obnoví se až po vyčerpání cachce na těch 75 %. Zatímco to, proč se stahování zastaví, jsem už vysvětlil dříve (jde o situaci, kdy se zaplňuje zpětný buffer na úkor toho dopředného, které se stabilizuje ve chvíli, kdy se zaplnění ustálí na poměru zpětný/dopředný = 25/75), tak ten stav, proč rychlost klesne na 50 % maximální rychlosti asi není tím, že by došlo k snížení přenosové rychlosti na profilu mezi klientem a webshare (takový závěr jsme učinil v předchozím postu). Zkusil jsem totiž hned vzápětí pustit jiný stream (Black Panter: Wakanda nechť žije), a tam plnění bufferu jede maximální rychlost blížící se 150 Mbps.

Takže z těch asi tří stavů chování, které jsem se tu snažl popsat a pochopit, se dva již podařilo vysvětlit, ale ten poslední, proč u některých streamů rychlost komunikace při plnění bufferu poklesna na cca 50 % obvyklé maximální rychlosti, se mi vysvětlit nepodařilo. To, že by v okamžiku přehrávání došlo k omezení rychlosti na trase se totiž nepotvrdilo! Podle dosavadních zjištění by to tedy mohlo záviset:
  • na typu přehrávaného streamu/kontejneru
  • na konkrétním fyzickém umístění zdrojového souboru, tedy stavu, kdy by některé servery na webshare měly omezenou rychlost komunikace...
Zkusím:
  1. stream stáhnout a podívat se, co je zač
  2. budu si protokolovat adresy serverů SCC přehrávaných stremů a snažit se najít takové, u kterých je maximální rychlost komunikace omezená a zjistit, zda je tam nějaká závislost
Pokud bude mít někdo nějaký nápad, budu vděčný.
 
Citovat
#12
@JiRo: Musím složit poklonu za způsob, jakým umíš témata vysvětlit. Hodně mi to pomáhá. Dvěma věcem v tomto tématu nerozumím.
1) Proč si video cache zabere trojnásobek nastavené hodnoty. Jaký je mechanizmus zápisu/čtení, že pro 1B dat potřebuje 3B prostoru v RAM.

2) Ty říkáš, že nepoužíváš video cache, protože ji máš nastavenou na 0. Ale ve wiki je napsáno, že nastavení na 0 "zakáže" video cache v RAM a Kodi ve skutečnosti použije jako video cache veškerou dostupnou velikost pevného disku daného zařízení (SSD, eMMC, uSD...). Takže, jestli jsem to správně pochopil, pak může být video cache naopak mnohem větší, i když zřejmě pomalejší.
X96max plus 4/32 + CE 21 RC2 + skin Confluence SCC / TV Samsung QE55Q6FNA
X96max plus 4/32 + CE 20.5 + skin Confluence SCC

AVR Denon 1600H / Dali Spektor 5.1
Win10pro + Kodi19.5
NAS Synology 215j 3TB Raid1
Router Turris 1.1
 
Citovat
#13
@jkmh: ad.1 Tady to mi taky není 100 % jasné. Podle mne je to nějaká historická strategie a nejsem si 100% jistý, co za ní stojí. Ještě tak bych si to dokázal vysvětlit u některých kontejnerů, kde se používá tzv. double buffer, ale proč trojnásobek, tak to asi uspokojivě vysvětlit nedokážu. Jak jsem psal výše, zkoušel jsme to šponovat na nějaká hodně vysoká čísla, ale samo Kodi to nepustilo dále, než přes 1 500 MB (U 4 GB operační paměti) a sice běželo, ale stream se už nepřehrál. Problém je, že když se to stane, tak např. SCC nahlásí, že daný stream nenalezl, ale žádný další chyba se neprotokoluje... Takže je lepší se té strategie (trojnásobek + rezerva) držet.  1

ad. 2 Tady bych měl asi vysvětlit pojmy:
  1. cache v operační paměti
    • buffermode = 0, 1, 2 nebo 4
    • memorysize > 0
  2. úplný zákaz cache, tzn. cache = 0
    • buffermode=3
    • na ostatních parametrech nezáleží
  3. cache na disku - v souboru special://home/filecache000.cache, případně special://home/filecache0001.cache, případně i vyšší čísla ...002, 003, ..., pokud už nějaké tyto soubory existují. Někdy totiž, při havárii přehrávače nebo i celého Kodi při přehrávání, tam ty soubory mohou zůstat a Kodi je ani po restartu nesmaže! To je pak dost nepříjemné, protože velikost těch souborů může být značná.
    • buffermode = 0, 1, 2 nebo 4
    • memorysize = 0
  4. cache default = není soubor advancedsettings.xml nebo v něm není tag <cache>, resp. v něm chybí některý z vnořených tagů. Pak jsou default nastaveny takto:
    • buffermode = 0
    • memorysize = 20971520 (20 MB)
    • readfactor = 4.0
    • chunksize = 65536
Jinak aktuální popis v Kodi Wiki najdeš v Advancedsettings.xml.

K té variantě nastavení č. 3 - cache na disku je samozřejmě trochu problém, pokud tím diskem je např. SD karta, protože dlouhodobé používání tohoto modu ji může zásadním způsobem zkrátit životnost. To, že je ta cache pomalejší by asi ani tolik vadit nemuselo.
 
Citovat
#14
Souhlasím s tebou, že strategie je dobré se držet. Jen jsem prostě šťoural. A buffermode jsem si s tím nespojil. Příště musím ve wiki číst důkladněji.  3
X96max plus 4/32 + CE 21 RC2 + skin Confluence SCC / TV Samsung QE55Q6FNA
X96max plus 4/32 + CE 20.5 + skin Confluence SCC

AVR Denon 1600H / Dali Spektor 5.1
Win10pro + Kodi19.5
NAS Synology 215j 3TB Raid1
Router Turris 1.1
 
Citovat
#15
@jkmh @JiRo Tak na odpovědi jsem opravdu zvědavý.
((Samozřejmě jsem je propásl psaním!))
Mohu přispět několika fantasiemi (nebudu je nazývat teorie).
1..
Nejdříve, jak si představuji zápis do cache. Chache je vymezena počátkem a koncem, zápis začíná samozřejmě na počátku a pokud se zaplní až ke konci, přepisuje se cache od začátku.

Při startu (Play) nic jako backward nemá smysl. (Přeskočím, co se ukáže po odklepnutí Play.)
Ukazatel adresy právě "promítaného snímku" běží kupředu (pominu pro jednoduchost, že se jedná o pixely) a nad ním se plní cache forward. V celém objemu cache je nad ním o 75% (tam se omezí), tedy za právě "promítaným snímkem" zůstává 25% nepřemazaného objemu cache. Backward.

To před a za je relativní vzhledem k přepisování cache.

2..
Jak bych viděl rychlost doplňování cache.
Pokud spustím videostream příkladně s tokem 20Mbps, první naplnění může být nejvyšší rychlostí linky, příkladně 140Mbps. Přehrávám celé do konce - doplnění cache může být plynulé 20Mbps nebo kolísá, jak je určeno "neznámou" logikou.
Pokud budu opakovaně posouvat třeba o 2 minuty vpřed, bude cache vyžadovat zahodit obsah a načíst nový. Tím se celkový objem stažených dát nezvýší, ale bude se ve špičkách stahovat nejvyšší rychlostí.
A teď - co když je toto ochráněno, aby se zatížení místní sítě férově podělilo a také na sebe neupozorňovalo dodavatele internetu...
Nějaký modul může počítat "rozumnou" výši hodnoty rychlosti stahování (nad 20Mbps) a doplňování cache zpomalit...

3..
Proč nejde cache zvětšovat nad doporučenou mez a dochází k podivném chování.
Opět je to má fantasie ale zde už hraniční.

Přehrávač Kodi komunikuje s cache mechanismem, ke kterému potřebuje ukládat adresy právě přehrávané části a modul cache si musí řídit doplňování forward, opět má někde uloženou adresu.
Může být, že programátor nepočítal se zápisem adresy vyšší než..? Nevím. 1024? v desítkovém vyjádření...
Může být, že potom i výpočet "rozumné" rychlosti stahování bude zmatený...

Kones fantasií, bude to horkem 4
Kodi 20 -LibreELEC/LinuxMint/Win/Android -RPi4/3/2/ IntelPC/xMiStick4K -Router 1Gbit 2.4+5GHz
 
Citovat
#16
Chtěl jsi nápady, tady je máš.  3

@meda: A proč se chová divně při přešvihnutí video cache? Já si myslím, že se začne systém nedostatkem RAM dusit a tím pádem začne swapovat momentálně nepotřebné aplikace, aby si uvolnil místo. Jenže swapování je pomalé a při nedostatku RAM nestíhá odkládat a následně načítat to, co aktuálně k běhu potřebuje. A pokud je video cache limitovaná, tak swapovat nepotřebuje nebo jen minimálně. Nezkoumal jsem to, ale v htop by to mohlo být vidět.
X96max plus 4/32 + CE 21 RC2 + skin Confluence SCC / TV Samsung QE55Q6FNA
X96max plus 4/32 + CE 20.5 + skin Confluence SCC

AVR Denon 1600H / Dali Spektor 5.1
Win10pro + Kodi19.5
NAS Synology 215j 3TB Raid1
Router Turris 1.1
 
Citovat
#17
@meda Já se vyjádřím jen k té logice zápisu do cache. Na začátku přehrávání je pro dopředný buffer vyhrazeno 100 % paměti vyhrazené pro cache. Jakmile se začně přehrávat, tak to, co se už přehrálo se zapíše do zpětného bufferu a to co se přednáčítá zapisuje zase do dopředného bufefru. Ono to fyzicky není tak, že by se plnily dva buferry samostaně, ale představme si to jako "dvoudílné okno" putující po paměti vyhrazené pro cache, které se pohybuje a zároveň se mění poměr mezi oběma jeho částmi. Od počátečního rozdělení 0/100 do konečného 25/75. V okamžiku, kdy se skočí dopředu, záleží na tom, jestli se skočí až za část, která je načtená v dopředném bufferu, nebo se skočí do místa, které je ještě v dopředném bufferu načtené. Pokud je to ten první případ, tak se vše znuluje a začíná se znova. Pokud ten druhý, tak se to pomyslné okno jen posune, obsah dopředného bufefru se o ten posun sníží a pokračuje se v přednačítání, obsah zpětného bufferu se (a zase podle toho, jak je ten skok "dlouhý") buď vynuluje, nebo jen poměrně sníží. Ty bufffery jsou samozřejmě cyklické, tzn. že se v něm ten algoritmus pohybuje stále dokola.

A ještě poznámka k tomu, jak to, že někdy dojde k tomu, že se dopředný buffer naplní nad hodnotu 75 % a pak se začně postupně vyčerpávat až zpátky k hodnotě 75 %. Někdo se může zeptat, proč se to děje jen někdy a na čem to tedy vlastně závisí. I tady je ta odpoěď poměrně jednouduchá. Tady v tom případě záleží na tom, jak vysoký je datový tok vlastního streamu. Pokud je totiž dostatečně vysoký (oproti maximální rychlosti komunikace), tak se ten zpětný buffer zaplní dříve, než se stačí zaplnit ten dopředný. Tzn. že maximální zaplnění dopředného bufferu nikdy nepřekročí 75 %. Je-li ale ten datový tok vlastního streamu menší, tak dojde k tomu, že se dříve zaplní dopředný buffer než ten zpětný, tudíž ten algoritmus načítá dál přes limit 75 %, a to až do chvíle, než se to srovná. V okamžikui, kdy jsou oba bufferu naplněné, tak se ten dopředný přestane načítat, a to až do doby, než jeho zaplnění klesne na 75 %.

A protože mi ještě vrtá hlavou ta odpověď @meda: v jeho bodě 2, přemýšlel jsem ještě o jeho domněnce. A možná že by to mohl být klíč k té záhadě, jak to, že se někdy významně sníží rychlost načítání.

Jak @meda: píše, mohl by ten algoritmu na základě spočítaného poměru rychlosti načítání a rychlosti vlastního streamu skutečně usoudit, že není třeba načítat tak rychle a rychlost snížit. To ostatně koresponduje s podobnou teorií, kterou jsem před pár příspěvky také uvedl. Jenže já si myslel, že by tohle mohl dělat přímo Webshare, ale mně samotnému se to zdálo nepravdpěodobné ("To se pak člověk na něco upne..."). Ale Méďova teorie to vysvětluje smysluplně.  6

Takže další hraní bude s hodnotou readfactor, který by na tohle chování možná měl mít vliv... Až budu mít zase chuť na laborování, vyzkouším několik nastavení a pak tu budu informovat...

Jasně! Vyřešena i poslední záhada. Díky @meda: jsem se zamyslel nad tím, jakou roli má parametr readfactor a ještě pro jistotu si znova prošel jak Wiki, tak github, a teď už mi to dává smysl! A rovnou to i vyzkoušel u streamu z SCC, který jsem už jednou testoval (ben 10_ Alien Force 1x01 - průměrná bitrate má rozhodně pod 10 Mbps). A vyšlo to přesně tak, jak jsem předpokládali.

Při nastavené hodnotě readfactor = 20, se rychlost načítání pohybuje kolem 80 Mbps. Jakmile nastavím readfactor = 40, tak se rychlost posune k maximu mé linky, tedy lehce pod 150 Mbps, tedy stejně, jako u streamů s výrazně vyšším průměrným datovým tokem. Ještě to prověřím i při dalších kombinacích nastavení a rychlostech steramů, ale řekl bych, že mi to začalo dávat smysl.
 
Citovat
#18
@JiRo Jen si chci ujasnit chápání tvé věty:
"Jakmile se začně přehrávat, tak to, co se už přehrálo se zapíše do zpětného bufferu a to co se přednáčítá zapisuje zase do dopředného bufefru."

Já bych ji chápal: "to, co se už přehrálo zůstane obsahem zpětného bufferu a to, co se přednáčítá, zapisuje zase do dopředného bufefru."
Ale tak, že dopředný buffer přepisuje nejstarší obsah zpětného bufferu.

Myslíme totéž?
Kodi 20 -LibreELEC/LinuxMint/Win/Android -RPi4/3/2/ IntelPC/xMiStick4K -Router 1Gbit 2.4+5GHz
 
Citovat
#19
@JiRo: Wiki to tady vlastně píše: https://kodi.wiki/view/HOW-TO:Modify_the_video_cache. čím vyšší je nastavení readfactor, tím je větší rozdíl mezi datovým tokem načítání do cache a čtení z cache.
X96max plus 4/32 + CE 21 RC2 + skin Confluence SCC / TV Samsung QE55Q6FNA
X96max plus 4/32 + CE 20.5 + skin Confluence SCC

AVR Denon 1600H / Dali Spektor 5.1
Win10pro + Kodi19.5
NAS Synology 215j 3TB Raid1
Router Turris 1.1
 
Citovat
#20
@meda Ano, přesně tak. Však jsem to tam psal, že nejde o dva buffery, ale o jakési dvoudílné okno, které se pohybuje cyklicky v rámci rezervované cahce. Ta příčka mezi nimi, což je aktuální poloha v přehrávaném streamu, je ale dynamická a její "poloha v rámci okna se mění podle podle toho, kolik se toho už přehrálo. Ale jen do doby, než se dosáhne poměru 25/75. Myslím, že jsme to pochopili oba stejně.

Ono jako "dva buffery" je to třeba chápat situaci, kdy se provede skok dopředu, v rámci kterého sice stále ještě zůstaneme v rámci dopředného bufferu přednačtených dat, ale už se dostaneme mimo rozsahu toho zpětného bufferu, protože je jejich velikost rozdílná (25/75). Ale jinak je to samozřejmě úplně jedno. Jde o jeden společný datový prostor, jen se tam v kódu manipuluje s pointry, podle kterých se v rámci video cache čte a zapisuje a které se případně mění podle toho, kam a o kolik skočíme dopředu nebo dozadu...  6

@jkmh Ano, je to tak. Jen mi to hned nedocvaklo a teprve, když jsem začal formulovat to, jak ta cache vlastně pracuje, jsem si na to vzpomněl.

@meda: a @jkmh: díky za tuto konkrétní spolupráci. Myslím, že jsme zase o kousek postoupili ve znalostech, které ale zas tak potřeba nejsou. Sice teď o něco více víme, jak to funguje, ale i když jsme to nevěděli, tak nám to fungovalo dobře, ne? 1
 
Citovat
  


Přejít na fórum:


Prochází: 1 host(ů)