Så förhindrar du dubbla filminlägg efter ändring av lagringssökvägar
Förhindra dubbla filmer genom att göra de gamla och nya sökvägarna ömsesidigt uteslutande innan medieservern skannar det migrerade biblioteket.
En lagringsmigrering kan göra samma film tillgänglig via två bind-monteringar, två biblioteksrötter, en tillfällig kopia eller en inaktuell databaspost som finns kvar efter att den gamla sökvägen har tagits bort. Det säkraste arbetsflödet är att pausa automatiska skanningar, säkerhetskopiera applikationsdatabasen, kartlägga de exakta gamla och nya sökvägarna, flytta eller kopiera medier under ett kontrollerat tidsfönster, ta bort den föråldrade källan från biblioteket och köra en enda avsiktlig omskanning först när servern bara kan se en enda kanonisk plats.
Kartlägg alla sökvägar som kan nå samma film
Lista biblioteksrötter, Docker-bind-monteringar, symboliska länkar, sammanslagna filsystem, nätverksmonteringar och tillfälliga migreringsmappar. Fastställ en films verkliga sökväg från både värddatorn och containern.
Dubbletter uppstår ofta eftersom skannern tar emot samma fil via en ny sökväg medan den gamla databasposten fortfarande är giltig. En migreringsrapport från Jellyfin återskapade problemet när biblioteksmappar flyttades och skapade dubbletter.
Välj en kanonisk containersökväg, till exempel /media/movies, och håll den stabil även om värddatorns lagringskälla ändras. En stabil containersökväg minskar framtida förändringar i databasen eftersom applikationen inte behöver lära sig en ny plats för varje migrering mellan lagringspooler eller enheter.
Pausa automatiska skanningar innan du kopierar eller byter namn på medier
Inaktivera realtidsövervakning och schemalagda biblioteksskanningar under migreringen. Annars kan servern indexera ofullständiga kopior, se båda platserna eller registrera samma titel medan mappar byter namn i flera steg.
Säkerhetskopiera medieserverns konfiguration och databas innan du ändrar sökvägar. Det skyddar visningsstatus, val av omslag, samlingar, användare och leverantörsidentifierare som kanske inte kan återskapas exakt vid en ombyggnad av ett rent bibliotek.
Kopiera eller flytta först en liten testmapp, verifiera kontrollsummor eller filstorlekar och låt den gamla källan vara orörd tills den nya platsen kan läsas av tjänstekontot. Låt inte båda sökvägarna vara aktiva biblioteksrötter under detta verifieringsfönster.
Ta bort den gamla bibliotekssökvägen innan du skannar den nya
När den nya sökvägen har verifierats tar du bort den föråldrade mappen från bibliotekskonfigurationen eller mappar om den befintliga containersökvägen till den nya källan på värddatorn. Bekräfta att den gamla sökvägen inte längre kan nås via ett annat bibliotek eller en symbolisk länk.
Att ta bort en sökväg rensar inte alltid alla tillhörande poster omedelbart. Ett Jellyfin-ärende rapporterar att metadata som var kopplad till borttagna sökvägar fanns kvar, vilket är anledningen till att sökvägsrensningen måste verifieras och inte bara antas.
Kör applikationens stödda biblioteksrensning eller fullständiga skanning först när den gamla källan inte längre är tillgänglig. Undvik att redigera databasen manuellt om du inte har en testad säkerhetskopia och en återställningsplan som är specifik för versionen.
Bevara medieidentiteten medan filerna flyttas
Håll filmappnamn, filnamn, årtal, utgåveetiketter, leverantörsidentifierare och lokala metadatafiler konsekventa. En titel som byter namn under samma migrering kan behandlas som ett annat objekt även när videobytarna är oförändrade.
Lagra lokala metadata och omslag på ett genomtänkt sätt. Om identifierare som TMDB- eller IMDb-ID:n finns inbäddade i namn eller NFO-filer ska du bevara dem så att den nya sökvägen kopplas till samma filmidentitet i stället för en andra tvetydig träff.
ZimaSpaces arbetsflöde för NAS-datamigrering är den kompletterande kontrollen för att skydda källdata och validera behörigheter innan den gamla kopian tas bort.
Skilj mellan två sökvägar och två versioner eller utgåvor
Öppna båda dubblettposterna och jämför deras filsökvägar, medieinformation, leverantörsidentifierare, speltid, utgåveetiketter och tillgänglighet. Två poster kan vara samma fil via två sökvägar, två fysiska kopior eller legitima versioner som har grupperats felaktigt.
Inaktuella poster kan förbli åtkomliga efter att en sökväg försvinner. En Jellyfin-rapport kallar dessa skenposter, som inte ska förväxlas med en andra verklig filmfil.
Om båda posterna pekar på aktiva sökvägar tar du bort den oavsiktliga sökvägen från bibliotekets omfattning. Om en sökväg inte längre finns använder du den stödda rensningsprocessen och verifierar att posten försvinner. Om filerna är avsiktliga utgåvor använder du medieserverns stödda regler för namngivning och gruppering i stället för att ta bort en av dem på måfå.
| Mönster för dubblett | Trolig orsak | Rätt åtgärd |
|---|---|---|
| Två poster, två aktiva sökvägar | Gamla och nya rötter skannas båda | Behåll en kanonisk sökväg |
| Två poster, en inaktuell sökväg | Inaktuell databaspost | Rensa biblioteket efter säkerhetskopiering |
| Två filer, samma titel | Migreringskopian finns fortfarande kvar | Verifiera och avveckla den gamla kopian |
| Två avsiktliga utgåvor | Felaktig namngivning eller gruppering | Använd stödd namngivning för utgåvor |
Denna klassificering förhindrar att en databasrensning tar bort en legitim alternativ version eller en version med högre kvalitet.
Kör en kontrollerad omskanning och verifiera resultatet
Aktivera skanning igen först när den kanoniska sökvägen är monterad, den gamla sökvägen är borta och tjänsteanvändaren kan läsa den nya platsen. Starta en fullständig skanning och håll utkik efter händelser för borttagning och tillägg kring den migrerade filmen.
Vissa bibliotek har misslyckats med att ta bort filer efter en lagringsflytt även efter att den gamla sökvägen tagits bort från inställningarna. En Jellyfin-rapport dokumenterar att borttagna filer blev kvar i biblioteket, så den slutliga kontrollen måste jämföra databasposter med verkliga sökvägar.
Verifiera att varje film visas en gång, öppnas från den nya sökvägen, behåller visningsstatus och samlingar samt fortfarande fungerar efter en omstart av tjänsten. Håll den gamla lagringen frånkopplad men intakt tills denna granskning är godkänd. Avveckla den sedan enligt säkerhetskopierings- och migreringsplanen.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
