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

"Přeinstaloval jsem Kodi i SCC a už mi to funguje,"

je jedna z nějčastějších hlášek, které se (a nejen v poslední době) na fórech věnujících se Kodi a jeho v ČR asi nejpopulárějšího doplňku SCC, objevuje. Co je zajímavé, že ani po létech osvěty a vysvětlování si stále ještě většina uživatelů, a to i těch, kteří o sobě tvrdí, že Kodi znají, neuvědomuje, jak to s Kodi a doplňky, co se týče procesu jejich instalace, vlastně je. Tak přidávám několik postřehů, které to snad pomohou osvětlit.

Kodi v systému, na kterém je instalován, zpravidla obsadí dva adresáře. Mohou existovat jisté výjimky, ale ty jsou právě jen výjimkami. Prvním adresář je ten, do kterého se instaluje vlastní Kodi - říkejme mu pro zjednodušení <kodi>, druhým pak ten, do kterého se instalují data - tomu budeme říkat <home>. Ve skutečnosti se v souborovém systému různých typů instalací mohou tyto adresáře jmenovat různě, záleží na tom o jaký systém (operační i souborový) jde. Aby se to nepletlo, má samo Kodi pro tyto adresáře ještě své vlastní označení, které je použitelné pouze v rámci Kodi a jeho doplňků, prostřednictvím tzv. special protokolu. Ale tím si to teď nebudeme komplikovat.

Co je podstatné je to, že do adresáře <kodi> se instaluje vlastní Kodi a nic jiného, a že adresář <home> je naopak adresářem, do kterého si Kodi a jeho doplňky ukládají všechny další data a také adresáře, do kterého se ukládají i samy doplňky, tedy jejich výkonné části. Tady je třeba zmínit jednu skutečnost a tou je, že v okamžiku, kdy si v nějakém systému poprvé nainstalujeme samotné Kodi, tak se adresář <home> ani nevytvoří, natož aby se do něj při instalaci kopírovala jakákoliv data. Adresář Home se vytvoří a data se do něj nakopírují až po prvním spuštění poprvé nainstalovaného Kodi. Můžeme si z toho odvodit první znalost, a tou je to, že:

1. Chceme-li existující Kodi dostat do stavu po jeho prvotní instalaci, postačí úplně (při zastaveném Kodi) smazat adresář Home, či alespoň jeho obsah. Pak stačí Kodi spustit a máme k dispozici prázdné a čisté Kodi, které si s sebou nenese žádnou zátěž způsobenou jeho předchozím používáním.

To samé můžeme použít u většiny doplňků. U těch je to podobné. Při prvotní instalaci doplňku se vytvoří obsadí pouze adresář odpovídajcíí jeho id (např. plugin.video.netflix) v adresáři <home>/addons, ale nevytvoří se jeho datová část v adresáři (pro uvedené id plugin.video.netflix) <home>/userdata/addon_data/plugin.video.netflix. Tento adresář se vytvoří a naplní (zpravidla) až při prvním spuštění doplňku nebo jeho nastavení. A plyne z toho analogická znalost, jako v případě Kodi samotného, a to, že:

2. Chceme-li existující doplněk dostat do stavu po jeho prvotní instalaci, postačí úplně (při zastaveném doplňku, nejde-li to, tak celého Kodi) smazat adresář <home>/userdata/addon_data/<addon id>, či alespoň jeho obsah. Pak stačí doplněk spustit a máme k dispozici prázdný a čistý doplněk, které si s sebou nenese žádnou zátěž způsobenou jeho předchozím používáním.

Co se týče bodu 2, tak ale existují výjimky. A jsou to výjimky, které souvisí s ne úplně standardním využíváním mechanismu Kodi a jeho doplňků, kdy některé doplňky mohou při své činnosti zapisovat data i mimo svou datovou část, ale dělají to i do datové části i jiných doplňků nebo dokonce do částí určené pro jejich kód. Příkladem jsou například různé helpery, které například zapisují soubory do adresáře s definičními xml soubory.

Je třeba také pamatovat na to, že:

3. Pokudu instalujeme Kodi nebo doplněk (platí to i pro přeinstalaci, a to i stejnou verzí), tak se příslušné adresáře (tedy <kodi> nebo <home>/addons/<addon id>) vymažou a nahradí se obsahem z instalace.

Stejně jako na to, že:

4. Pokud odinstalujete Kodi nebo addon a adresáře <home> nebo <home>/userdata/addon_data/<addon id> nejsou prázdné, vždy dostane dotaz, zda data Kodi nebo addon smazat také.

Co si z toho odnést? Například to, že se většinou nevyplácí přeinstalovávat Kodi nebo doplněk. Pokud máte podezření že je v datech doplpňku nějaký problém, tak vymažte pouze jeho datovou část. U vlastního Kodi je to podobné. Jste-li v situaci, kdy máte podezření, že je s Kodi generálně něco špatně, tak většinou stačí vymazat pouze <home> adresář.

Výjimky (u doplňků) existují. Velmi často mohou být problémy způsobeny nekonzistencí verzí závislostí, což je většinou důsledek nějakých nestandardních činností, nejčastěji jako následek používání neověřených zdrojů doplňků a jejich repozitářů, které mohou do Kodi zavléci doplňky (které jsou závislostmi), které mohou celkem spolehlivě rozbít ne příliš robustní (bohužel) "Kodi ekosystém". Někdy může být podobného stavu dosaženo i tím, že uživatelé používají nightly verze Kodi, výjimečně i jeho prerelease (zejména alpha) verze, ačkoliv pro to nemají dostatečné zkušenosti a vlastně ani důvody.

@JiRo: Dávám ti palec. Protože jsi ale nahoře uvedl "...Kodi i SCC a už mi to funguje,"
musím se zeptat k textu Co se týče bodu 2, tak ale existují výjimky... na toto:
Jak právě je to s doplňkem SCC - provádí zásahy i do jiných adresářů než podle svého vlastního id, nebo i pro SCC platí uvedené návody?

@meda Ne, SCC touto výjimkou není.

@JiRo: mas pravdu , ale na druhou stranu kolik si myslis ze useru se do boxu dostane ke slozce userdata, proto je pro mnoho uzivatelu jednodussi vse vymazat, preinstalovat , a ono staci bud tc nebo v androidu nejaky manager treba x-plore

@matchboxx Já si nic nemyslím, jen jsem popsal, jak to je, protože si myslím, že tohle o Kodi stále ještě většina lidí neví.

@matchboxx: Myslím si, že osvěta nikdy neuškodí. A protože @JiRo: to umí podat, jistě to pochopí i poučený laik.

osveta to kazdopadne, ale obavam se, ze tady si to stejne moc lidi neprecte , nebot je to zname jiz leta a stejne na to serou

Ono smutnejsie je, ze rovno napisu, "nefunguje mi prihlasovanie v kodi" a podobne, kde si myslia ze SCC je kodi...
Ono samotne SCC je naprd navrhnuté a porusuje standardy Kodi, a vdaka tomu plugin rozbija svoj subor s nastaveniami settings.xml... kde premaze prihlasovacie udaje...

(14.10.2022, 18:27)jastrab Napsal(a): Ono smutnejsie je, ze rovno napisu, "nefunguje mi prihlasovanie v kodi" a podobne, kde si myslia ze SCC je kodi...
Ono samotne SCC je naprd navrhnuté a porusuje standardy Kodi, a vdaka tomu plugin rozbija svoj subor s nastaveniami settings.xml... kde premaze prihlasovacie udaje...

zkus to navrthout sam

@jastrab: Nechci hodnotit, jestli je SCC napsané dobře nebo špatně, natolik tomu nerozumím. Nicméně tvrdím, že poškození settingu může být často způsobeno nevhodným zacházením při startu. Možná i v souvislosti se skinem nebo použitými addony.
Obsluhuju tři boxy cca rok, před tím maliny a nabouraný setting jsem zaregistroval jen jednou. A to ještě po výpadku napětí. Přisuzuju tomu i to nabourání.

Rozjela se debata, to jsem rád. A přinesla s sebou (možná) i další mýty.

SCC je naprd navrhnuté a porusuje standardy Kodi

@jastrab: Bylo by zajímavé vědět, do jaké míry názor, že "SCC je naprd navrhnuté a porusuje standardy Kodi", opíráš o vlastní zjištění a do jaké míry jen opakuješ to, co (a nejen tady) v průběhu času už tolikrát zaznělo (a často právě ode mne ). Jistě, SCC, resp. jeho autoři, se z dodržováním standardů Kodi potýkali často. Ale rozhodně bych to nehodnotil tak, že "SCC je naprd navrhnuté". Ekosystém Kodi a koncept jeho addons, včetně rozdělení na pluginy, service a další typy, má svá pravidla a vnitřní logiku. Problém je, že jednak není příliš detailně popsán, a také to, že byl navržen v době, kdy většina addons byla (asi tak 10x) jednodušší, než některé současné (k takovým bych zařadil i SCC). Autoři resp. autor @LáďaB: začínal vymýšlet SCC (to se ještě označovalo SC2) v době, kdy (podle jeho slov) Kodi prakticky neznal. Seznamoval se s ním tedy za pochodu. Byl jsem v té době jedním z kritiků a párkrát jsem s ním o tom i tady na fóru diskutoval. Dnes vidím, že jsem v některých chvílích příliš tlačil na pilu, neuvědomoval jsem si, že zatímco já se Kodi zabývám už více jak 13 roků, on s ním teprve začínal. Je možné, že to zpočátku byla tak trochu "válka", a já si zpětně uvědomuji, že jsem ze své "agresivity" měl ubrat. Zvláště, když bylo zřejmé, že druhá strana  na "bojišti" bere mé připomínky vážně, viz Náplast pro oči a.k.a. Verze 1.4.@JiRo(15).

No, abych to ale nějak produktivně a v duchu tohoto tématu zakončil tuto část. To, že "Kodi SCC je naprd navrhnuté a porusuje standardy Kodi" můžeme (dnes) už označit za mýtus. Když už, tak bychom mohli hovořit o tom, že SCC Kodi používá netradičním způsobem, a že to někdy může přinést problémy. Ale jak vidno z historie, jsou ty problémy řešeny. Možná ne vždy tak rychle, jak by si někteří přáli, ale nezapomínejme na to, že to autoři dělají ve svém volném čase a zadarmo.

Nicméně tvrdím, že poškození settingu...

@jkmh: Se settings byly v SCC problémy od začátku. Ještě v raných dobách takového charakteru, že to některé uživatele od SCC odrazovalo a někteří se dokonce vraceli k originálnímu SC. Myslím, že i autoři z toho měli těžkou hlavu. Ale byl to právě ten případ, o které jsme psal výše. Kodi ještě neznali tak dokonale, a tak stačilo jen nepatrné laické pošťouchnutí, a vyřešili to. Jestli tě to zajímá, tak se podívej na tento post od @LáďaB: a dva následující (ode mne a znova od Ládi).

Pak přišla doba, kdy se v SCC, z nějakého potřeby, začalo do settings zapisovat periodicky (A zatraceně často). Tam se začaly poprvé objevovat ty problémy s poškozením souboru settings. No, poškozením... Prostě se nepodařilo do souboru zapsat data a jeho velikost tak byla =0. Poté, co i tohle bylo opraveno, či spíše když se změnila koncepce spolupráce mezi plugin a service částí addon, tak se výskyt tohoto problému rapidně snížil.

Dnes je to tak, že k problému dochází, ale řekl bych, že jen velmi sporadicky a u zcela okrajového počtu uživatelů. Sám jsem na něj za celou dobu používání posledních verzí SCC narazil jen jednou, a to podobně jako ty, v případě "tvrdého" vypnutí napájení boxu. Vyřešil jsem si to okamžitě známým způsobem, kdy si settings, je-li v pořádku (existuje a jeho velikost není =0), při startu boxu a ještě před startem Kodi ukládám jako zálohu a když v pořádku není, tak si ho naopak z té zálohy obnovím. Zároveň si do dalšího souboru ukládám informaci o tom, že k obnově ze zálohy došlo. Mám to takto už více než rok a soubor do kterého si ukládám infomaci, že k obnově settings ze zálohy došlo, je stále prázdný.

Co se týče hodnocení toho, co za problémy "poškození" settings stojí, tak jsi, podle mne, na dobré cestě. Ano, celá ta doba po startu Kodi, kdy se incializuje samo Kodi, pak všechny service části addons a nakonec se prostřednictvím widgets spouští jednotky až nízké desítky instancí jednotlivých plugins, je značně obskurní. Nebudu zabíhat do detailů, ale dá se říci, že tam funguje něco, jako je "efekt motýlích křídel". Stačí jen nepatrná změna v nějakém addon, nastavení Kodi a hned se celé časování této iniciální fáze a posloupnost událostí změní, a vše najednou funguje jinak. Já jsem si tohle uvědomil už v době, kdy o SCC nebylo ani vidu ani slechu. A tak, abych eliminoval jednu kategoorii potenciálních zdrojů problému, tedy tu způsobenou spouštěním jednotek až desítek instancí plugins z widgets, tak jsem do vlastní modifikace skinu vložil to známé zpoždění. A už několikrát se ukázalo, že to velkou část, i později přicházejících problémů (včetně těch v SCC) dokázalo eliminovat.

A závěrem...

Já občas napíši nějaký addon a mám jich několik, které mají i service část. A dokonce i takové, kde mezi service a plugin nebo script částí probíhá intenzivní komunikace. Podobně jako SCC pro to používám socket-y, ale doplňuji to ještě technikou jednoduchých semaforů (používám pro to proměnné typu window porperty). Navíc každou service píši ve standardní struktuře, ve které mám takové funkce (s možností jejich jednoduchého nastavení), jako je zpoždění spuštění, přechod do sleep módu a další.
   
Současně s tím si jednotlivé fáze běhu service a důležité stavové informace ukládám do proměnných typu window properties, které si pak mohu celkem jednoduše zobrazit on-line např. ve stavovém řádku skinu. Pro ladění a sledování časově kritických souvislostí mezi různými service je to neocenitelné. Možná je tohle něco, co by autory (a nejen SCC) mohlo inspirovat.

Takže, abych i v této části dnešního nesmírně dlouhého postu zůstal věren tématu tohoto vlákna, tedy mýty a fakta, už jenom následující. Občasné nápady, jak vyřešit nějaký porblém, jsou-li spojeny práve s používání addons se service částmi, mohou být jen důsledkem souhry řady okolností. Nejsou to tedy mýty v pravém slova smyslu, ale mají stejné důsledky. Není to ve skutečnosti tak, jak se nám zdá. Získat ale fakta, je tomto případě poměrně složité, protože na to už jen laické znalosti nestačí. Tady už musí pomoci autoři. Ať už Kodi nebo addons. My jim ale můžeme docela účinně pomoci. Tím že nebudeme jen psát, že nám to nefunguje, ale že jim v první řadě poskytneme informace o tom, co se v našem Kodi děje. Pošleme log!

Videco cache, PVR & Live TV a adaptivní protokoly

Dost často si můžete přečíst: "Nainstaloval jsme si addon pro sledování OTT služby a nastavil video cache, a přesto se mi to seká...".

Video cache je nástroj, který umožňuje přednačítat data přehrávaná přehrávačem. Pro tuto chvíli přeskočím popis toho, jak a kde se video cache definuje, jaké má ta definice parametry, a naváži na to, co je uvedeno v nadpise. Tedy na to, že i když máte video cache nadefinovanou správně, při přehrávání videa z vaší videotéky nebo z video pluginu vám funguje podle očekávání, tak v některých případech tomu tak není. Ty případy totiž mohou být dva.

Video cache a PVR

Video cachce se nepoužívá v okamžiku, pokud je přehrávaný obsah v Kodi jako live stream zpracováván prostřednictvím PVR & Live TV. Je tedy zcela zbytečné, pokud například používáte addon pro přehrávání obsahu OTT služby Skylink, u které jsou problémy s plynulostí dodávky dat časté, myslet si, že to spravíte nastavením video cache. Ta při přehrávání tohoto (a podobného) obsahu zůstane nepoužita. Často, když to vysvětluji, dostávám otázku, proč tomu tak je. Vysvětlení je jednoduché. Je to principem funkce daného zdroje (v tomto případě tedy OTT služby). Principem funkce cache je načístat si data "dopředu", a to za předpokladu, že zdroj ta data dokáže poskytovat rychleji, než je to pro plynulé a nepřerušované přehrávání obsahu potřeba. A to OTT služba, která poskytuje data streamů vysílaných on-line poskytovateli TV obsahu, nedokáže.

Video cache a adapativní protokoly (HLS, MPEG-DASH)

Video cache se nepoužívá i v okamžiku, pokud je přehrávaný obsah definován a jeho načítání řízeno tzv. adaptivními protokoly. Momentálně se používají dva nejznámější, HLS a MPEG-DASH (což je občas zkracováno pouze na DASH). Protože jsou tyto protokoly často používány v případě live streamů, může to být často matoucí, proč se tedy u live streamu s protokolem HLS nebo MPEG-DASH nepoužívá video cache. Zda je to proto, že je to live stream a nebo kvůli tomu, že se používá adaptivní protokol. Je to z obou důvodů, přičemž pro to, aby Kodi nepoužilo video cache, stačí aby byl splněný jen jeden z nich. Jinými slovy, i když budete mít obsah definovaný např. pomocí MPEG-DASH protokolu a nebude to live stream, video cache se nepoužije.

(12.10.2022, 4:42)JiRo Napsal(a): @meda Ne, SCC touto výjimkou není.

@meda Možná, že jsem se v tomto bodě zmýlil. Ještě existují případy, kdy addon zapisují i mimo rámec svých dat. Buď explicitně, nebo s pomocí dalších funkcí a vazeb, včetně těch nativních. Tak například SCC zapisuje (buď explicitně nebo se tak děje prostřednitvím funkcí Kodi) informace o sledování titulu na dvě místa, prvním je video db Kodi, druhým databáze Trakt.

Napadlo mě to v souvislosti s posledními problémy addon SCC. Analýzou problému je zřejmé, že se problematické chování spustí poté, co historie počtu spuštěných titulů dosáhne nějaké hodnoty. Původně jsme si myslel, že by tedy problém moho být rychle (a dočasně) eliminován smazáním souboru data.db, který je uložen v datovém adresáři SCC. Neuvědomil jsem si ale, že spuštění přehrávání titulu se zanamenává i do databáze Kodi a případně i do databáze Trakt. Já jsem se bohužel s tímto problémem nesetkal, a tak jsem neměl možnost vyzkoušet, jak by Kodi, u kterého se ten problém objevil, reagoval například na dočastné odstranění video databáze nebo zrušení propojení SCC s Trakt. Kdyby byla možnost to vyzkoušet, tak by infromace o tom, čím se ta situace vedoucí k "recursion error", která vede někdy až k vyčerpání paměti, odstartuje.

@JiRo: V tom případě SCC používá 3 databáze. Trakt, jak píšeš ty, SCC db a v Kodi databázi Myvideos119.db. Přišel jsem na to, když jsem chtěl z SCC z Pokračovat ve sledování smazat nekompletní seriál. Seriál jsem musel najít a smazat v obou db. A trakt nepoužívám.

@jkmh Ano, je to tak. A pokud k tomu budeme ještě počítat backend, tak vlastně čtyři. Ale v databázi backendu nejsou data personalizovaná .

---

Také jsem s tím laboroval, abych pochopil jak to SCC dělá. A vlastně to bylo také ve chvíli, kdy jsem potřeboval zjistit jak funguje (či vlastně "nefunguje") Pokračovat ve sledování. Od té odby mám tuto položku v SCC skrytou. 

Ona by se hned ta databáze Kodi při pokusech mazat nemusela, možná by stačilo smazat jen pár záznamů obsahující id SCC aby se vidělo, že to na to má opravdu vliv.

@JiRo: OT: No, jestli nám všechna dosavadní poznání z K19 nové K20 poboří, tak bude opět zábava. 

(13.11.2022, 16:14)jkmh Napsal(a): V tom případě SCC používá 3 databáze. Trakt, jak píšeš ty, SCC db a v Kodi databázi Myvideos119.db. Přišel jsem na to, když jsem chtěl z SCC z Pokračovat ve sledování smazat nekompletní seriál. Seriál jsem musel najít a smazat v obou db. A trakt nepoužívám.

Prosím, kde se databáze nacházejí a jak v databázích najít a smazat např nějaký konkrétní seriál. Z SCC v Pokračovat ve sledování, bych rád odstranil nějaké seriály, které tam již nechci, ale nevím jak. Škoda, že není nabídka smazat v kontextovém menu.

@Jaffa Jedná se o databázi v souboru data.db v datovém adresáři addon SCC, tabulky watch_history* a pak ve video databázi Kodi, o které píše @jkmh, ta je uložena v userdata/Database, tam je to tuším tabulka files. Jestli ti tahle informace nestačí, tak se do toho raději nepouštěj.

Pokud ve video databázi nemáš jiná data než z SCC (tzn. nepoužíváš knihovnu Kodi), případně o ně můžeš přijít, možná by stačilo oba soubory při zastaveném Kodi smazat. Či spíše raději někam odložit nebo přejmenovat, abys měl zálohu. A ještě lépe, samozřejmě, před jakoukouliv nestandardní operací vyzálohovat raději celý Home adresář Kodi. Bude i pro ostatní dobré vědět, zda to pomůže.

Laborovat by se taky dalo s parametrem v nastavení SCC, na záložce Rozhraní, Počet položek na stránku. Pokud ho máš dostatečně vysoký (klidně tam dej 500), tak hned tak k problému nedojde. Ale jestli to funguje i zpětně, kdy už k problému došlo, to nevím, ověřit to nemám jak. Mně všechny Kodi i s SCC šlapu bez problémů. Pokud Kodi spadne hned po startu a nemůžeš tedy nastavení SCC ani spustit, tak je možné ten parametr ručně změnit v souboru settings.xml, opět při zastavemé Kodi (nebo stačí addon, pokud se ti to podaří). V souboru settings je ten parametr uložen jako index seznamu hodnot 20, 50, 100, 150, 200, 250, 500, tedy 0 pro 20 až 6 pro 500.

@Jaffa: K předchozímu ještě dodám, že v těch databázích nejsou uváděny názvy, ale je to řetězec znaků. Napřed musíš zjistit ten odpovídající názvu, pak v db najít řetězec, který je shodný alespoň prvními šesti znaky, lépe více. Viz Stream info na screenshotu.

@jkmh: @JiRo: Díky za info, bohužel ta databáze je řetězec znaků, ve kterých se absolutně nevyznám. SCC šlape bez problémů, jen v pokračovat ve sledování přibývají např filmy, které jsem jen zkusil, ale pak nekoukal nebo seriály, kde jsem třeba nesledoval všechny díly. A už je tam nepotřebuju vidět, ale smazat nelze. Dá se je označit jako zhlédnuté a pak tam již nejsou.