phpMyAdmin & Kodi Datenbank

Zitat von buers

bei gescratchten Filmen

Da muss ich mich schon am Kopf kratzen, um mir zu überlegen

Zitat von locha

was bedeutet das?

... Ich hatte mich veschrieben, meinte "gescrapten" (oder wie auch immer man das hier am besten schreibt - ein deutsches Wort kenne ich nicht). Scrapers - Official Kodi Wiki.

Kommt mir schon bisschen suspekt vor. Hört sich bisschen an, als würde was (der Client oder die DB-Engine) einen "full table scan" machen, um einen Eintrag zu finden, anstatt über Index zugreifen. Paar Hinweise, wo man anfangen könnte, da Bottleneck zu identifizieren, hatte ich gegeben.

Zusätzlich: Wenn man bei Kodi die Komponentenspezifische Protokollierung aktiviert - dort gibt es den Punkt "Ausführliche Protokollierung der Datenbank Komponente". Habe jetzt allerdings nicht geprüft, ob das ggf. nur interne DB und nicht externe (wie bei dir) betrifft.

Ansonsten würde ich - gerade nachdem du die DB manuell verändert hast - mit neuer DB anfangen. (Nicht das da wirklich ein Index ein Knacks hat, und deswegen ein Full table scan gemacht wird). Und dann die Finger von der DB lassen.

Du hattest geantwortet, dass Thumbnails lokal auf den CLienten liegt, und dass das Anzeigen der Cover bei neu hinzugefügten Filmen (mit hoher ID) verlangsamt ist, auf allen Clients. Nur beim ersten Zugriff pro Client, oder immer? Ich habe verstanden - immer. (Weil ich manche Erklärungen hier so sehe, die eben gerade diese Beobachtung nicht berücksichtigen würden - wenn es nur bei ersten Mal ist, sähe ich das nicht als Problem an ...).

Benutzt du ganz normal einen Scraper, oder lokale Artworks/Grafiken die im Filesystem liegen (evt. über Media Manager / nfo Files)?

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.

Zitat von locha

Ich habe dieses Jahr bestimmt schon 5x die Quellen neu einlesen müssen

Wieso? Zu viel mit der Datenbank gespielt?

Zitat von locha

dauert immer 2 Tage bis ich mit allem fertig bin und es so ist wie ich will

Wieso, wenn ich local infos habe ist es gleich so wie ich es möchte.

Jedenfalls weisen die 2 Tage meines Erachtens darauf hin, dass da was im Argen liegt. Ob jetzt externe DB oder interne - das sollte normalerweise nicht das limitierende Element sein beim Scrapen (auch nicht bei lokalen Infos). Ich habe über 5000 Filme, bei "echtem" Scrapen (was viel langsamer sein sollte) dauert bei mir das Aufsetzen eines neuen Clients (mit lokaler DB) einige Stunden (wenig abhängig davon, ob jetzt lahmer Android Stick oder sehr schneller Windows PC). Mache ich halt über Nacht. (Gesehen Status ist mir zugegebenermaßen wurscht - ist mir aber schon klar, dass das für viele wichtig ist)

Mit local info only / local artworks habe ich leider keine Vergleichsmöglichkeit. Da halte ich mich jetzt auch zurück. Deine Beobachtungen legen nahe, dass da was nicht stimmt. Beobachtungen von mir und anderen, dass es bei uns alles toll ist, hilft da halt nicht weiter ...

Zitat von locha

dauert immer 2 Tage bis ich mit allem fertig bin

Da stimmt dann auch was Generelles nicht. Bei meiner (wohl viel größeren) Bibliothek dauert es keine 2 Stunden, bis alle 50.000++ Videos (Filme, Serien-Episoden und nicht kategorisierte Videos) wieder perfekt in der Datenbank sind, incl. dem Zurückspeichern der Gesehen Zustände mit WatchedList.

Zitat von locha

das "Problem" ist nur bei den Filme so, Serien fällt mir das nicht auf, hab auch nicht so viele im Vergleich zu Filmen, Verhältnis 10 zu 1 (Filme zu Serien). Und was mir auch noch aufgefalle ist, Filme von Filmreihen sehe ich auch kein Problem,

Auch das ist ein untrügliches Zeichen dafür, das etwas Grobes nicht stimmt. Denn für die Datenbank sind Serien- Episoden und Movieset Filme exakt dasselbe wie Filme, die zu keinem Set gehören. Dein Problem liegt 100% sicher nicht prinzipiell an der Datenbank. Deine DB ist allerdings mit großer Wahrscheinlichkeit durch deine manuellen Eingriffe trotzdem korrupt.

Aber wenn der Neuaufbau trotz lokaler Grafik und .nfo so elendiglich lange dauert, dann ist gar nichts in Ordnung und du musst zuerst mal den Grund für das langsame Einlesen aufspüren. Dauert es auch 2 Tage, wenn du eine lokale SQLite Datenbank nutzt, also keine zentrale DB in der advancedsettings.xml angibst? Lässt sich ja einfach testen, in dem man die AS an die Seite kopiert und dann Kodi ohne AS startet und die Filme neu einlesen lässt. Wenn es mit lokaler DB normal schnell ist, dann klemmt die Verbindung zur MariaDB oder dein NAS ist tatsächlich rettungslos überfordert. Falls auch das so lange dauert, muss man weiter sehen.

Wie erstellst du denn deine nfos? Ich nutze EMM, der holt auch den gesehen Status von Kodi und schreibt ihn in die nfos!

DB seperat exportieren ohne Artwork und alte Dateien überschreiben wäre eine gute Möglichkeit um die nfos mit gesehen Status zu haben. Artwork hast du ja selber.
Nfo Dateien sollten auch stimmen, da sie ja vorher richtig in der Datenbank waren.

Ist die Artwork richtig benannt hatte ich noch nie Probleme das Kodi sie nicht findet. Format jpg/png sollte stimmen.

Zitat von Lehmden1

Da stimmt dann auch was Generelles nicht. Bei meiner (wohl viel größeren) Bibliothek dauert es keine 2 Stunden, bis alle 50.000++ Videos (Filme, Serien-Episoden und nicht kategorisierte Videos) wieder perfekt in der Datenbank sind, incl. dem Zurückspeichern der Gesehen Zustände mit WatchedList.

War auch so mein Gedanke!

Ich nutz zum erstellen der Datenbank den Lappi, ist ein wenig schneller wie mit nem Stick oder Box, aber dennoch sind 2 Tage verdammt viel!

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

Ich versteh jetzt dein Vorgehen nicht?
Dein Kodi auf dem Lappi hat eine lokale DB oder die selbe wie deine Clients?
Sollte dein Lappi die selbe DB nutzen (mach ich so) brauchen deine Clients keine nfos!
Hat dein Lappi eine eigene DB musst du nur bei einem Client die NAS-DB aktualisieren.

Wenn du mit dem Lappi scrapst hast du doch deine Artwork nicht lokal im Filmordner!? Und jeder Client muss sich die Artwork selber holen und da passiert es vlt mal das ein anderes Bild genutzt wir.

Zitat von locha

Aber eins versteh ich nicht. Was meinst du mit

Im Falle du lagerst deine Thumbnails aus, aber das machst du ja nicht.

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.

Zitat von derMaik

Wie erstellst du denn deine nfos? Ich nutze EMM, der holt auch den gesehen Status von Kodi und schreibt ihn in die nfos!

Falls ich gemeint war, mit Media-Buddy, den ich selbst geschrieben habe. Ich mag sowas wie Gesehen Zustände nicht in den .nfo. Die Metadaten (Titel, Beschreibung, Rating,....) sind konstant. Dann ständig die .nfo neu zu bauen nur für den Gesehen Zustand widerstrebt mir gewaltig.

Der Media- Manger (tmm, EMM, MediaElch, Media-Buddy,...) hat in der eigentlichen Bibliothek rein gar nichts zu suchen. Filme und Serien arbeitet man in einem Arbeitsorder auf. Geht dann was schief, betrifft es nur die paar neuen Dateien, nicht die ganze Bibliothek. Nicht, das es einem so geht wie mir damals beim Ausprobieren von Emby. Ein Häckchen vergessen zu löschen (oder setzen, ich weiß nicht mehr genau) und Emby hat alle meine zigtausend .nfo überschrieben, mit dem, was grade online zu kriegen war. Da die Online Quellen je nach Serie nur selten oder gar nicht stimmen, hat es mich mehrere Monate Arbeit gekostet, bis alles wieder so war, wie es sein muss. Das ich Emby danach nie wieder angefasst habe, dürfte logisch sein. Seitdem hat jedes Programm (auch mein eigenes), welches .nfo verändert, absolutes Verbot in meiner Bibliothek rumzustochern. Auch Kodi darf das übrigens nicht (Datenbank in einzelne Dateien exportieren ist nicht). Das Einzige, warum ich mal .nfo in meiner Bibliothek ändere, ist wenn eine Serie abgesetzt wurde. Dann wird sie von "Continuing" auf "Ended" umgestellt. Und natürlich, wenn beim ersten Aufarbeiten Fehler passiert sind. Sowas wie Rechtschreibfehler in der Beschreibung oder falsche bzw. fehlende Altersfreigabe, usw. Wenn ich sowas bemerke, wird es natürlich beseitigt. Betrifft das nur eine einzelne .nfo erledige ich das einfach mit einem Text Editor. Aber auch das mache ich am Desktop im Arbeitsordner.

Wenn man WatchedList nimmt, hat man obendrein immer auch ein unabhängiges Backup der Flags, was speziell bei Serien ggfs. unheimlich wichtig sein kann. Bei Filmen ist es nicht ganz so wichtig. Wenn ich Lust auf einen Film habe, schaue ich ihn mir an. Egal ob er als Gesehen markiert ist oder nicht. Bei Serien ist das anders, da man hier stets wissen muss, was als nächstes dran kommt.

Ne, dich mein ich nicht. Aber ich bin mit EMM zufrieden, er macht ja auch nix an der Datenbank sondern schaut sich nur den gesehen Status an.

Ich weis jetzt nicht wo der Unterschied zwischen Arbeitsordner und Medienordner ist wenn ich die nfo für einen Film / Serie nach dem anderen erstelle/bearbeite und dann Kodi diese aktualisieren lasse. Ich lass den EMM auch nicht einfach blind durchlaufen, das könnte Kodi ja auch selber. Ich muss auch nicht jeden Rechtschreibfehler korrigieren, mir gehts haupsächlich um deutsche Texte und die Artwork.
WatchedList ist sicher auch eine gute Möglichkeit.

Achja, ich bin nicht so für Bedienungsanleitungen, aber für Media-Buddy bräuchte ich sicher eine, so richtig bin ich da nicht durchgestiegen. Vlt nehm ich mir nochmal die Zeit dafür.
Die ganze Video/Audio nachbearbeitung brauch ich nicht, aber das hats für mich auf den ersten Blick unübersichtlich gemacht.

Zitat

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.

Zitat

Der Lapi-Client mit dem die NFO erzeugt wird hängt nicht an der DB, schon klar dass das dann unsinn ist

OK

Zitat

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:

Zitat von derMaik

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