Ich arbeite komplett ohne .nfo alles steht in der DB, die Daten liefern die Scraper. D.H. habe alle Clients an die DB angebunden
nfos ersetzen ja auch nicht die Datenbank! Sie sind da um die Scraper zu "entlassten" und eigene Angaben in die DB zu bekommen. Auch wenn die Datenbank mal abkackt sind die Daten durch die nfos schneller wieder in der Datenbank.
Ich arbeite komplett ohne .nfo alles steht in der DB
Oh böser Fehler, wenn es die DB mal zerhaut, und die Mega-Sammlung neu angepasst werden muss...
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.
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...
Der Weg über .nfo's ist völlig OK und auch gut, da es quasi meine Backup Strategie ersetzt.
Das ist der Weg allerdings eher für den erfahrenen Anwender...
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
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?
Viele wege führen nach Rom!
z.B. Trakt Addon oder wie Lehmden1 erwähnt hat WatchedList beides übers Kodirepo zu bekommen.
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 
Den gesehen Status bekommst Du auch hin indem du die Watchedstates mit exportierst und importierst vor dem Wechsel.
Das geht durch einen Eintrag in die advancedsettings
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.
hab ich gemacht, 2800 Filme hat ca. 1h gedauert...alles gleiches Setup über WLan & Powerline...ist für mich schnell genug.
Das Scrollen durch die Bib flutscht nur so, richtig gut. Hab für das Scrappen die gleiche Reihenfolge gewählt wie als ich die DB ausgelagert hab, sprich ein besonderer Film der eine 4-Stellige ID hatte ist neben einem der die ID 1 hatte. Und siehe da, keine 15sec bis das Cover da ist. Ist wirklich nur minimal verzögert, ein Augenzwinkern vllt. 
damit kann ich leben. Hoffe natürlich das bleibt auch so wenn die ganzen Serien dazu kommen 
Wenn ich die Bib neu auslagern will, kann ich dann einfach wie auf Screenshot die Bib anwählen und löschen?
Desweiteren würde ich in Zukunft gerne weiterhin mit "Lapi-Kodi" meine nfo's erstellen (lokale DB) und danach wiederum mir "Lapi-Kodi#2" diese über local only in die ausgelagerte NAS DB scrapen. Wie kann ich jetzt auf dem Laptop zwei verschieden Kodi's (will noch gerne bei Nexus bleiben) installieren, also eins mit lokaler DB und eins mit der entsprechenden AS für die externe zentrale DB?
Jeder wie er mag.
Einfach Kodi in einen anderen Ordner installieren, aber mit einer Verknüpfung starten. z.B. "E:\Kodi\kodi.exe" -p
Portable mode - Official Kodi Wiki
Datenbank kannste auch umbennen, oder löschen.
Ich philosophiere auch mal![[ag]](https://www.kodinerds.net/wcf/images/smilies/smiley44.gif "ag"){kind=small}
Zum Verständnis vom Anwender für Anwender, meine Zusammenfassung.
Man hat eine Umgebung mit mehreren Kodi-Clients, und möchte (natürlich) auf allen Clients den gleichen Status haben. Um bei Kodi zu bleiben, führt der Weg an einer externen/zentralen Datenbank nicht vorbei. Realisiert wird diese Datenbank über einen MySQL-Server, welcher im lokalen Netzwerk mit einer statischen IP zu installieren ist. Dieser DB-Server muss immer dann online sein, "bevor" ein verbundener Kodi-Client gestartet wird. Nutzt man einen Client, welcher einen beschränkten Storage-Speicher hat (FTV usw.), muss bei einer Mega-Sammlung geprüft werden, ob der Client-Speicherplatz für die Kodi-Thumnails ausreicht, u.U. müssen die Thumbnails zentral ausgelagert werden (experimentelle Funktion). Bis hier hin die Theorie.
Ist die Entscheidung zum Datenbank-Server gefallen, kann dieser z.B. unter Windows und Linux installiert werden, ebenfalls auf einem NAS, wenn das NAS-Betriebssystem die Installation unterstützt.
Performance - hängt maßgeblich von der kompletten Umgebung ab, also Netzwerk-Anbindung, Server-Performance und Speicher-Lacation der Datenbank. Ein Datenbank-Server auf einem beschränkten System, wird sich im Benutzererlebnis anders zeigen, als ein Server welcher auf Performance ausgelegt ist. Zu nennen ist an dieser Stelle vor allem die Netzwerk-Anbindung (LAN! ->WLAN ist wegen der Latenz nicht empfehlenswert), und auf welchem Storage-Speicher die Datenbank liegt (HDD, SSD, M.2 NVMe SSD), bzw. zur Verfügung gestellt wird. Letzteres gilt übrigens auch für zentral ausgelagerte Thumbnails. Zur Einrichtung und Verwaltung der Datenbank bieten sich phpMyAdmin und HeidiSQL an. Mit dem Windows-Tool HeidiSQL können Datenbanken exportiert, geprüft, repariert und optimiert/defragmentiert werden. An dieser Stelle sei erwähnt, das es nicht empfehlenswert ist, "händisch" an/in der Datenbank zu experimentieren ->Wink mit dem Zaunpfahl
Kodi-Datenbank/MySQL-DB-Server vs. Artworks/Poster/nfo's (Metadaten) - muss unterschieden werden. Metadaten werden vom Kodi-Scraper/Beschaffer entweder (wenn lokal nicht verfügbar) online bei Online-Datenbanken wie z.B. IMDB oder TV/TMDB beschafft, oder bei lokal verfügbaren Metadaten mit einem "local only scan" in die Kodi-Datenbank integriert. Zudem generiert Kodi noch Thumbnails, welche per Standard auf dem Client gespeichert werden. Sind lokale Metadaten (z.B. in den Medienverzeichnissen) nicht verfügbar, müssen diese zunächst online beschafft werden, um diese dann in einer lokalen oder externen/ausgelagerten Kodi-Datenbank zu speichern. Der Unterschied zu lokal gespeicherten Metadaten ist, im Zweifel müssen die Daten aus den Online-Datenbanken neu beschafft werden, wenn eine Kodi-Datenbank aus irgendwelchen Gründen nicht mehr zur Verfügung steht. Das kann im Worst Case auch dazu führen, das alle händischen Anpassung bez. Titel und Artwork neu eingepflegt werden müssen. Insofern an dieser Stelle meine Empfehlung einen Media-Manager zu nutzen, welcher die Metadaten lokal speichert. Generell noch ein Hinweis zur Beschaffung der Metadaten mit dem Kodi-Scraper oder einem MediaManager-Tool. Die Treffergenauigkeit hängt maßgeblich davon ab, wie genau das Matching der Titelbezeichnung der Onlinedatenbank vs. eigene gewählte Titelbezeichnung/Filename vorliegt. Im Zweifel sollte der Titel in einer Onlinedatenbank recherchiert werden, um das passende Ergebnis zu erzielen.
Achja, ich bin nicht so für Bedienungsanleitungen, aber für Media-Buddy bräuchte ich sicher eine,
Aber jetzt genug OffTopic.
@catshome hat es schon gut zusammen gefasst. Wenn man bei Kodi und seiner Datenbank bleiben will, also nicht auf Jellyfin, Emby oder Plex als System mit etwas Kodi Anbindung umsteigen will, benötigt man bei mehreren Klienten eine zentrale, für alle Kodi Systeme einheitliche Datenbank. Das ist dann eine MySQL Datenbank, die im Netzwerk verfügbar sein muss. Die lokalen .nfo und Grafiken aus dem Media-Manager dienen als "Futter" für diese Datenbank, damit man die entsprechenden Informationen nicht immer wieder neu aus dem Internet holen und ggfs. auch noch anpassen muss. Man braucht also beides, die Kodi DB und die .nfo. Auch bei einem eventuellen Wechsel des Systems, also wenn man dann doch mal von Kodi auf Emby o.Ä. umsteigt, bleiben die Metadaten aus den .nfo erhalten. Deswegen pflege ich die .nfo entsprechend sorgfältig. Hier steckt halt die ganze "Arbeit" zum Stylen der Medien- Bibliothek drin.
Ich würde aus eigener Erfahrung empfehlen, ein extra System für die MySQL Datenbank aufzusetzen. Das NAS beinhaltet immer irgendwelche HDD. Die verursachen Lärm, Hitze und verbrauchen Strom. Deswegen geht mein 40 TB Eigenbau- NAS bei Nichtgebrauch in den Standby. Es muss nur laufen, während ich lokale Filme oder Serien schaue. Es ist also, je nach Umstand und Wetter nur 0-12 Stunden am Tag online. Wenn ich Live TV schaue oder Online streame, muss das NAS nicht laufen obwohl ich Kodi nutze. Deswegen wäre es nicht gut, wenn dort die MySQL drauf wäre. Die vielen HDD mitlaufen zu lassen, während ich Live TV schaue, macht keinen Sinn für mich.
Natürlich "darf" dieses 24/7 System auch andere Aufgaben "nebenher" erfüllen, aber als NAS, nein danke. Das System sollte möglichst wenig Strom verbrauchen, dabei aber möglichst viel Leistung bieten. Dafür kann man einen Raspberry Pi nutzen, muss man aber nicht. Denn es gibt inzwischen Intel basierte "Mini-PC", die nicht mehr Geld kosten, weniger Strom verbrauchen und deutlich mehr Leistung als ein RasPi 5 bieten. Obendrein kann man dort sogar Windows laufen lassen, wenn man will, ist also nicht auf Linux festgelegt. Mein 24/7 Mini PC hat neu 80€ gekostet, incl. Gehäuse, Netzteil, 6GB RAM, 128 GB EMMC Speicherplatz und einer Windows 10 Pro Lizenz. Ich habe nur zusätzlich eine noch herum liegende M2 SSD eingebaut, um mehr Platz zu haben. Inzwischen haben diese Teile aber alle Windows 11. Ist halt schon etwas älter. Mein System verbraucht mit laufendem Windows an der Steckdose gemessene 2,8 Watt, was bei den heutigen Strompreisen keine 5€ pro Jahr an Stromkosten sind. Das ist mir der Spaß durchaus wert. 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).
40 TB Eigenbau- NAS
Mags du kurz erläutern wie der Eigenbau genau zusamengesetzt ist? Oder ist das Einfach nur ein Mini PC mit angeschlossenen externen HDD's?
Die Synology DS220j hab ich mir als Einsteiger geholt, vorher nie so ein System gehabt, immer nur externe HDD's über USB an TV. Nun überlege ich auch in einem Jahr oder so entweder eine neue Synology mit mehr Bums oder auch Eigenbau...
Mit ner Syno hast du deutlich weniger Arbeit. Das läuft OOTB sau stabil und anständig und ist dazu super einfach. Einsteigen sollte man mMn. mit einer DS 224+. Mit dem Ding kannst du eig alles anstellen, auch als Docker Host lässt es sich einsetzen. Alternativ eine DS423+, die hat gleich 2x m.2 Einschübe. Sinnvoll wenn du vorhast diverse Dockerdienste einsetzen zu wollen die etwas performance brauchen wie eine NextCloud o.Ä.
Bei beiden Modelllen lässt sich übrigens u.A. der RAM auch erweitern.
Mit nem Eigenbau kommst du nicht wirklich günstiger, bist aber natürlich offener / freier. Mit all seinen Vor- und Nachteilen - da musst du dich halt selbst um alles kümmern. Je nachdem wie fit du bist oder sein möchtest bzgl. Linux Aber auch das kann sehr simpel sein dank Systemen wie unRaid oder OMV
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.
Mags du kurz erläutern wie der Eigenbau genau zusamengesetzt ist?
Ist ein normaler, uralter ATX Big Tower, in dem ein auch schon älteres Board mit einem Celeron J1900 und 8 GB RAM drin steckt. Dazu ein PCIe 4 x SATA Controller und die diversen HDD. Alles aus altem Zeugs, das rum lag, zusammengebastelt. Die 8 HDD sind intern per SATA angeschlossen. Wenn man zu viele externe USB Platten anschließt, "verschwindet" gerne mal die eine oder andere davon. Dann muss man das USB Kabel rausziehen und wieder einstecken. Finde ich lästig. Außerdem nerven die "tausend" Steckernetzteile für die externen Laufwerke.
Eigentlich ist mein NAS reine Resteverwertung und hat mich deswegen kaum etwas gekostet. Lediglich zwei 8 TB Platten habe ich neu für das NAS angeschafft. Ach ja, die 25€ für den zusätzlichen SATA Controller, die sind auch direkt für das NAS angefallen. Viele der eingebauten HDD waren mal externe Platten, die ich aus dem Gehäuse entfernt habe. Damals waren externe Platten deutlich billiger als interne. Heute haben sich die HDD Preise (dank den "Bitcoin- Idioten") massiv nach oben entwickelt und dabei angeglichen. Deswegen lohnt es meist nicht mehr, die externen Gehäuse zu knacken, um an die eigentlichen HDD zu kommen. Seinerzeit hat einem das aber locker 30% eingespart.
Das System ist für nichts anderes da, als Speicherplatz im Netzwerk zur Verfügung zu stellen, obwohl der J1900 alle mal stark genug wäre, auch andere Aufgaben zu erledigen. Aber das Ganze frisst für meinen Geschmack zu viel Strom um ständig zu laufen. Deswegen habe ich auch Windows10 drauf. Denn sowohl Ubuntu als auch Debian und auch sowas wie OMV sind in Bezug auf Standby und WOL erheblich unzuverlässiger als Windows. Da neben SMB nur Standby/WOL für mich von Bedeutung ist, ist es nach vielen Experimenten halt doch Windows geworden. Läuft für meine Zwecke einfach am stabilsten.
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 
Bevor ich das mache, wie geht ihr in so einem Fall mit den alten Thumbs um? Thumbs erst löschen, dann die DB neu erstellen, oder werden diese überschrieben und/oder wieder die gleichen genutzt. Will nix doppelt haben wegen internem Speicherplatzmangel...
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.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
