Solltest du Medienmetadaten auf der SSD oder zusammen mit der Bibliothek speichern?
Belassen Sie die Datenbank und den aktiven Cache des Medienservers auf einer SSD, während Sie portable NFO-Dateien und ausgewählte Grafiken bei der Mediensammlung speichern, wenn Migration wichtig ist.
„Metadaten“ umfasst mehrere verschiedene Dinge: die Anwendungsdatenbank, den Benutzerstatus, Indizes, Caches, heruntergeladene Grafiken, Kapitelbilder, Trickplay-Vorschauen, NFO-Begleitdateien und manuell kuratierte Bilder. Wenn alles an einem Ort gespeichert wird, entstehen entweder unnötige HDD-Latenzen oder eine eingeschränkte Portabilität. Ein Heimmedienserver funktioniert normalerweise am besten mit einem aufgeteilten Layout, dessen Grenzen für Sicherung und Wiederherstellung dokumentiert sind.
Klassifizieren Sie die Metadaten, bevor Sie ein Laufwerk auswählen
Erfassen Sie die Anwendungsdatenbank, Konfiguration, Benutzerkonten, Wiedergabeverlauf, Indizes, Caches, Miniaturbilder, Poster, Hintergrundbilder, NFO-Dateien, Untertitel und Plug-in-Daten. Kennzeichnen Sie jedes Element als maßgeblich, portabel, wiederherstellbar oder temporär.
Die Anwendungsdatenbank und der Benutzerstatus sind normalerweise serverspezifisch und ändern sich häufig. NFO-Dateien und neben den Medien gespeicherte Grafiken sind Dateien auf Dateiebene, die von einer anderen kompatiblen Bibliothek gelesen werden können, während Caches und generierte Miniaturbilder möglicherweise entbehrlich sind.
Wählen Sie den Speicherort nicht allein anhand des gesamten Ordnernamens. Ein Verzeichnis namens „Metadaten“ kann sowohl unersetzliche manuelle Änderungen als auch problemlos neu generierbare Bild-Caches enthalten. Daher gelten für die Inhalte unterschiedliche Regeln für Sicherung und Platzierung.
Speichern Sie Datenbanken, Indizes und aktive Caches auf einer SSD
Datenbankabfragen, das Durchsuchen der Bibliothek, die Suche, Aktualisierungen des Benutzerstatus und der Abruf von Miniaturbildern umfassen viele kleine Lese- und Schreibvorgänge. Eine SSD reduziert die Latenz dieser Vorgänge und hält sie vom sequenziellen Medien-Workload fern.
Schneller Speicher macht ein unsicheres Dateisystem oder ein zu kleines Volume nicht wett. Ein Jellyfin-Problembericht dokumentiert Datenbanksperren und eine nicht reagierende Benutzeroberfläche während der normalen Nutzung und veranschaulicht damit, dass die Anwendungsdatenbank eine aktive betriebliche Abhängigkeit und kein entbehrlicher Cache ist.
Platzieren Sie die vollständige persistente App-Dateneinheit auf einer SSD mit ausreichend freiem Speicher, Snapshots und Sicherungen. Vermeiden Sie es, die aktive Datenbank auf einer Netzwerkfreigabe zu speichern, sofern die Anwendung deren Sperr- und Latenzverhalten nicht ausdrücklich unterstützt.
Bewahren Sie portable NFO-Dateien und kuratierte Grafiken bei den Medien auf, wenn dies sinnvoll ist
NFO-Begleitdateien, lokale Poster, Editionsbezeichnungen und manuell ausgewählte Grafiken können den Wiederaufbau einer Bibliothek in einer anderen Instanz erleichtern. Sie bleiben im Filmordner sichtbar, wenn die Anwendungsdatenbank verloren geht.
Die Portabilität ist nicht für jede Version und jeden Scanner garantiert. Ein Jellyfin-Migrationsbericht beschreibt, dass vorhandene NFO-Dateien nach einem Umzug ignoriert und überschrieben wurden. Daher ist ein Testimport erforderlich, bevor Sie sich ausschließlich auf Begleitdateien als Wiederherstellungspfad verlassen.
Speichern Sie nur Metadaten, die die Anwendung zuverlässig lesen kann und die Sie bewahren möchten. Sichern Sie manuell kuratierte Dateien und verhindern Sie, dass automatische Anbieter sie ohne kontrollierten Test überschreiben.
Beachten Sie die Grenzen von schreibgeschützten Bibliotheken und Berechtigungen
Eine schreibgeschützte Medienbereitstellung schützt Quelldateien vor versehentlichen Änderungen durch die Anwendung. Gleichzeitig verhindert sie jedoch, dass der Server NFO-Dateien, Grafiken, Sammlungen und lokale Vorschauen neben der Bibliothek speichert.
In einem Jellyfin-Problembericht schlug das Erstellen einer Sammlung aufgrund eines schreibgeschützten Medien-Dateisystems fehl, obwohl die Anwendungskonfiguration auf der SSD beschreibbar war. Der Fall zeigt, warum der Speicherort die Metadatenfunktionen beeinflusst.
Wenn die Unveränderlichkeit der Quelldateien wichtig ist, belassen Sie die Medien schreibgeschützt und leiten Sie anwendungseigene Metadaten auf das SSD-Volume. Gewähren Sie Schreibzugriff auf die Bibliothek nur, wenn lokale Begleitdateien ausdrücklich Teil des Wiederherstellungsplans sind, und beschränken Sie diesen Zugriff auf die Dienstidentität.
Halten Sie wiederherstellbare Vorschaudaten getrennt vom kritischen Status
Trickplay-Bilder, Kapitel-Miniaturbilder, extrahierte Vorschauraster und temporäre Caches können deutlich größer werden als die Kerndatenbank. Auch ihr Sicherungswert ist anders, da sie häufig neu generiert werden können.
Jellyfin bietet Optionen, Grafiken und Trickplay-Bilder neben den Medien zu speichern, was in manchen Layouts die Übersicht und Migration verbessert. Der Quellcode der Benutzeroberfläche beschreibt die Platzierung lokaler Grafiken und von Trickplay-Daten als separate Auswahlmöglichkeiten und nicht als einen universellen Metadaten-Speicherort.
Verwenden Sie ein dediziertes Cache- oder Metadaten-Subvolume, wenn die Vorschauen erheblich anwachsen. Sichern Sie die Datenbank und manuelle Metadaten häufiger als wiederherstellbare Miniaturbilder und dokumentieren Sie, welche Ordner bei einer Wiederherstellung verworfen werden dürfen.
Wählen Sie das Layout nach den Anforderungen an Wiederherstellung und Migration
Verwenden Sie ausschließlich SSD-Speicher für App-Metadaten, wenn ein Server die Bibliothek verwaltet, die Medienbereitstellung schreibgeschützt bleiben soll und schnelles Durchsuchen wichtiger ist als Portabilität auf Dateiebene. Verwenden Sie lokale NFO-Dateien und Grafiken, wenn kuratierte Metadaten mit den Dateien migrieren müssen oder mehrere kompatible Werkzeuge die Bibliothek gemeinsam nutzen.
Ein aufgeteiltes Layout bietet normalerweise die beste Abgrenzung: Datenbank, Benutzer, Indizes und aktive Caches auf der SSD; Quelldateien auf Speicher mit hoher Kapazität; ausgewählte NFO-Dateien und kuratierte Grafiken neben den Medien; große, wiederherstellbare Vorschauen auf einem separat dimensionierten Cache oder einem unterstützten lokalen Pfad.
| Datentyp | Bevorzugter Speicherort | Sicherungspriorität |
|---|---|---|
| App-Datenbank, Benutzer, Wiedergabestatus | SSD-App-Volume | Hoch |
| Indizes und aktiver Cache | SSD oder dedizierter Cache | Niedrig bis mittel |
| Kuratierte NFO-Dateien und Grafiken | Neben den Medien, wenn Portabilität wichtig ist | Hoch bei manueller Bearbeitung |
| Trickplay- und Kapitelbilder | Dimensionierter Cache oder unterstützter lokaler Pfad | In der Regel wiederherstellbar |
| Filme und Serien als Quelldateien | Speicher mit hoher Kapazität | Abhängig von der Ersetzbarkeit |
Der ZimaSpace-Leitfaden zur Auswahl von NAS-Laufwerken für App- und Metadaten-Workloads liefert den Speicherkontext für diese Aufteilung.
Überprüfen Sie das Layout mit Sicherungs- und Wiederherstellungstests
Stoppen Sie den Medienserver und sichern Sie das SSD-App-Volume sowie alle neben der Bibliothek gespeicherten Metadaten. Stellen Sie sie in einer isolierten Instanz mit denselben Containerpfaden und Berechtigungen wieder her.
Bestätigen Sie, dass Benutzer, Wiedergabeverlauf, Sammlungen, manuelle Zuordnungen, Grafiken und ein Element mit aktivierter Trickplay-Funktion erwartungsgemäß zurückkehren. Testen Sie anschließend eine zweite Wiederherstellung, die nur die Mediendateien und Begleitdateien verwendet, um festzustellen, was ohne die App-Datenbank verloren ginge.
Das Layout ist korrekt, wenn das Durchsuchen reaktionsschnell bleibt, der App-Speicher planbar wächst, die Medien wie vorgesehen schreibgeschützt bleiben können und die dokumentierte Sicherung alle nicht wiederherstellbaren Bestandteile rekonstruiert. Ändern Sie die Platzierung erst, wenn der Wiederherstellungstest ein tatsächliches Geschwindigkeits-, Kapazitäts- oder Portabilitätsproblem aufzeigt.
Empfohlene Produkte
Support & Tipps
Mehr zum Lesen
Kann Plex eine GPU mit einem anderen Docker-Container gemeinsam nutzen?
Plex und ein weiterer Container können häufig auf dieselbe GPU zugreifen, aber du musst die Treiberunterstützung, die Gerätezuordnung, die Auslastung der Video-Engine, den Speicher...
So erkennst du, ob ein Plex-Fehler vom Client oder vom Server verursacht wird
Reproduziere dasselbe Element auf einem anderen Client, vergleiche den Sitzungspfad und sammle Serverbelege erst, nachdem der Geltungsbereich dir gezeigt hat, wo der Fehler tatsächlich...
So konfigurierst du den Plex-Cache und den temporären Transcodierungs-Speicher
Schütze den persistenten Plex-Zustand, indem du temporäre Transcodierungsdateien auf geeignetem lokalem Speicher ablegst, und überprüfe anschließend die Bereinigung, den freien Speicherplatz und das Verhalten...
