[matata]

Díky za zpětnou vazbu. Vezmu to po bodech.
 
Vlastní evidence zhlédnuto / rozkoukáno. Máš pravdu, že Kodi si u položek z pluginu vede playcount i resume samo a Nokturno mu ho při výpisu přepisuje ze svého souboru. Ta duplicita tam je. Důvod není neznalost Kodi, ale dvě věci, které jsem s jeho databází nedokázal pokrýt:

1. Kodi klíčuje stav přesnou cestou položky. Nokturno ale nemá jednu cestu na titul: stejný film se dá otevřít z hledání, z katalogu, z widgetu, s vynuceným výběrem streamu nebo s alternativním párováním, a každá varianta má jiné parametry v URL. Chtěl jsem stav vázaný na titul (IMDb/TMDB id), ne na cestu, ať rozkoukanost nebloudí.
   
2. Nokturno není jen doplněk do Kodi. Stejná knihovna běží v integraci pro Home Assistant a v doplňku pro Stremio, a víc Kodi v domácnosti si přes HA stav synchronizuje. Ten společný stav musí ležet mimo Kodi databázi.
   

Co si z tvé poznámky beru: doplněk by měl stav zapisovat i do Kodi, ne ho jen přebíjet. Tedy po skončení přehrávání nastavit playcount a resume i na cestu položky přes Kodi API, aby fungovaly skinové funkce („Označit jako zhlédnuté", filtry nezhlédnutého) a hlavně doplňky třetích stran, které sedí nad Kodi databází. Dnes tam je i reálná chyba: když někdo označí titul jako zhlédnutý z kontextového menu skinu, Nokturno mu to při dalším výpisu vrátí zpátky. Jde do nejbližší verze.
Trakt. Tady trefa úplně. Nokturno má vlastní vazbu na Trakt (scrobble ze služby, označení zhlédnuto z menu), navázanou na svou evidenci, ne na Kodi. Tvůj přístup s jedním společným synchronizačním doplňkem pro celé Kodi je čistší. Pokud se povede bod výš, tj. Nokturno bude poctivě plnit Kodi databázi, může moje vlastní Trakt vazba časem odpadnout a nechat to na script.trakt nebo na Histra doplňku. Ten neznám, můžeš prosím poslat odkaz, případně napsat, jak ho máš zapojený?
Rychlost hledání. Tady musím uctivě oponovat. Hledání běží pro každý zdroj v samostatném vlákně (ThreadPoolExecutor, jedno vlákno na zdroj, vlastní úložiště souběžně vedle nich). Vlákno čekající na síťovou odpověď v Pythonu GIL pustí, takže celková doba už dnes odpovídá zhruba nejpomalejšímu zdroji, ne součtu. Asyncio by tu u čistě síťového čekání nic nezrychlilo, a v Kodi navíc není žádný asynchronní HTTP klient, jen blokující urllib, takže by stejně muselo běžet nad vlákny.
Tvoje pozorování, že to trvá dlouho, ale sedí. Příčina je jinde a dík za připomenutí, ať se na to podívám:

• Uvnitř jednoho zdroje se dotazy točí sériově (několik variant názvu za sebou), ty jdou paralelizovat.
  
• Titulky z WebShare se hledají až po streamech jako další dotaz, můžou jít souběžně.
  
• Největší brzda je fáze „Meta: x/y" v ukazateli: doplněk čte hlavičky nalezených souborů (zvukové stopy, rozlišení), aby uměl seřadit streamy podle jazyka a kvality. Osm souběžně, u třiceti streamů jsou to čtyři kola. Řešení je číst hlavičky jen u prvních N po předběžném seřazení, nebo líně až v dialogu výběru.
  

Tvé řešení bych rád viděl, byť jen popis přístupu. Kde se s Kodi kamarádíš nativně a kde ne, to je přesně ta zkušenost, která mi chybí.