Kun je je kijkgeschiedenis behouden tijdens een migratie van je mediaserver?

Ja, de kijkgeschiedenis kan behouden blijven wanneer de migratie de gebruikersdatabase, media-identiteit en compatibele applicatiestatus naar de nieuwe server overzet.

Alleen filmbestanden kopiëren verplaatst geen afgespeelde markeringen, hervatposities, favorieten, gebruikersaccounts of keuzes per track. Deze gegevens staan in de permanente database van de mediaserver en zijn gekoppeld aan gebruikers- en media-identificatoren. De veiligste aanpak is een volledige migratie van een instantie op hetzelfde platform, met een consistente back-up terwijl de server is gestopt, overeenkomende versies, stabiele containerpaden en een geïsoleerde hersteltest voordat de bestemming de actieve server wordt.

Bepaal of u een instantie verplaatst of van platform wisselt

Een migratie van dezelfde applicatie van de ene host naar de andere kan doorgaans de volledige serverstatus behouden. Een overstap van Plex naar Jellyfin, van Emby naar Jellyfin of naar een ander platform vereist een export, synchronisatieservice, plug-in of API-gebaseerde vertaling, omdat de databases verschillende schema’s en identificatoren gebruiken.

Jellyfin-gebruikers hebben juist om een eenvoudigere export van accounts, kijkgeschiedenis en gebruikersinstellingen gevraagd, omdat gebruikersgegevens niet simpelweg een kopie van een mediamap zijn.

Kies één route voordat u begint: een volledig herstel van de instantie voor dezelfde mediaserver, of een gedocumenteerde overdracht van de kijkstatus bij een platformwijziging. Combineer beide niet door slechts een deel van één database naar een nieuw gescande bestemming te kopiëren.

Maak een back-up van de volledige permanente serverstatus

Breng de configuratie, database, gebruikers, plug-ins, metadata, certificaten, instellingen voor geplande taken en containeromgeving in kaart. Noteer de actieve applicatieversie, image-tag, databaselocatie en alle permanente mounts.

De kijkstatus kan meer omvatten dan een booleaanse waarde. In een Jellyfin-discussie worden velden genoemd zoals afgespeelde status, aantal keer afgespeeld, afspeelpositie, datum van laatste keer afspelen, favorieten en geselecteerde streams in de gebruikersgegevens.

Maak een back-up van de volledige ondersteunde persistentieset in plaats van slechts één tabel te exporteren, tenzij er geen volledig herstelpad bestaat. Een gedeeltelijke transplantatie van de database kan één veld behouden, maar tegelijkertijd gebruikers-ID’s, mediaverwijzingen, schema-verwachtingen of nieuwere migratiegeschiedenis beschadigen.

Stop de server of gebruik een database-consistente snapshot

Voorkom afspelen, scans, metadata-updates en wijzigingen door gebruikers terwijl de laatste back-up wordt gemaakt. Stop het proces van de mediaserver voordat u SQLite-bestanden kopieert, tenzij de opslag en applicatie een consistente online back-upmethode ondersteunen.

Een Jellyfin-back-updiscussie waarschuwt dat het kopiëren van actieve SQLite-bestanden een inconsistente status kan vastleggen, omdat de database mogelijk in gebruik is tijdens een gewone back-up van het bestandssysteem.

Leg na het stoppen van de service controlesommen en bestandsgroottes vast en houd de bronserver ongewijzigd totdat de bestemming de controle heeft doorstaan. Laat beide servers tijdens de omschakeling nooit naar dezelfde database of hetzelfde doel voor synchronisatie van de kijkstatus schrijven.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Houd applicatieversies en de upgraderichting onder controle

Herstel indien mogelijk eerst naar dezelfde applicatieversie. Controleer voordat u de bestemming upgradet of plug-ins, databaseschema en containerpaden overeenkomen.

Databasemigraties kunnen eenrichtingsverkeer zijn en een herstelde instantie kan mislukken wanneer de vastgelegde migratiestatus niet overeenkomt met het daadwerkelijke schema. Een actueel Jellyfin-probleem beschrijft een conflict in de herstelde migratiestatus.

Start de herstelde server zonder openbare clienttoegang, lees het migratielogboek en maak een nieuwe snapshot voordat u een upgrade uitvoert. Test nooit een nieuwere release met de enige kopie van de database en verwacht daarna dat de oude serverversie deze opnieuw kan openen.

Behoud stabiele mediapaden en itemidentiteit

Houd dezelfde paden zichtbaar in de container, ook als de hostschijven veranderen. Koppel bijvoorbeeld een nieuwe opslagpool aan de bestaande paden /media/movies en /media/tv in plaats van de bestemming volledig nieuwe bibliotheekroots aan te leren.

Door paden te wijzigen kunnen nieuwe mediarecords ontstaan of kunnen verouderde vermeldingen naast de herstelde records blijven staan. Een Jellyfin-probleem koppelt verwijderde bibliotheekpaden aan blijvende verouderde metadata en dubbel gedrag bij verder kijken.

Controleer één film en één aflevering op basis van bestandspad en interne itemidentiteit voordat u een volledige scan start. Als de bestemming elk bestand als nieuw ziet, stop dan en corrigeer de padkoppeling voordat koppelingen naar de kijkstatus over dubbele records worden verspreid.

Houd gebruikers en hun identificatoren consistent

Herstel gebruikers met de database in plaats van accounts handmatig opnieuw aan te maken met dezelfde zichtbare namen. Een zichtbare gebruikersnaam bewijst niet dat de gebruiker op de bestemming dezelfde interne identificator heeft.

Bij handmatig herstel van de geschiedenis wordt vaak de tabel met gebruikersgegevens gebruikt, maar de records zijn afhankelijk van zowel gebruikers- als mediaverwijzingen. Het verplaatsen van bibliotheeklocaties zonder metadata te verliezen vereist daarom zorgvuldige pad- en databaseverwerking in plaats van een blinde nieuwe scan van verplaatste bestanden.

Log na het herstel in als elke representatieve gebruiker en vergelijk afgespeelde markeringen, items die nog bezig zijn, hervatposities, favorieten, audiokeuzes en ondertitelkeuzes. Beoordeel het resultaat niet alleen vanuit het beheerdersaccount.

Gebruik een synchronisatie- of exportroute voor platformoverschrijdende migraties

Wanneer de bron- en doelapplicatie verschillen, exporteer de geschiedenis dan via een ondersteunde plug-in, API-tool of neutrale service zoals een platform voor het bijhouden van kijkgeschiedenis. Test een kleine steekproef voordat u de volledige bibliotheek synchroniseert.

Koppel gebruikers en titels expliciet en beschouw afleveringen, edities, alternatieve versies en hernoemde bestanden als mogelijke identiteitsconflicten. Alleen een filmtitel is te weinig onderscheidend wanneer meerdere jaren of versies dezelfde naam hebben.

Bewaar een export van de brongeschiedenis, ook nadat de eerste import is geslaagd. De overdracht moet herhaalbaar of controleerbaar zijn, zodat ontbrekende gebruikers en verkeerd gekoppelde titels kunnen worden gecorrigeerd zonder de migratie opnieuw te moeten starten.

Voer een geïsoleerd herstel uit en schakel pas over na controle

Start de bestemming op een tijdelijke poort, met geplande scans, webhooks en externe synchronisatie uitgeschakeld. Controleer gebruikers, bibliotheektellingen, aantallen bekeken items, hervatposities, afspeellijsten, collecties en verschillende willekeurig geselecteerde titels.

De NAS-datamigratieworkflow van ZimaSpace geeft de bredere richtlijn: behoud de bron totdat de gekopieerde status vanaf de bestemming is gecontroleerd.

De migratie is pas voltooid wanneer de herstelde instantie een herstart doorstaat, de paden stabiel blijven, representatieve gebruikers hun geschiedenis behouden en nieuwe afspeelactiviteiten de bestemming correct bijwerken. Houd de bron offline maar herstelbaar totdat de nieuwe server meerdere dagen normaal heeft gewerkt en er een nieuwe back-up is gemaakt.