phpMyAdmin & Kodi Datenbank

  • Hallo,

    ich habe ein paar Verständnisfragen zur ausgelagerten Kodi Datenbank in phpMyAdmin, genauer gesagt zu der "movie" DB.

    1. Frage: Warum ist bei manchen Filmen die idMovie = idFile und bei manchen ist idMovie idFile?

    kodinerds.net/wcf/attachment/72236/

    2. Frage: Warum bekommen Filme welche aktualisiert wurden eine andere idMovie und behalten nicht die gleiche id wie vor der Aktualisierung?

    3. Frage: Neu hinzugefügte Filme haben auf einmal eine 5-Stellige idFile, warum? Habe keine 37.000 Filme ^^

    4. Frage: Kann die Datenbank so angepasst werden, dass den Filmen die idMovie alphabetisch zugeordnet wird? Sagen wir mal ich hätte 2840 Filme, dann will ich das (500) Days of Summer die ID=1 hat (was er ja schon hat) und der letzte Film z.B. Zurück in die Zukunft dann die ID=2840.

    Hintergrund zu der letzten Frage ist folgender: Bei mir werden die Cover in der Kodi Bib (hier alphabetische Sortierung) idMovie abhängig aufgebaut, sprich ein Film der zum Schluss hinzugefügt wurde braucht am längsten bis hier das Cover angezeigt wird. Das dauert teilweise mehrere Sekunden...

    Kenne mich mit Datenbanken leider überhaupt nicht aus und habe im Handbuch zu phpMyAdmin nichts hilfreiches finden können...

    Würde mich also freuen wenn mir jemand die Zusammenhänge und die Frage nach der Sortierung/Zuordnung erklären könnte ✌🏼

  • Hi.

    Kenne mich mit Datenbanken leider überhaupt nicht aus

    Das merkt man. Zunächst, PHPMyAdmin ist keine Datenbank. Das ist eine Web App, mit der man eine MySQL (bzw. die freie Variante davon, MariaDB) Datenbank verwalten kann. Statt PHPMyAdmin kann man z.B. auch HeidiSQL dazu verwenden, eine Standalone App die direkt unter WIndows, Linux,... läuft und keinen Webserver plus Browser dafür benötigt. Noch weniger Aufwand benötigt man mit einer CLI (einem "Dos Fenster", wenn du in der Windows Welt zu Hause bist). Die notwendigen Befehle zum Verwalten der Datenbank werden mitgeliefert. Allerdings muss man hier halt alles eintippen. PHPMyAdmin wird sehr oft bei Online Datenbanken verwendet, wo ein Web Tool ja auch viel Sinn macht. Für eine lokale Datenbank wäre mir das aber viel zu viel Aufwand. Da finde ich sowas wie HeidiSQL einfach viel besser.

    Bei einer Datenbank wird mit Abfragen (Englisch "Query", das Q in MySQL) gearbeitet, die unter anderem auch eine Sortierung beinhalten können. Das ist aber eine Sache der Software, in diesem Fall von Kodi. Um das zu ändern, müsste man Kodi umprogrammieren. Eine Aufgabe für die Entwickler. Nur ob die das je machen würden, keine Ahnung.

    Was man direkt in der Datenbank machen kann, wenn man weiß, was man tut, ist es die DB zu optimieren und ggfs. zu re- indizieren. Davon würde ich aber die Finger lassen, so lange man sich nicht genau mit Datenbanken auskennt. In aller Regel verschlechtert man die Geschichte nur bis hin zum totalen Crash. Und wirklich viel Speed würde das in deinem Fall auch nicht bringen können.

    Und deine anderen Fragen im Einzelnen, obwohl alle mehr oder weniger dieselbe Antwort haben:

    Warum ist bei manchen Filmen die idMovie = idFile und bei manchen ist idMovie ≠ idFile?

    Weil die ID jeweils fortlaufende Nummern sind, die automatisch hochgezählt werden. idFile umfasst nicht nur die Filme, sondern auch die Serien, Videos, Musik aber auch Poster, Fanart, Clearart und sogar die Senderlogos. Alles, was an Dateien irgendwie in der Datenbank eingebunden wurde. Das Eine hat mit dem Anderen nichts zu tun. Wenn es da Übereinstimmungen gibt, ist das purer Zufall.

    Warum bekommen Filme welche aktualisiert wurden eine andere idMovie und behalten nicht die gleiche id wie vor der Aktualisierung?

    Die gleiche Antwort, die id wird automatisch hochgezählt. Dadurch bekommt jeder Film, der neu eingelesen wird, auch eine andere id. Und eine Aktualisierung des Films bedeutet nichts anderes als das neu Einlesen.

    Neu hinzugefügte Filme haben auf einmal eine 5-Stellige idFile, warum? Habe keine 37.000 Filme

    Auch hier wieder die gleiche Antwort, die id wird automatisch hochgezählt und zählt alle Dateien, die von Kodi verwendet werden, nicht nur die Filme selbst.

    -------------------------------------
    Danke fürs lesen, Claus

  • Ok, alles klar. Vielen Dank für die ausführliche Aufklärung.

    Ich nutze das halt, weil es auf der Synology läuft und finde das ganz ok so...bis auf die Sache mit den Ladezeiten eben. Aber das liegt dann wahrscheinlich auch am Netzwerk, dass es so lahm ist.

    Synology DS 220j | Nexus v20.2 | NVIDIA Shield TV Pro | Xiaomi TV Box S 2nd Gen | Xiaomi MiBox S | LG OLED65C17LB

  • Also der Punkt mit den Ladezeiten der Cover/Fanart von teilweise 15s bei neu hinzugefügten Filme nervt mich total X(

    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?

    Synology DS 220j | Nexus v20.2 | NVIDIA Shield TV Pro | Xiaomi TV Box S 2nd Gen | Xiaomi MiBox S | LG OLED65C17LB

  • Da ist dein genereller Aufbau von Frage ... bei mir gehe ich auf Filme und schwups - alle Cover da. Keinerlei Wartezeit.

    Aber ich muss dich schonmal enttäuschen, das DS220j ist wirklich sehr schwach auf der Brust - das ist schonmal eine deutliche Bremse im ganzen Aufbau. Das Ding ist mit SMB schon Überfordert ...

    das Einzige was am Ende zählt ist
    dass ihr lebt was ihr liebt und liebt wofür ihr lebt


    Kodi HTPC - W11 | AMD Athlon 3000G | Pioneer A 504R Bj. 96
    OMV NAS - NAS | Emby Server | LogitechMediaServer
    3x Logitech SqueezeBox & 3x RasPi PiCorePlayer
    Unifi Netzwerk | Sophos XGS Firewall | Agfeo TK | Kentix Security
    Loxone SmartHome

  • Ich habe über 40.000 Serien Episoden und 3.000 Filme, dazu 100.000 Musikstücke und 250.000 Fotos. Das Einzige, wo es nervt sind die Fotos, denn hier müssen die Metadaten jedes Mal neu eingelesen werden, da die Metadaten nicht zwischengespeichert werden. Das verzögert das Einlesen der Verzeichnisse deutlich, speziell, wenn viele Fotos im Ordner sind.

    Das erste Einlesen der Grafiken dauert nun mal ein paar Sekunden. So 2-3 Sekunden sind es schon, vorausgesetzt der Server ist online und die HDD läuft. Das hängt größtenteils von dem Speicherort ab, außerdem auch von der Hardware, die eingesetzt wird. Muss die HDD beispielsweise erst anlaufen oder gar der Server erst aufwachen, dauert es ewig. Das liegt aber an der Natur der Sache. Sonst sind es maximal 3 Sekunden bei meiner großen Sammlung. Deine 15 Sekunden sind jedenfalls nicht normal, immer vorausgesetzt, die HDD bzw. der Server muss nicht erst hochfahren, um die Grafiken einzulesen.

    Viel schlimmer finde ich es, das Änderungen an Grafiken bzw. auch am Gesehen Status meist nicht direkt angezeigt werden. Hat man z.B. ein Logo hinzugefügt (über den Kontextmenü Punkt "Informationen"), muss man erst aus File bzw. Serien raus, ein anderes Modul aufrufen und dann zurück gehen, damit die Änderungen angezeigt werden. Wenn ich eine Serie zu Ende geschaut habe, wird weder beim Staffelordner noch bei der Serie selbst das Gesehen Flag gesetzt. Auch hier hilft nur das, was beim Ändern von Grafiken hilft.

    Die ID hat jedenfalls nichts mit der Geschwindigkeit des ersten Einlesens zu tun. Wenn du da meinst, irgendwelche Effekte zu sehen, ist das Wunschdenken. Geht es bei einem Film dadurch vielleicht etwas schneller, dauert es eben beim nächsten um so länger. Ist reiner Zufall. Die Gesamtzeit wird nicht beeinflusst. Und obendrein spielt das sowieso nur beim allerersten Aufrufen des neuen Films eine Rolle. Danach sind die Grafiken gecached und nahezu sofort verfügbar, selbst wenn der Server gar nicht online ist. Ist ein wirklich zu vernachlässigendes "Problem". Wenn es sonst nichts gibt, prima. Leider gibt es durchaus viel wichtigere Problem, die man angehen müsste...

    -------------------------------------
    Danke fürs lesen, Claus

  • DS220j ist wirklich sehr schwach

    Aah, ok...

    Und was bremst deiner Meinung nach mehr ein, die DS220j oder folgendes Netzwerk -> Synology NAS ist über Powerline (AV1000 von TP-Link) mit der Fritzbox (7590DS) verbunden, hier erreiche ich Übertragungsraten beim Schreiben von 17MB/s und Lesen 22MB/s mit WLan 5GHz, Android Box ist mit WLan (5GHz) verbunden, laut Fritzbox 325/430Mbit/s?

    Da ich jetzt die Shield habe wollte ich eh mal testen wie es ist mit Lan-Kabel und ohne Poweline/Wlan...

    Die ID hat jedenfalls nichts mit der Geschwindigkeit des ersten Einlesens zu tun. Wenn du da meinst, irgendwelche Effekte zu sehen, ist das Wunschdenken.

    Also, hab einen Film mit idMovie 2345 und diese ist neben einem Film mit der idMovie 1. Rufe ich die Bib auf sind die Arts von Film mit idMovie 1 sofort zu sehen, ca. 15sec später dann die Arts von idMovie 2345. Hab nun den Film 2345 händisch auf idMovie 17 geändert, da hier einer gelöscht wurde und siehe da wenn ich jetzt die Bib aufrufe sind die Arts von Film1 und Film17 (vorher 2345) nahezu unverzögert (<1s) zu sehen, also nix Wunschdenken ;)

    Viel schlimmer finde ich es, das Änderungen an Grafiken bzw. auch am Gesehen Status meist nicht direkt angezeigt werden.

    Ja das finde ich auch nicht so...auch wenn man Filme aktualisiert passieren ganz merkwürdige Sache, am besten danach immer Kodi beenden und Neustarten ^^

    Aber was ich mich eher frage ist wieso sowas nicht schon längst an die Entwickler weitergeleitet wird. Ich blicke da mit den Tickets und Github nicht so durch, sonst hätte ich schon zig Tickets erstellt :D

    Synology DS 220j | Nexus v20.2 | NVIDIA Shield TV Pro | Xiaomi TV Box S 2nd Gen | Xiaomi MiBox S | LG OLED65C17LB

  • da bremst sowohl die Syno als auch u.U. das Powerline. Powerline ist natürlich abhängig von der Qualität und Länge der Verkabelung sowie weiterer Stör-Verbraucher im Stromnetz. Und die Syno ist ansich einfach lahm :( So leit es mir tut.

    das Einzige was am Ende zählt ist
    dass ihr lebt was ihr liebt und liebt wofür ihr lebt


    Kodi HTPC - W11 | AMD Athlon 3000G | Pioneer A 504R Bj. 96
    OMV NAS - NAS | Emby Server | LogitechMediaServer
    3x Logitech SqueezeBox & 3x RasPi PiCorePlayer
    Unifi Netzwerk | Sophos XGS Firewall | Agfeo TK | Kentix Security
    Loxone SmartHome

  • Muss dir nicht leid tun :D

    Ist meine erste NAS, hab die mir vor ca. 1.5 Jahren geholt. War mir schon klar, dass die nicht sooo die Power hat aber zum Einstieg war es ganz gut voallem preismäßig...

    Synology DS 220j | Nexus v20.2 | NVIDIA Shield TV Pro | Xiaomi TV Box S 2nd Gen | Xiaomi MiBox S | LG OLED65C17LB

  • Machst du die Anzeige über Filme oder gehst du evt. über Videos->Dateien rein. Mir ist bei Nachstellen eines hier im Forum berichteten Problems schon mal aufgefallen, dass (bei gescratchten Filmen) unter "manchen" Umständen die Coveranzeige sehr langsam sein kann. Ich meine, das war nur bei Androidi Client der Fall, nicht bei Windows Client. (Allerdings nutze ich keine externe DB - dein Problem könnte schon unabhängig davon sein.)

    In deiner Signatur stehen verschiedene Clients - ist das Problem auf allen Clients? Hast du einen PC, und da ist es auch?

    Ansonsten, bei normalem DB-Design, auch bei mehreren Zehntausend Einträgen, sollte die Geschwindigkeit der DB selbst nicht limitierend sein, bei der Coveranzeige. Und schon gar nicht die Bandbreite zur Datenbank.

    Hast du die Thumbnails auf NAS ausgelagert? Schuss ins Blaue: Mal statfiles auf false setzen: advancedsettings.xml - Official Kodi Wiki

    Du kannst auch mal ein top-Befehl aufmachen auf deinem NAS, und schauen, ob du während der langsamen Coveranzeige ein Ressourcen-Problem siehst. Ich habe vergessen, was Synology so per Default an Tools mitbringt, aber auch Tools wie iostat und ifstat.

    Auf der Client Seite kann man auch top probieren, z.B. unter adb shell. Oder einfach auch Mal debug logging einschalten, und sehen, ob da was auffällig ist in der Bildschirmanzeige (z.B. bzgl. CPU Nutzung) und im Log selbst, wenn man sich den genauen Zeitstempel merkt, wann du auf die Anzeige des Covers wartest.

    Issues · xbmc/xbmc · GitHub und HOW-TO:Submit a bug report - Official Kodi Wiki

    kennst du? Man benötigt (nach meinem Gedächtnis) nur github account.

    Kodi 21.1, 17.6, 21.1, 16, 20.5 on Windows 11 Pro, Android 6, Android 12, FireTV Box 2nd Gen, FireTV 4k Max 2nd Gen
    Media on NAS, OpenMediaVault 6 (Debian Linux).

  • locha Interessant zu wissen wäre, ob du mittels pathsubstitution die Thumbnails in der advancedsettings.xml
    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 X(

    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 X(

    -> 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 ;)

    3x RPI 5 mit Libreelec (Client's), 2x RPI 4 mit Libreelec (Client's), 1x RPI5 als DB Server (MariaDB), PI-Hole auf Raspi OS, 1x Qnap TS-431P2, TS-420 (Backup Nas).

    7 Mal editiert, zuletzt von Timmiotool (16. Juli 2024 um 10:49)

  • Machst du die Anzeige über Filme oder gehst du evt. über Videos->Dateien rein.

    Filme, also DB Kodi. Videos->Dateien (also Quelle) dauert noch länger, ich weiß...

    (bei gescratchten Filmen)

    was bedeutet das?

    ist das Problem auf allen Clients?

    Ja auf allen, auf PC ist diese DB nicht drauf, könnt ich mal testen und Thumbs sind nicht ausgelagert, also local auf der Shield.

    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.

    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....:D wie gesagt, eher nur positives, sprich Arts von dem betroffenem Film werden schneller geladen.

    Wenn hier bei Dir nun 10 Sekunden steht, passt definitive was nicht

    Hier alles i.O., steht auch iwas mit 0,0xx Sekunden

    Synology DS 220j | Nexus v20.2 | NVIDIA Shield TV Pro | Xiaomi TV Box S 2nd Gen | Xiaomi MiBox S | LG OLED65C17LB

    Einmal editiert, zuletzt von locha (16. Juli 2024 um 11:38)

  • Evtl. muss dein Nas auch erst aus dem Standby anlaufen,

    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…

    Schneller ist das jetzt (vermutlich) nur, da er die Hälfte seiner Tabellen nicht mehr findet

    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.

    Synology DS 220j | Nexus v20.2 | NVIDIA Shield TV Pro | Xiaomi TV Box S 2nd Gen | Xiaomi MiBox S | LG OLED65C17LB

  • Hab nun den Film 2345 händisch auf idMovie 17 geändert, da hier einer gelöscht wurde und siehe da wenn ich jetzt die Bib aufrufe sind die Arts von Film1 und Film17 (vorher 2345) nahezu unverzögert (<1s) zu sehen, also nix Wunschdenken

    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.

    Sobald die Grafik einmal eingelesen wurde, ist sie ab dem zweiten Mal blitzschnell da. Das wäre also ganz genau so der Fall, wenn du die ID gelassen hättest wie sie war. Denn beim (ab dem) zweiten Mal wird sie aus dem lokalen Cache des Klienten (also z.B. von der Shield, auf der Kodi läuft) geladen, was ungleich schneller ist als extern vorhandene Dateien anzuzeigen. Durch das Ändern der ID des Films wurde die dem Film zugeordnete, lokal zwischengespeicherte Datei nicht geändert. Sie ist nach wie vor gültig (sofern die DB nicht ganz abgeschossen wurde).

    Wobei 15 Sekunden wirklich extrem lang sind. Eine Erklärung kann da eigentlich nur eine lahme Hardware im NAS, eine lahme Verbindung zum NAS, schlafende HDD im NAS oder Standby des NAS (ggfs. auch eine Kombination aus diesen Gründen) liefern. Oder es werden gar nicht die beim Film gespeicherten Grafiken verwendet, sondern sie werden aus dem Internet nachgeladen (ist eine Sache, wie Kodi konfiguriert wurde und wie die .nfo aufgebaut sind). Dann sind 15 Sekunden absolut normal und würde bei meinem lahmen Internet zu Hause schon als "Schnell" durchgehen.

    -------------------------------------
    Danke fürs lesen, Claus

  • Bei mir macht es von der Performance einen Unterschied, ob ich die Sammlung mit der Option "Dateiansicht" oder "Video" öffne. Bedeutet - in Kodi einen Medien-Ordner als "Video-Ordner" hinzuzufügen, bringt bei mir mehr Performance, konkret werden einmal eingelesene Titel, beim 2. Aufruf "sofort" mit Cover angezeigt (Emburay-Skin). Ich habe eine MariaDB auf einem Synology 923+ mit 10GbE LAN installiert, der Client ist eine Shield 2019 pro, per 1GbE LAN angebunden, die Thumbnails sind ebenfalls zentral auf dem NAS ausgelagert, die Metadaten/Cover/nfo's liegen im jeweiligen Medien-Ordner.

    Mit dem Windows-Tool "HeidiSQL" kann man übrigens die Datenbanken optimieren lassen.

    Meine These/Erfahrung sei noch erwähnt, "BumBum-Performance benötigt auch BumBum-Hardware", oder man muss eben mit Abstrichen leben;)

  • 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.

    Sobald die Grafik einmal eingelesen wurde, ist sie ab dem zweiten Mal blitzschnell da.

    Ey ich hab das schon verstanden und ich wäre froh wenn es sich so verhalten würde wie ihr das hier schreibt...tut es aber nicht. Und nun bin ich hier um hoffentlich eine Lösung für mein "Monk" Problem zu bekommen ;)

    Synology DS 220j | Nexus v20.2 | NVIDIA Shield TV Pro | Xiaomi TV Box S 2nd Gen | Xiaomi MiBox S | LG OLED65C17LB

  • 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.

    Zitat

    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....:D wie gesagt, eher nur positives, sprich Arts von dem betroffenem Film werden schneller geladen.

    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:

    Zitat

    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.

    3x RPI 5 mit Libreelec (Client's), 2x RPI 4 mit Libreelec (Client's), 1x RPI5 als DB Server (MariaDB), PI-Hole auf Raspi OS, 1x Qnap TS-431P2, TS-420 (Backup Nas).

    3 Mal editiert, zuletzt von Timmiotool (16. Juli 2024 um 13:32)

  • Jaja... ich weiß, bin aber immer so neugierig und dann kommen diese Zwangsstörungen hinzu ^^

    ...dort fehlt jetzt die Zuordnung der Art Tabelle und das ist nur eine von diversen Tabellenzuordnungen,

    Oha, das erklärt so paar Sachen die ich gestern beobachtet habe...

    Mal sehen was ich so als nächstes mache...ein BackUp der DB hab ich ja 8)

    Weiß wer ne gute Quelle, vorzugsweise deutsch, wo ich mich über MariaDB/phpMyAdmin oder Grundlegend über Datenbanken informieren kann?

    Das ganze findest du im Wiki: Klick

    das ist gut, hab mich schon gefragt was hinter den ganzen cXX steckt, cool danke :thumbup:

    Synology DS 220j | Nexus v20.2 | NVIDIA Shield TV Pro | Xiaomi TV Box S 2nd Gen | Xiaomi MiBox S | LG OLED65C17LB

  • 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.

    3x RPI 5 mit Libreelec (Client's), 2x RPI 4 mit Libreelec (Client's), 1x RPI5 als DB Server (MariaDB), PI-Hole auf Raspi OS, 1x Qnap TS-431P2, TS-420 (Backup Nas).

    2 Mal editiert, zuletzt von Timmiotool (16. Juli 2024 um 13:45)

  • Ach halb so wild, bißchen Mut zur Lücke schaden nicht solange ich damit niemanden verletzte :S

    Ich sichere mich ja vorher wenn möglich immer ab und fange dann an mit learning by doing

    Synology DS 220j | Nexus v20.2 | NVIDIA Shield TV Pro | Xiaomi TV Box S 2nd Gen | Xiaomi MiBox S | LG OLED65C17LB

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!