[JiRo]

@matata: Tak jsem si doplněk na testovací Kodi nainstaloval a vyzkoušel. Nijak podrobně jsem ho ale nestudoval, a to ze dvou důvodů. Jednak na to nemám čas a jednak jsem se nechtěl nechat ovlivnit, protože v podstatě podobnou sadu funkcí a zdrojů si vytvářím a používám taky, jen to mám pojaté trochu jinak. Nejde o kritiku, mně se doplněk jinak líbí, ale věřím, že když se zmíním o několika zásadách a charakteristikách mého řešení, tak to může spustit nějakou produktivní diskusi.
   
Já se v mých řešeních snažím psát doplňky do Kodi tak, abych maximálně využili jeho nativních funkcí. Pro to je třeba Kodi znát, a to je často kámen úrazu. Bylo to vidět třeba např. na doplňku Stream Cinema Community (SCC), kde jeho hlavní autor je sice excelentní programátor, ale Kodi zpočátku moc neznal, a tak plno věcí v začátku SCC pěkně skřípalo. A i když se je podařilo nakonec uhladit, bylo tam plno zásadně špatných rozhodnutí v basic designu, které jeho funkce neativně ovlivňovaly až do konce. Typicky např. v tom, že položky nabízených titulů měly dva příznaky shlédnuto. Jeden shlédnuto v Kodi a druhý shlédnuto v Trakt.

• je to vidět i tady, kdy si autor do doplňku zapracoval vlastní databázi ukládání stavů rozkoukáno/shlédnuto, ačkoliv mohl klidně využít to, co nabízí Kodi a nechat tu práci na něm. Kodi to stejně dělá, tak proč toho nevyužít bezezbytku místo vytvářené další databáze. Já v mém řešení používám pro stav shlédnuto zásadně pouze mechanismy Kodi (funkce, databáze, přístupy).
  
• podobné to asi bude i u Trakt, i když to jsem nijak zkoumat nemohl. Nevím, jak ten funguje, ale pokud by to bylo nějak tak, jako to bylo u již zmíněného SCC, může to vést k dalším zbytečným funkční duplicitám. Já jsem se tohle snažil vyřešit také globálně pro celé Kodi. Trakt už sice nepoužívám, přešel jsme na Histra, ale zase jen tak, že existuje jeden společný doplněk, který řeší synchornizaci mezi Kodi a jeho databází (a tedy i doplňků) a Histra databází.
  
• a (snad zatím ) poslední poznámka se týká rychlosti vyhledávání streamů. Nezkoumal jsem kód, ale z toho, jak se vyhledávání chová a hlavně, jak dlouho trvá, než se zobrazí jeho výsledek, bude pravděpodobně pro realizaci paralelního běhu pro jednotlivé prohledávané zdroje, použit threading. Pokud se mýlím, tak se omlouvám. To pro takovou úlohu ale ideální není. Lépe by bylo použít něco, u čeho by čekání na odpovědi neblokovalo ostatní vlákna. Co třeba použít asyncio. Zatímco teď je celková doba vyhledání dána (+/-) součtem doby hledání ve všech vláknech, při použití asyncia by se přiblížila době hledání v tom nejpomalejším. Vycházím při tom z obecného předpokladu, že dobu hledání nejvíce ovlivňuje doba čekání na odpověď z externího zdroje.