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.
Ich kann Dir nur den Tipp geben: Wenn du nicht 100% weißt, was du in der DB machst, lass die Finger davon.. Da macht man schneller was kaputt als man denkt.
Die Datenbank von Kodi ist alles andere als trivial, hat sehr viele Abhängigkeiten der Tabellen untereinander, die nicht immer ersichtlich sind da innerhalb der Tabellen ab und an die ID gewechselt oder wie bei den Thumbs sogar Quersummen aus den Links gebildet werden um diese dann dem Thumbcache zu zuordnen. Ich bin hier im Forum selten aktiv aber schon seit XBMC Zeiten dabei, ich hab den gleichen Mist vor Jahren genauso blauäugig versucht - ist nie gut gegangen
Weiß wer ne gute Quelle, vorzugsweise deutsch, wo ich mich über MariaDB/phpMyAdmin oder Grundlegend über Datenbanken informieren kann?
Schau am besten mal bei YT da findet man genügend Anfänger Tutorials, die auch die Grundlagen erklären. Fachliteratur dürfte an der Stelle den Rahmen sprengen.
Das kann alles ausgeschlossen werden, hier läuft schon alles und muss nicht anlaufen...
Wie gesagt das Cover von Film 1 ist ja ruck zu da, nur wenn neben Film 1 ein Film mit einer 4-stelligen ID ist, dann merkt bzw. sieht man die Wartezeit. Ändere ich die ID von 4-stellig auf 2-stellig geht es auch ruck zuck. Ich hab von der Thematik auch keine Ahnung, deswegen frage ich ja hier, aber trotzdem kann mir bis jetzt keiner so richtig erklären wieso das so wie ich es mache funktioniert…
Habe immer nach Änderungen sporadisch Filme aus der DB abgerufen, hat sowei alles funktioniert. Musste nur bei den geänderten Filmen die Arts neu einlesen per Information->Grafik auswählen usw.
locha du hast schon eine Erklärung bekommen:
Du hast das Prinzip, wie das Ganze funktioniert, einfach nicht verstanden. Beim ersten Mal -> lahm bis extrem lahm, ab dem zweiten Mal blitzschnell. Daran ändert das manuelle Herumpfuschen in der DB absolut gar nichts. Falls das doch einen Einfluss haben sollte, dann nur, weil du die DB geschrottet hast und nix mehr geht.
Stimm Dir 100% zu Lehmden1.
Ja, wird ein Film gelöscht wird die ID frei, hab mir notiert welche IDs frei sind und diese neu belegt. Hab bis jetzt nichts negatives festgestellt, noch nicht....
Ist nicht richtig. Die kompletten Einträge bleiben in der DB. Lösch mal einen und füg den wieder hinzu... Da wirst du bemerken, das der noch nicht einmal als "neu hinzugefügt" angezeigt wird, da die kompletten "alten" DB Einträge weiter vorhanden bleiben. Der Eintrag wird lediglich aus einer Tabelle entfernt, die quasi den "View" steuert. Warum ist das jetzt "schneller"? Ganz einfach: Der Eintrag wird nicht zum ersten mal eigelesen, ist bereits in den lokalen Caches der Clients vorhanden.
Nimms mir nicht übel locha, ist ja deine DB aber dran rumzufummeln, obwohl man keine Ahnung hat, wie das eigentlich funktioniert, welcher Abhängigkeiten innerhalb der Tabellen vorhanden sind, das kann nur schief gehen. Du lieferst ja gerade selber das Beispiel:
Habe immer nach Änderungen sporadisch Filme aus der DB abgerufen, hat sowei alles funktioniert. Musste nur bei den geänderten Filmen die Arts neu einlesen per Information->Grafik auswählen usw.
Was meinste warum du das machen musstest? ...dort fehlt jetzt die Zuordnung der Art Tabelle und das ist nur eine von diversen Tabellenzuordnungen, die nicht mehr passen. Dafür hat jetzt wahrscheinlich irgendein anderer Eintrag diese Daten und es werden die falschen Infos angezeigt. Du schrottest Dir damit schlicht die DB, da du das Grundprinzip (noch) nicht verstanden hast.
Das ganze findest du im Wiki: Klick
Vielleicht noch ein ein Hinweis: Spätestens wenn ein Change der Video DB ansteht von Kodi 21 (Video132) auf Video132 oder was auch immer es wird, wird dir die Migration um die Ohren fliegen, da die SQL's auf die Nase fallen. Wenn du eine DB Sicherung der SQL hast würde ich dir raten, diese wieder einzuspielen.
locha Interessant zu wissen wäre, ob du mittels pathsubstitution die Thumbnails in der advancedsettings
ausgelagert hast (auf die Nas)? Wenn du das getan hast, kann es durchaus zu längeren Wartezeiten, wie beschrieben kommen.
Wenn nicht, sollten die Cover nach dem ersten Laden (lokal) gecached, sofort verfügbar sein.
Also der Punkt mit den Ladezeiten der Cover/Fanart von teilweise 15s bei neu hinzugefügten Filme nervt mich total
Hab jetzt mal zum Test händisch bei ein paar Filme die idMovie so angepasst, dass diese näher an der alphabetischen Sortierung liegt und siehe da, viel viel besser und "gleichmässiger" Aufbau der Arts.
Es macht doch viel mehr Sinn, dass die Datenbank von Kodi, welche alphabetisch sortiert ist auch in dieser Reihenfolge aufgebaut/abgerufen wird und nicht nach der Abhängigkeit der idMovie.
Bin ich den der Einzige den das stört
oder habt ihr das Problem bei ausgelagerter Kodi DB und neu hinzugefügten Inhalten (Filmen) nicht?
Du hast ja oben schon erwähnt, das du nicht sonderlich viel Ahnung von Datenbanken hast, das merk man an dieser Äußerung auch ganz gut
Also der Punkt mit den Ladezeiten der Cover/Fanart von teilweise 15s bei neu hinzugefügten Filme nervt mich total 
-> Wenn keine ausgelagerten gemeinsamen Thumbs, werden diese beim ersten Laden über den vom Scraper gelieferten Link (das kann eine URL im www oder auch ein lokaler Link (z.B auf der Nas) sein)) bezogen, lokal (auf dem jeweiligen Client) gecached. Das kann nun sein, das die Quelle einfach nicht so schnell liefert... Evtl. muss dein Nas auch erst aus dem Standby anlaufen, bis die SQL DB oder SMB Daten liefern kann. Die Synology DS 220j ist extrem schwach, klar läuft da Maria, MySQL drauf aber das ist einfach keine Rakete. Denk vielleicht einfach drüber nach die Nas nur als Medienquelle zu nutzen, überlasse den Rest Geräten, die das besser können. Ich hab die SQL DB, Thumbs z.B auf nem RPI5 ausgelagert (braucht einfach nicht viel Strom im 24/7 Betrieb). Obwohl die Daten nur auf einer SD Karte liegen, die Cover on the fly von den Clients (teilwiese über WLAN) abgerufen werden, sind die direkt da. Das gleiche Konstrukt hatte ich vorher auf einer relative performanten QNAP NAS laufen, das lief ähnlich langsam wie bei Dir.
Hab jetzt mal zum Test händisch bei ein paar Filme die idMovie so angepasst, dass diese näher an der alphabetischen Sortierung liegt und siehe da, viel viel besser und "gleichmässiger" Aufbau der Arts.
-> kein guter Einfall. Die ID's werden nicht grundlos einmalig, aufsteigend in die DB geschrieben - die werden in diversen anderen Tabellen genutzt. Wenn du die nun händisch in einer anpasst, wird es an anderen Stellen zu Konflikten, Zuordnungsfehlern kommen. Schneller ist das jetzt (vermutlich) nur, da er die Hälfte seiner Tabellen nicht mehr findet und die hälfte der SQL-Abfrage sofort mit "Error" auf die Nase fällt.
Es macht doch viel mehr Sinn, dass die Datenbank von Kodi, welche alphabetisch sortiert ist auch in dieser Reihenfolge aufgebaut/abgerufen wird und nicht nach der Abhängigkeit der idMovie.
-> So funktionieren Datenbanken einfach nicht. Siehe dazu auch Lehmden1 "Bei einer Datenbank wird mit Abfragen (Englisch "Query", das Q in MySQL) gearbeitet". Was du mal schauen könntest, in PHPmyadmin:
für 500 Datensätze benötigt meine DB das (damit du ein feeling für die Abfragezeiten bekommst)... Wenn hier bei Dir nun 10 Sekunden steht, passt definitive was nicht
Android ist nicht gleich Android. Die Hersteller passen das Android auf Ihre Bedürfnisse an... Gerade auf Geräten wie TV's, Media Player, sind das dann die Typischen Probleme. Die Shield, das ist immer eine gute Wahl gewesen als Android Player, viele anderen Geräte sind leider reines Glücksspiel.
