• 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 9.2.8
 
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 19.5RC2 + skin - upravený Confluence / TV Samsung QE55Q6FNA
AVR Denon 1600H / Dali Spektor 5.1
Win10pro + Kodi19.2 Matrix
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 19.5RC2 + skin - upravený Confluence / TV Samsung QE55Q6FNA
AVR Denon 1600H / Dali Spektor 5.1
Win10pro + Kodi19.2 Matrix
NAS Synology 215j 3TB Raid1
Router Turris 1.1
 
Citovat
  


Přejít na fórum:


Prochází: 1 host(ů)