Kannst du den Wiedergabeverlauf während der Migration eines Medienservers beibehalten?

Ja, der Wiedergabeverlauf kann erhalten bleiben, wenn bei der Migration die Benutzerdatenbank, die Medienidentität und der kompatible Anwendungsstatus auf den neuen Server übertragen werden.

Das alleinige Kopieren von Filmdateien überträgt keine Wiedergabemarkierungen, Fortsetzungspositionen, Favoriten, Benutzerkonten oder Auswahloptionen pro Titel. Diese Datensätze befinden sich in der persistenten Datenbank des Medienservers und sind mit Benutzer- und Medienkennungen verknüpft. Am sichersten ist eine vollständige Migration einer Instanz auf derselben Plattform mit einem konsistenten Backup im gestoppten Zustand, übereinstimmenden Versionen, stabilen Containerpfaden und einem isolierten Wiederherstellungstest, bevor das Ziel zum aktiven Server wird.

Festlegen, ob Sie eine Instanz verschieben oder die Plattform wechseln

Eine Migration derselben Anwendung von einem Host auf einen anderen kann normalerweise den vollständigen Serverstatus bewahren. Der Wechsel von Plex zu Jellyfin, von Emby zu Jellyfin oder von einer anderen Plattform erfordert hingegen einen Export, einen Synchronisierungsdienst, ein Plugin oder eine API-basierte Übersetzung, da die Datenbanken unterschiedliche Schemata und Kennungen verwenden.

Jellyfin-Benutzer haben sich ausdrücklich einen einfacheren Export für Konten, Wiedergabeverlauf und Benutzereinstellungen gewünscht, weil Benutzerdaten nicht einfach durch das Kopieren eines Medienordners übertragen werden.

Wählen Sie vor Beginn einen Weg: vollständige Wiederherstellung der Instanz bei demselben Medienserver oder eine dokumentierte Übertragung des Wiedergabestatus beim Plattformwechsel. Kombinieren Sie beides nicht, indem Sie nur einen Teil einer Datenbank in ein neu gescanntes Ziel kopieren.

Den vollständigen persistenten Serverstatus sichern

Erfassen Sie Konfiguration, Datenbank, Benutzer, Plugins, Metadaten, Zertifikate, Einstellungen geplanter Aufgaben und die Containerumgebung. Notieren Sie die laufende Anwendungsversion, den Image-Tag, den Datenbankpfad und alle persistenten Einbindungen.

Der Wiedergabestatus kann mehr als nur einen booleschen Wert umfassen. In einer Jellyfin-Diskussion werden Felder wie Wiedergabestatus, Wiedergabeanzahl, Wiedergabeposition, Datum der letzten Wiedergabe, Favoriten und ausgewählte Streams in den Benutzerdatensätzen genannt.

Sichern Sie den gesamten unterstützten Persistenzbestand, statt nur eine Tabelle zu exportieren, sofern kein vollständiger Wiederherstellungsweg existiert. Eine teilweise Übertragung der Datenbank kann zwar ein einzelnes Feld bewahren, aber Benutzerkennungen, Medienreferenzen, Schemaanforderungen oder den Verlauf neuerer Migrationen beschädigen.

Den Server stoppen oder einen datenbankkonsistenten Snapshot verwenden

Verhindern Sie während der Erstellung des endgültigen Backups Wiedergabe, Scans, Metadatenaktualisierungen und Benutzeränderungen. Stoppen Sie den Medienserverprozess, bevor Sie SQLite-Dateien kopieren, sofern Speicher und Anwendung keine konsistente Online-Sicherung unterstützen.

Eine Jellyfin-Backup-Diskussion warnt davor, dass das Kopieren aktiver SQLite-Dateien einen inkonsistenten Zustand erfassen kann, weil die Datenbank möglicherweise gerade verwendet wird, während ein gewöhnliches Dateisystem-Backup läuft.

Erfassen Sie nach dem Stoppen des Dienstes Prüfsummen und Dateigrößen und lassen Sie den Quellserver unverändert, bis das Ziel die Überprüfung bestanden hat. Lassen Sie niemals beide Server während der Umstellung in dieselbe Datenbank oder dasselbe Ziel für die Synchronisierung des Wiedergabestatus schreiben.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Anwendungsversionen und Upgraderichtung kontrolliert halten

Stellen Sie die Wiederherstellung nach Möglichkeit zunächst in derselben Anwendungsversion her. Prüfen Sie, ob Plugins, Datenbankschema und Containerpfade übereinstimmen, bevor Sie das Ziel aktualisieren.

Datenbankmigrationen können nur in eine Richtung funktionieren, und eine wiederhergestellte Instanz kann ausfallen, wenn ihr aufgezeichneter Migrationsstatus nicht mit dem tatsächlichen Schema übereinstimmt. Ein aktuelles Jellyfin-Problem dokumentiert einen Konflikt des wiederhergestellten Migrationsstatus.

Starten Sie den wiederhergestellten Server ohne öffentlichen Clientzugriff, lesen Sie das Migrationsprotokoll und erstellen Sie vor jedem Upgrade einen weiteren Snapshot. Testen Sie niemals eine neuere Version mit der einzigen Datenbankkopie und erwarten Sie anschließend, dass die alte Serverversion sie wieder öffnen kann.

Stabile Medienpfade und Medienidentität bewahren

Behalten Sie dieselben im Container sichtbaren Pfade bei, auch wenn sich die Hostdatenträger ändern. Ordnen Sie beispielsweise einen neuen Speicherpool wieder den vorhandenen Pfaden /media/movies und /media/tv zu, anstatt dem Ziel vollständig neue Bibliotheksstammverzeichnisse beizubringen.

Geänderte Pfade können neue Medieneinträge erzeugen oder veraltete Einträge neben den wiederhergestellten zurücklassen. Ein Jellyfin-Problem verknüpft entfernte Bibliothekspfade mit dauerhaft veralteten Metadaten und doppelten Einträgen bei „Weiter ansehen“.

Überprüfen Sie anhand des Dateipfads und der internen Medienidentität je einen Film und eine Episode, bevor Sie einen vollständigen Scan starten. Wenn das Ziel jede Datei als neu erkennt, halten Sie an und korrigieren Sie die Pfadzuordnung, bevor Verknüpfungen zum Wiedergabestatus auf doppelte Datensätze verteilt werden.

Benutzer und ihre Kennungen konsistent halten

Stellen Sie Benutzer zusammen mit der Datenbank wieder her, statt Konten manuell unter denselben Anzeigenamen neu anzulegen. Ein sichtbarer Benutzername beweist nicht, dass der Zielbenutzer dieselbe interne Kennung besitzt.

Bei der manuellen Wiederherstellung des Verlaufs wird häufig die Benutzerdatentabelle bearbeitet, doch die Datensätze hängen sowohl von Benutzer- als auch von Medienreferenzen ab. Das Verschieben von Bibliotheksorten ohne Verlust der Metadaten erfordert daher eine sorgfältige Behandlung von Pfaden und Datenbank statt eines unkontrollierten erneuten Scans verschobener Dateien.

Melden Sie sich nach der Wiederherstellung mit jedem repräsentativen Benutzer an und vergleichen Sie Wiedergabemarkierungen, begonnene Titel, Fortsetzungspositionen, Favoriten, Audioauswahl und Untertitelauswahl. Beurteilen Sie den Erfolg nicht ausschließlich anhand des Administratorkontos.

Für plattformübergreifende Migrationen einen Synchronisierungs- oder Exportweg verwenden

Wenn Quell- und Zielanwendung unterschiedlich sind, exportieren Sie den Verlauf über ein unterstütztes Plugin, ein API-Tool oder einen neutralen Dienst wie eine Plattform zur Verfolgung angesehener Inhalte. Testen Sie vor der Synchronisierung der gesamten Bibliothek zunächst eine kleine Auswahl.

Ordnen Sie Benutzer und Titel ausdrücklich zu und betrachten Sie Episoden, Editionen, alternative Schnittfassungen und umbenannte Dateien als mögliche Identitätskonflikte. Ein Filmtitel allein ist zu ungenau, wenn mehrere Jahrgänge oder Versionen denselben Namen tragen.

Bewahren Sie auch nach dem erfolgreichen ersten Import einen Export des Quellverlaufs auf. Die Übertragung sollte wiederholbar oder prüfbar sein, damit fehlende Benutzer und falsch zugeordnete Titel korrigiert werden können, ohne die Migration von vorn zu beginnen.

Eine isolierte Wiederherstellung durchführen und erst nach der Prüfung umstellen

Starten Sie das Ziel an einem temporären Port und deaktivieren Sie geplante Scans, Webhooks und externe Synchronisierungen. Überprüfen Sie Benutzer, Bibliotheksanzahl, Wiedergabestatistiken, Fortsetzungspositionen, Wiedergabelisten, Sammlungen und mehrere zufällig ausgewählte Titel.

Der NAS-Datenmigrationsablauf von ZimaSpace stellt die übergeordnete Regel auf: Bewahren Sie die Quelle, bis der kopierte Zustand vom Ziel aus überprüft wurde.

Die Migration ist erst abgeschlossen, wenn die wiederhergestellte Instanz einen Neustart übersteht, die Pfade stabil bleiben, repräsentative Benutzer ihren Verlauf behalten und neue Wiedergaben das Ziel korrekt aktualisieren. Halten Sie die Quelle offline, aber wiederherstellbar, bis der neue Server mehrere Tage normalen Betriebs und ein frisches Backup erfolgreich absolviert hat.