Hab das selber schon mal gehabt...du könntest einfach nach Updates suchen (wenn die Oberfläche das anbietet), dir danach direkt die Pi Hole Abfragen anschauen, vom Device. Da sollte man sicher fündig werden.
Alternative machste dir eine Gruppe ohne Adlisten und schmeißt die Shield dort rein, dauerhaft oder teporär - auch eine Möglichkeit.
Soweit mir bekannt liegen alle Downloads immer direkt unter einer nvidea.com url...
keine Frage, PL ist gut, im Angebot ja teilweise noch günstiger zu haben. Bei dem Preis und mit dem Hintergrund, das er eigentlich nur für das Amazon Universum gedacht ist, muss man halt Abstriche machen. Abseits von Android, F-TV, wirds dann auch schwierig mit Apps für Netflix, Prime und Co. Immer auch eine Sache der eigenen Gewohnheiten.
Ohne die Sache jetzt schlecht machen zu wollen (Kodi auf nem F-TV Stick den man eh rumliegen hat ist prinzipiell ja eine super Sache)...aber es gibt bessere Devices (RPI, Shield, etc.) Wird wohl kein vollwertiger CEC verbaut sein oder das angepasste Android verhindert das er in Kodi erkannt wird...
Es bleibt der Watch Dog, damit kann man es es auf jeden Fall so konfigurieren, das Kodi abschaltet/pausiert nach X Zeit inaktivität.
Hat sich denn hinsichtlich des Updates auf 9.1.2 (für 2019 Pro) bei jemandem schon etwas getan?
Ich benutze pihole und bin mir immer nicht sicher, ob die Updates evtl. geblockt werden.
Whiteliste die URL doch in PI-Hole einfach generell. Je nachdem welche Adliste(n) du nutzt (kann ja durchaus auch mal etwas fehlerhaft eingetragen sein) kann es durchaus passieren, das die URl geblockt wird (auch wenn das hier wohl nicht der Fall ist).
unter Einstellungen -> System -> Eingabe -> Peripheriegeräte -> CEC Adapter kannst du einstellen, was beim Ausschalten vom TV geschehen soll u.a ist "Kodi beenden" oder "Wiedergabe stoppen" möglich.
Optionen sind immer abhängig vom verwendeten CEC Adapter, ggf. nur dann vorhanden.
Mit Pure auf Auto, kannste erstmal nix falsch machen...
Vielleicht heißt es bei deinem Denon einfach anders, also nur DTS-HD, kann gut sein. Musst sonst mal ins Manual schauen. Virtual macht bei einem vorliegenden DTS oder Dolby Signal wenig Sinn, da würde ich immer die Original Tonspuren bevorzugen.
Die Punkte heißen; DTS Surround oder Dolby Audio - DD. Wenn die nicht da sind, kann es sein, das tatsächlich kein Signal ankommt am Receiver.
Wie Paust55 sagte sollte es mit pure auf Auto natürlich auch klappen...
Schau mal in KODi unter System Audio ob die Anzahl der Audiokanäle stimmt, Passthrougt eingeschalt und alle Punkte wie DTS fähiger Receiver etc. aktiviert sind. Ansonsten mal mit einem anderen Gerät, Blue Ray Player oder so gegentesten an welchem Gerät überhaupt das Problem vorliegt.
sCorporation Ich hab auch n Denon. Du hast schlicht den Sound Mode verstellt und zwar auf die Funktion DTS-HD Neural:X, das ist das Virtuelle System um 5.x, 7.x aus 2.0 zu erzeugen - kannste aber auch bei DTS/Dolby aktivieren. Start mal einen Film und dann drückst du Grün (zumindest bei mir so) unter Sound Mode auf der FB, dann stellst du das dort einfach wieder auf DTS / Dolby (Direct).
Viele Android "Hacks" sind mittlerweile aus Kodi verschwunden. Mit Kodi 21 gab es auch diverse Änderungen in Richtung Decodierung/Player, auch die Android API's spielen dabei ein Rolle. Kann also schon sein, das dein Gerät das einfach nicht (mehr) packt. Was mir persönlich aufgefallen ist, das Kodi 21 etwas mehr Ressourcen (wenn auch nicht viel) benötigt als die 20er Version. Soweit ich das sehe, ist dein TV aus 2017, dementsprechend ist die Hardware auch nicht mehr die performanteste. Ich denke, mit ein paar Einstellungen wirst du das nicht in den Griff bekommen. Downgrade wäre eine Möglichkeit.
Wenn es keine Lösung für mein Problem geben sollte, würde dann die Möglichkeit bestehen, wieder zu Kodi 20 zurückzugehen? Da hat, wie gesagt, alles wunderbar funktioniert...
Klar, einfach die 21er deinstallieren (Userdata Ordner vorher sichern) und wieder die 20er drauf (+ggf. Userdata, falls gelöscht wieder kopieren um die alten Settings zu übernehmen (Textures13 aber löschen)). Ein Downgrade der Datenbank ist nicht möglich. Einfachster Weg aus der 21er die .nfo exportieren (falls nicht schon vorhanden) und dann die DB der 20er damit wieder neu aufbauen (falls die alte nicht sogar mit etwas Glück noch vorhanden ist).
Ok...ich werden die DB neu aufsetzen, finde nach meinem amateurhaften Eingreifen in die ausgelagerte DB immer mehr Ungereimtheiten wenn ich mir die Kodi DB genau angucke
"Überraschung".. Sorry, musste sein 
Jepp, DB, Thumbnails, Textures13.db bereinigen und sauber starten, das wird langfristig das Beste sein.
Textures13.db und und Thumbnails Ordner vorher löschen. Könnte man auch im nachhinein machen, da die Thumbs auch dann neu erstellt würden.
Falls du nicht weißt, wo die sich versteckt: https://kodi.wiki/view/Userdata
Ein RasPi 4 oder 5 (die deutlich langsamer sind) verbrauchen mit demselben Messgerät gemessen deutlich mehr Strom (so 5-6 Watt, also etwa das Doppelte an Stromverbrauch bei etwa halber Geschwindigkeit).
...unter Last 5 ohne pendelt sich das dann bei ca. 3.5 Watt ein (RPI5) zumindest das, was mein Messgerät meint.
Hatte vorher einen Nuc, der lag bei 4.
Ich hatte ursprünglich vor, die Maria DB auf meiner QNap als Docker laufen zu lassen, was aber dazu geführt hat, das die Nas nicht mehr in den Standby ging (sobald ein Docker lief). Bei 4 Platten die 24/7 laufen kommt dann schon einiges an Strom zusammen. Ob das bei den Synos auch so ist, k.a. Ich denke, man muss immer etwas schauen, das man einen Kompromiss aus Leistung/Stromverbrauch findet. Des weiteren ist es mühsam z.B. einen RPI einzusetzen wenn man 0 Linux Vorkenntnis hat, da sollte man dann auch schauen, das man mit einem System unterwegs ist, welches man bedienen kann.
Nehmen wir mal an einige Datensätze sind in der Tat iwie zerschossen in der zentralen DB und ich will den gesehen Status haben, dann ist das doch eher keine gute Idee die DB per Kodi zu exportieren und den Status in die nfo's zu schreiben oder?
Jupp, eine SQL Sicherung umfasst natürlich vollumfänglich die komlette DB, deswegen mein Ansatz über die DB zu gehen. Das war und wird aber immer so ein Ding sein, das es einfach verschiedenen Meinungen dazu gibt, halt stark vom Nutzerverhalten abhängig. Deswegen sag ich ja: Man muss schauen, wie es auf die individuellen Bedürfnisse am besten passt, kein Grund deswegen zu streiten 
Ist doch gut, das jeder das so handhaben kann wie es am besten passt. Wo soll jetzt das Problem sein, auf eine reine DB zu setzen (mit entsprechenden Sicherungen natürlich) anstatt auf .nfo's, wenn die Vorteile der .nfo's für einen einfach nicht relevant sind... Warum man da jetzt so einen Unterton einbringen muss verstehe ich nicht 
Oh böser Fehler, wenn es die DB mal zerhaut, und die Mega-Sammlung neu angepasst werden muss...
Ne ne, siehe Beitrag drüber Wenn die DB komplett im Eimer ist, ich das nicht merke, hast du recht. Von zeit zu Zeit mach ich mal einen export der DB aus Kodi, darüber bekomme ich zur Not, wenn auch mit etwas Datenverlust alles wieder rein...
Ist klar, geb ich Dir recht, gerade bei eigenen "Content" führt an den .nfo's auch eigentlich nichts vorbei. Ich sichere die SQL DB, Thumbs täglich per Cron auf eine Nas. Des Weiteren wird vom RPI mittels DD Befehl ein komplettes Image des RPI per Cron (alle 7 Tage) erstellt. Der Weg über .nfo's ist völlig OK und auch gut, da es quasi meine Backup Strategie ersetzt.
Worst Case 4 me: SD Karte vom RPI defekt, alles weg... Neue Karte in einen USB Leser/Schreiber, Image drauf, maximal noch die SQL Sicherung vom Vortag einspielen im Nachgang und alles in ein paar Minuten wieder auf Stand. Es kommt bei Kodi einfach stark auf die eingesetzten Systeme an, da muss jeder kucken wie es am besten auf die eigenen Bedürfnisse passt.
Ich hab son ollen MI TV von Xiaomi. Günstig gewesen, gutes Bild aber furchtbares Teil was die SW betrifft (Android, herstellerangepasst) - da geht sowas auch nicht, alles schon versucht. Aufgegeben, RPI dran gut war. Ist son bisschen Off Topic aber bin an dem Punkt, das ein TV besser ein dummes Anzeigegerät bleiben sollte wo man schlussendlich dann dran hängt was für einen am besten passt.
Wie, hab drei Clients, mache das ja damit alles synchronisiert ist...versteh ich jetzt nicht.
Sorry, hab mich da etwas unklar ausgedrückt. Sparen nicht. Ich hab einen komplett anderen Ansatz (ist immer son bisschen einen Glaubensfrage). Für mich macht eine gemeinsame DB einfach mehr Sinn, wenn ich alles zentralisiere, jeden Client. Ich arbeite komplett ohne .nfo alles steht in der DB, die Daten liefern die Scraper. D.H. habe alle Clients an die DB angebunden, die Thumbs liegen ebenfalls zentral, das ganze liegt alles auf nem RPI da easy zu sichern per Cron Job. Der Weg funktioniert nicht für jeden, gerade wenn/falls man eigene Daten (Homevideos o.ä.) nutzt, man individualisieren will, kein Scraper liefert, schwierig.
Der Lapi-Client mit dem die NFO erzeugt wird hängt nicht an der DB, schon klar dass das dann unsinn ist
OK 
Alle Filme sind local, actor ist URL von TMDB
das sieht gut aus. Ich gehe mal davon aus, dass die IP eine feste ist und dein Nas, welches auch immer online ist... Sollte passen.
Schwierig, ich würde nun tatsächlich auch nach dem Ausschlussverfahren weiter machen. Siehe:
Installier dir ein Kodi auf dem PC (geht auch als portable 2.Version) mit lokaler Datenbank und schau wie gut das funktioniert. Erstmal nur Filme.
Ohne irgendetwas zu verstellen scroll mal durch deine Bibliothek. Im Normalfall findet Kodi sämtliche Artwork und infos ohne lange Wartezeit.
Sollte das funktionieren kannste ja die selbe Installation nutzen und die Datenbank auslagern und wieder testen. Im anschluss die Artwork auslagern und testen.
Das am besten mit eingeschaltetem debug.log
locha hast du eventuell einen eigenen DNS wie z.B PI-Hole am laufen? Solche Problemen können auch aus der Ecke kommen...
Des Weiteren könntest du mal in die Tabelle "Art" schauen dort die Spalte URL, das ist die Quelle der Artworks die beim Scrapen oder durch einspielen der Daten durch ein Backup hinterlegt wird. Worauf kucken die? Vergleich mal 2 Stellig mit einer 4 Stelligen... Vorstellen könnte ich mir das die 2 Stelligen IDs auf lokale Pfade schauen, die neueren 4 Stelligen auf andere Quellen, vielleicht ist da was vermurks und der Zugriff klappt dort dann nicht richtig, deswegen diese Verzögerung.
Grundsätzlich würde ich drüber nachdenken, das anders zu handhaben und alles Neu zu machen. Das mit den .nfo kann man so machen aber da kannste Dir die DB sparen, da alles ja lokal alles liegt, was in der Regel auch fix läuft.
Wenn DB dann alle Clients daran koppeln und nicht mit einem Client die .nfo erzeugen, die wieder einlesen, das macht wenig Sinn.
Ein guter Weg wäre alle Clients an die SQL DB zu koppeln, den Thumb Cache (z.B auf die Nas auszulagern). Das hätte den Vorteil, das du mit deinem Notebook 1x Scrapst, die Daten direkt in der DB landen und das Artwork auch bereits für alle Client bereitgestellt ist, nur abgerufen werden muss. Nachteil ist natürlich, das die Clients immer on the fly das Artwork über das Netzwerk abrufen, was bei langsamen Verbindungen dann ebenfalls verzögern kann.
ich denke, es ging (so habe ich das verstanden) um das erstmalige hinzufügen neuer Einträge auf den Clients (durch die relative langsame Hardware bedingt (Vermutung) dauerte dies länger). Er hat dann die IDs händisch in der DB verändert 4Stellig auf 2 Stellig (was aber bei neunen Einträgen keinen Unterschied gemacht hätte) da er dachte, das dort die Ursache liegt. Die Einträge waren in Wirklichkeit einfach schneller, da die Einträge "Altbestand", bereits lokal gecached, also vorhanden waren auf den Clients, nur ein update erfolgte (was immer fixer geht als Neue). Art hat er danach manuell "gescrapt" da dort die Zuordnung nicht mehr passte.
Ich denke die DB nun 1x neu aufzusetzen wird das Beste sein, die dürfte nun bereits inkonsestent sein und spätestens bei der nächsten Migration der Video DB auf die Nase fallen.
