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

Musím se přiznat, že nastavení Adaptive je pro mě novinkou.
Když odhlédnu od pokusu s přerušením netu, nevím, jestli je lepší verze s pevným či dynamickým readfaktorem.  S pevným je sice větší náraz, ale celkově po kratší dobu. S dynamickým je zátěž rozprostřena v čase, ale každý vzorek představujevyšší zátěž. Alespoň dle screenů.
Toto dilema by asi vyřešil monitoring serveru pro obě varianty. Samozřejmě s patřičným počtem uživatelů.
Faktem je, že v obou pokusech se musí přenést stejný objem dat a časový vzorek je relativně krátký. Zajímavé by bylo zjištění, co team Kodi k tomuto řešení vedlo.

@jkmh: Myslím, žes to popsal docela přesně. Včetně toho testování, kde nemáme šanci to nějak prokazatelně provést. Ještě bude zajímavé podívat se na průběh přehrávání v situaci, kdy budou server Webshare zatíženy (hlavně ty problematické), jak se to bude chovat tam. Ale jinak asi šance nějak prokázat, že adaptivní nastavení je lepší, není. Spíše je to pocit, ale ani já si tím nejsem 100% jistý...

A mimochodem. Konečně, ve verzi CE 21, funguje správně pořízení screenshotů i ve 4K rozlišení. Teď jsem zkoušel udělat screenshot při přehrávání 4K s průměrný bitrate 70 Mbps a provedlo se to bez problémů. U verze CE 20 mi zamrzl celý systém.

No mně to se screenshotem při přehrávání pořád nevychází. Ve větší či menší míře je vidět vykreslování.

@JiRo: Protože v řádku 3 informací Player Debug Info přibyly další hodnoty, viz tvé uvedené přílohy, mohl bys, prosím, uvést pro lepší pochopení jejich význam?
Řádek začíná Player a pokračuje přes Forward...

A zadruhé poprosím, mohl bys podobně, jako přerušení přísunu dat, vyzkoušet naopak (aby se to přiblížilo mým starším testům)
po 1. minutě od začátku přehrávání na 1 minutu udělat Pause, pak znovu Play - jak bude vypadat graf následující minuty?
Díky

@meda: No, s těmi informacemi v Player Debug Info u CE 21 se sám ještě dost potýkám, protože jsem nenašel čas k tomu ověřit si, jak a čím jsou teď vlastně plněné. Trochu jinak se to chová v okamžiku, kdy se přehrává něco, co video cache nepoužívá a trochu jinak, když se naopak video cachce využívá. A celé se to chová trochu jinak než u CE 20 20. Budu nad tím muset ještě chvíli přemýšlet, případně položit dotaz vývojařům.

Požadovaný test je níže, snad jsem to pochopil správně. Video s průměrným bitrate 9 Mbps, maximum tarifu 150 Mbps. Udělal jseme tři screenshoty, vždy po minutě, aby byly vidět právě i hodnoty Player Debug Info.

-1:00 Spuštění přehrávání
[attachment=10345]
-2:00 Spuštění přehrávání, -1:00 Pause
[attachment=10347]
-3:00 Spuštění přehrávání, -2:00 Pause, -1:00 Play
[attachment=10346]

@JiRo: Když se tedy dívám na ty hodnoty % v P.D.I., není tam ještě 100%. Zřejmě adaptivní režim číslo <readfactor> hodně sníží. Proto asi nedošlo k mnou očekávanému výraznému poklesu na grafu během Pause. (Data nejsou potřeba pro Player ale do cache stále putují.)
Byl jsem totiž zvědavý, jak po výrazném poklesu datového toku se projeví opětovné spuštění Play.

Jak jsem minule poukázal na hodnoty % ve verzi Kodi Beta2, že se chováni Bufferu Playeru po Pause výrazně změní.
Poslední odstavec: https://www.xbmc-kodi.cz/prispevek-libre...#pid127042

@meda Ano, ten <readfactor> se pohybuje kolem 2-3. A k poklesu nedošlo, protože cache nebyla ještě zaplněná.

Mám Odroid N2+ se 4 GB RAM. Caching jsem měl nastavený na 20MB + read factor 4x + Gigabit od Vodafone (bývalé UPC přes koax). Vždy vše ok jen večer právě okolo té 19-20 hod se občas přehrávání seklo na chvíli. Read factor jsem nechal 4x. Memorysize jsem teď zvedl na 256MB (před zvednutím byla volná paměť cca 3300 MB, takže cajk).

Někdy se stane, že se přestane přehrávat a "spadne" to (chvíli je to zamrzlé, řádově jen sekundy a pak blik a jsem zpět v seznamu, ze kterého jsem přehrávání spouštěl). Pustím znovu STEJNÝ soubor od zapamatované pozice a někdy to inkriminované místo projede ok a pokračuje dál. Ale někdy se stane, že to na stejném místě spadne znova i třeba 3x po sobě a teprve až zvolím JINOU variantu souboru, tak to místo projede ok. 
Odhaduji, že to nesouvisí s cachingem apod, ale že může být ten soubor v tom místě poškozený/špatně uložený/ apod...

@pnowak: Ano, pokud to padá u streamu na stejném místě, je pravděpodobnost poškozeného steramu dost vysoká. Ale nemusí to tak být vždy. Pokud je např. průměrná bitrate titulu blízká aktuální propustnosti sítě (celému profilu od Webshare až po Koid) a cache není příliš veliká nebo se dokonce v průběhu přehrávání nedaří držet její naplnění na nějaké vysoké hodnotě (blízké 100 %) a ve filmu přijde nějaká dlouhá dynamická scéna, ve které se okamžitý bitrate streamu dramaticky zvýší, může dojít k vyčerpání cache a přehrávání se zastaví. Bohužel v současné době ta reakce Kodi není taková, jako to bývalo kdysi, kdy se prostě přehrávání pozastavilo a čekalo se na dočtení bufefru. Tohle už při nových typech kódování nefunguje tak, jak by mělo a tak to dopadně tak, že se přehrávání prostě ukončí.

Jak z toho ven? Tady je každá rada drahá a záleží na celé řadě okolností, jejichž vyhodnocení je možné pomocí kombinace sledování logu Kodi (viz Pozn. 1) a Player Debug Info, kde se ukáže, co se vlastně kolem datového toku přehrávaného streamu, naplnění cache, případně nějakých problémů s kvalitou streamu, dá vyhodnotit. Ještě je dobré se při tom podívat, co se děje na straně komunikace, a k tomu se dá použít doplněk Speed Meter, který ti dokáže současně ukázat rychlost komunikace na síťovém rozhraní a její průběh v posledních 3 mintutách. Ale jednoduchý a jednoznačný návod, jak si to vyhodnotit ti asi tak rychle nedám. Těch variant, stavů a okolností, které je třeba v tomto případě vzít v úvahu je hodně a dost složitě se to popisuje.

Pozn. 1 Co se týče sledování logu Kodi, tak tady mi pomáhá otevřít si on-line zobrazení logu pomocí SSH terminálu do systému s Kodi (musí to ten systém samozřejmě umožňovat) z PC na síti, kde vidím okamžitě, co se v logu děje  a vidím tam tak okamžitě případné zápisy o problémech přehrávače Kodi pro přehrávaní streamu. Já pro to používám (u *ELEC) systémů aplikaci tail, kde si ji sputím jako:
 
To mi, současně s výše uvednými nástroji (Player Debug Info a Speed Meter), dokáže říci hodně o tom, co se vlastně děje.

@JiRo Díky za vyčerpávající odpověď.
Nakonec zvolím variantu mrtvého brouka <=> to spadnutí přehrávání je tak ojedinělé (cca 4x měsíčně), že to nestojí v tuto chvíli za řešení.

Asi @meda: ještě dlužím nějaké odpovědi na otázky, týkající se video cache Kodi a zobrazení v Player Debug Info, ale věřím, že mé odpovědi budou užitečné i pro ostatní. Proto také vezmu popis poněkud zeširoka, a možná v něm uvedu i některé již notoricky známé věci, což mi ale @meda: jistě odpustí.

V Kodi Wiki Player Process Info samozřejmě existuje popis toho, co zobrazení funkce Player Debug Info obsahuje, tento popis je ale zastaralý a úplně 100% neodpovídá aktuální release verzi Kodi 21. Nicméně doporučuji si to přečíst. Taky se rovnou přiznám, že ani já neodpovím na všechno a určitě ne vyčerpávajícím způsobem, ale pokusím se nějak sdělit to, co jsem (zatím) vypozoroval. Dnešní příspěvek tedy budu věnovat pouze části Player Debug Info na části 3. řádku, začínající textem forward:.

Část screenshot-u, kde 1. řádek (kombinace bílého a modrého textu) jsou vybrané informace, které do zobrazení full screen přidává můj skin, následující 4 řádky (pouze bílý text) jsou všas plně údaje Player Debug Info:


Co tedy část za textem forward: obsahuje. Jsou to celkem 4 údaje oddělené znakem / a já je pro další budu označovat jak 1. údaj, 2. údaj atd. Co je třeba říci hned na začátek je, že to, co tyto údaje obahují, je závislé na tom, v jakém režimu se přehrávání video souboru/streamu nachází. To je určeno dvěma skutečnostmi:

• jaký soubor/stream se přehrává,
  
• jak je v Kodi nastaven tzv. caching (viz Pozn.1), tedy nastavení video cache Kodi.
  

Pozn. 1 Video cache se v Kodi od verze 21 nastavuje prostřednictvím nastavení Kodi v Nastavení > Služby > Caching. Kodi tedy už nepoužívá ani nečte parametry ze souboru advancedsettings.xml.

Kombinace dvou výše uvedných skutečností je pak při přehrávání východiskem pro:

1. Nepoužití cache - což je v případě, kdy nastane alespoň jeden z případů:
   • použití cache je v nastavení vypnuto (Buffer mode má hodnotu No Buffer)
     
   • přehrává se soubor/stream ze zdroje, který neopodvídá nastavenému Buffer mode
     
   • přehrává se stream definovaný prostřednictvím adaptivního prokolu (např. HLS, MPGE-DASH)
     
   • přehrává se tzv. PVR stream 
     
2. Použití cache - což je vždy, když nenastane žádný z případů uvedených v bodě 1.
   

Takže, jaký je význam 4 údajů v případě (ne)použití cache?

Při nepoužití cache:

1. údaj [MB/kB/B] - trvale se zobrazuje hodnota 0.00 B
   
2. údaj [%] - aktuální zaplnění (viz Pozn. 2) bufferu (viz Pozn. 3) Kodi přehrávače v %
   
3. údaj [sec] - vypočítaná doba (viz Pozn. 4) přehrávání nabufferovaných dat v sekundách
   
4. údaj [%] - nabuferovaná data v %, vztažená ke známá celkové velikosti (Pozn. 5) přehrávaného obsahu (což je při výpočtu % nabuferovaných dat chápáno jako 100 %)
   

Pozn. 2 - Kodi se snaží udržovat velikost buferu na co nejvyšší hodnotě. Záleží na typu přehrávaného soubor/streamu, jak se mu to daří. Primární je samozřejmě udržování synchronizace přehrávání s relativním časem přehrávaného obsahu, což také určuje typické hodnoty zaplnění, které se ne vždy a trvale musí držet na hodnotě 100 %. To ale není chyba. Např. o PVR steramnů (např. Live TV) se může pohyboat i kolem 70 % nebo dokonce i 30 % a přesto je přehrávání plynulé. Záleží na typu protokolu, řetězci zpracování takových streamů, např. Tvheadend + streamlink/ffmpeg nebo InputStream Adaptive, atp.
Pozn. 3 - buffer přehrávače je v kódu Kodi definovaná struktura, v současné verzi Kodi o velikosti 20 MB. Změnit se dá pouze zásahem do zdrojového kódu a novým přeložením celé aplikace.
Pozn. 4 - tento údaj velmi přibližne udává, na jak dlouhou dobu nabufferovaná data postačí k plynulému přehávání v případě, že dojde k přerušení komunikace se zdrojem dat. Vzhledem k dynamice prezentace dat, případného vlivu algoritmů adaptivních porotkolů, je to údaj opravdu jen velmi přibližný. Ostatně jeho smysl a praktické využití tomu odpovídá. Je to jistě zajímavé číslo, ale praktický význam nemá, tedy já ho alespoň moc nevidím.
Pozn. 5 - ne vždy může Kodi v tomto případě získat informace o celkové velikosti přehrávaného obsahu. To se týká především PVR streamů, u kterých se % nabufferovaných dat proto vztahuje ke známé velikosti získané z jiných dostupných informací (pokud jsou k diposzici). U Live TV např. z EPG. Význam tohoto údaje je tedy trochu podobný tomu předchozímu.

A při použití cache:

1. údaj [MB/kB/B] - aktuální hodnota zaplnění dopředného bufferu cache v MB/kB/B (viz Pozn. 6)
   
2. údaj [%] - aktuální zaplnění dopředného bufferu cache v % (viz Pozn. 6)
   
3. údaj [sec] - vypočítaná doba (viz Pozn. 7) přehrávání nabufferovaných dat v sekundách
   
4. údaj [%] - nabuferovaná data v %, vztažený ke známé celkové velikosti (Pozn. 8) přehrávaného obsahu (což je při výpočtu % nabuferovaných dat chápáno jako 100 %)
   

Pozn. 6 - video cache a její dopředný (forward) buffer je samostatné téma a byl mu věnován tento příspěvek. Zde tedy jen upozornění, že hodnota v % je vztažená k aktuální alokaci cache pro dopředný buffer, která ale může být dynamická a zejména v počátku přehrávání nebo po velkém skoku vpřed a nebo vzad může alokace pro dopředný buffer překročit oněch 75 %, jak je popsáno v odkazovanám příspěvku. 
Pozn. 7 - v případě tohoto údaje je v případě nepoužití cache napsáno, že velmi přibližne udává, na jak dlouhou dobu nabufferovaná data postačí k plynulému přehávání v případě, že dojde k přerušení komunikace se zdrojem dat.  V případě použití cache je tato neurčitost údaje ještě zásadnější. Navíc výpočet této doby závisí na tom, jak je nastavena vlastní cache, její umístění i strategie jejího plnění. Platí tedy pro ni ještě více to, co jsem uvedl v závěru Pozn. 4 výše.
Pozn. 8 - tady, oproti stavu při nepoužití cache, je situace celkem jasná. Velikost přehrávného obsahu je většinou známá, takže i tento údaj je většinou vždy relevantní v původním slova smyslu. Celkem jasně je to vidět a význam tohoto údaje, včetně vztahu ke 2. údaji to potvrzuje, v případě, kdy si zkusíte nejdříve nastavit cache do paměti, kdy je velikost cache limitovaná a pak na disk, kdy je neomezená (pokud tedy na disku místo pro celý přehrávaný obsah máte). Zatímco v prvním případě bude hodnota tohoto 4. údaje většinou menší jak 2. údaje, ve druhém případě budou hodnoty vždy shodné.

---

To je asi vše, co v danou chvíli k této probelmatice mohu dodat. Jasně, je zde hodně věcí, které by se daly ještě zkoumat, v řadě případů by předpoklady a odhady toho, jak to vlastně funguje, daly zlepšit či definitivně objasnit i analýzou kódu Kodi, ale já to, alespoň pro sebe a tuto chvílu, už považuji za zbytečné. Nic mi to nepřináší.

Je také možné, že se v hodnocení funkcí mohu mýlit, takže máte-li nějaká další zjištění nebo jiné názory, klidně je sem napište a můžeme se o tom tady pobavit.

@JiRo: Mám co studovat

Mýty a fakta o Trakt.tv (2) - Ale nejen o něm, také o stavu rozkoukáno a shlédnuto.

Jde o volné pokračování tématu, týkající se Trakt.tv v Kodi, kde předchozí díl najdete v Mýty a fakta o Trakt.tv (1) - Seznam ke shlédnutí (Watchlist) a seriály.
 

---

Původně jsem tento příspěvek vložil do jiného tématu, a reagoval jsme v něm na nepochopení toho, jak Kodi pracuje a zejména, jak pracuje se stavy rozkoukáno a shlédnuto v případech prostých videí, videí vložených jako titul do knihovny a videí, která jsou přehrávána z doplňku. V tomto jiném tématu jsem reagoval na jeden z příspěvků, ze kterého vyplynulo, že dotyčný ani netuší, jak se vlastně věci mají. Takže Cut/Paste a je z něj další pokračování v tomto tématu.

---

Co se týče toho, jak vlastně Kodi v uvedené problematice pracuje, nejde o téma, které by se týkalo jen jedné jeho oblasti. Takže to popíši, sice stručně, ale tak, aby to pokrylo maximum možného v pár bodech:

1. Kodi do své video databáze zapisuje stav sledování (rozkoukáno a shlédnuto) jakéhokoliv videa, ať je jen v databází, knihovně a nebo je to video spuštěné v doplňku. V tom posledním případě musí být doplněk samozřejmě napsán podle zásad a pravidel Kodi.
   
2. Pokud je video uložené v kihovně (film nebo seriál, netýká se tedy videa přehrávaného v doplňku) a v Kodi je nainstalován doplněk Trakt (id: script.trakt), je správně nastavený (stačí default nastavení), a je propojen s účtem na Trakt.tv, tak se do něj přenáší informace o shlédnutí (ne tedy o rozkoukání) daného titulu.
   
3. Některé doplňky (např. SCC nebo SC) mají vazbu na Trakt.tv vytvořenou ve vlastní režii. Tzn. že se stav shlédnuto do Trakt.tv přenáší i v případě přehrávání titulu z toho doplňku.
   

K tomu několik poznámek a příkladů, co to v praxi znamená:

1. Pokud se tedy přehrává video z doplňku, který nemá vlastní integraci s Trakt.tv, tak se do něj stav shlédnuto nepřenese, ani když je v Kodi nainstalován a porpojen s účtem doplněk Trakt.
   
2. Stav rozkoukáno a shlédnuto se z video doplňku přenese do video databáze Kodi, a to i tehdy, pokud ho doplněk přenese do Trakt.tv. Kdo si vzpomíná na SCC, tak tam byly v kontextmenu dvě položky týkající se označení shlédnuto/neshlédnuto. Jedna se týkala vido databáze Kodi, druhá Trakt.tv.
   
3. Samozřejmě, že stav rozkoukáno a shlédnuto se nastavuje ve videodatabázi Kodi podle toho, jak jsou v něm nastaven nastaveny meze pro vyhodnocení stavu přehrávání (v advancedsettings.xml se tyto meze dají změnit).
   
4. Většinou se stavy rozkoukáno a shlédnuto aktualizují (ve video databázi Kodi i na Trakt.tv) bezprostředně při skončení přehrávání. Jak doplněk Trakt, tak doplňky, které vazbu na Trakt mají ve vlastní režii (SCC, SC), ale mají k dispozici některé funkce, které umožňují expost přenést hromadně některé stavy z Trakt do Kodi a/nebo naopak.
   
5. Většina z toho, co je zde uvedeno o nastavování stavu rozkoukáno a sklédnuto platí za předpokladu použití interního přehrávače Kodi. Při použití externího přžehrávače existuje možnost, jak nastavit příznak shlédnuto staticky, na základě pevně zadané doby, po kterou je přehrávač pro přehrávání daného titulu používán.
   

@JiRo: Děkuji za krásný přehled těchto vazeb. Trochu mě mrzí, že třeba doplněk MAX (možná se zase bude jmenovat HBO MAX), tuto integraci nemá, a proto se stav shlédnuto nepřenáší do Traktu. Existuje doplňek WhiteLodge, který má tuto chybějící integraci do kinohvny nahradit pro hodně streamovacích platforem. Bohužel, vypadá to, že se přestal vyvíjet a dost dobře mi to teda nefungovalo, zkoušel jsem PC i Android. Má někdo jiné zkušenosti?