Varför visar ett fotobibliotek dubbletter först efter att ett externt bibliotek har aktiverats?
Dubbletter som endast visas efter att ett externt bibliotek har aktiverats innebär vanligtvis att samma foto har lagts in i databasen via två olika importvägar.
Börja inte med att radera kort som ser identiska ut. Ta först reda på om programmet skapade två poster för en fysisk fil, indexerade en uppladdad kopia tillsammans med originalet i det externa biblioteket eller hittade en genuint annan redigerad fil. Lösningen är att ta bort den överlappande importgränsen och samtidigt bevara den auktoritativa tillgången och dess ägarskap.
Fastställ om dubbletten är fysisk eller databasspecifik
Välj ett duplicerat foto och jämför dess filsökväg, storlek, kontrollsumma, fotograferingstidpunkt och biblioteks-ID. Två kort i gränssnittet innebär inte automatiskt att det finns två fysiska kopior.
Hantering av tillgångar i externa bibliotek kan visa filer som redan har laddats upp via en annan väg, vilket skapar två programposter även när hushållet bara lagrar en underliggande bild.
Om båda posterna hänvisar till samma fysiska innehåll via olika biblioteksrötter är detta ett problem med importgränsen. Om det faktiskt finns två filer bör du i stället felsöka kopieringsflödet.
Kartlägg alla sökvägar som kan indexera samma mapp
Skriv ned uppladdningskatalogen, rötterna för externa bibliotek, bind-monteringar, synkroniseringsmål och eventuella kapslade mappar som pekar tillbaka in i ett annat indexerat träd.
Självhostade fotolösningar skiljer ofta mellan hanterade uppladdningar och bevakad lagring. Om du förstår dessa biblioteksgränser i Immich blir det enklare att upptäcka överlappande rötter än att leta efter en generell knapp för att ta bort dubbletter i gränssnittet.
Inaktivera eller begränsa en överlappande källa i ett testbibliotek. Om den andra posten försvinner efter en reskanning som stöds, samtidigt som filen fortfarande är åtkomlig, bör du behålla en enda auktoritativ importväg.
Skilj på ägarskap och filidentitet
Jämför vem som äger varje bibliotekspost och om den ena kopian laddades upp av en användare medan det externa biblioteket indexerar samma fil för en administratör eller ett tjänstekonto.
En typisk självhostad lagringssökväg för Immich använder flera tjänster och lagringsplatser. Därför kan identiska byte komma in i programmet med olika ägarskap eller regler för livscykelhantering.
Sammanfoga inte poster blint när ägarskapet påverkar album, delning, radering eller ansiktsmetadata. Välj den sökväg vars livscykel motsvarar hur hushållet förväntar sig att fotot ska hanteras.
Kontrollera exakta kopior mot redigerade varianter
Jämför kontrollsummor och bilddimensioner innan du raderar något. En redigering i telefonen, en export med tillämpad sidofil eller en omskrivning av metadata kan se identisk ut i galleriet men ändå vara en genuint annan fil.
Lagringsplanering för Immich betonar genomtänkt extern lagringsplanering för Immich. Den skillnaden är viktig när ett externt träd innehåller original, redigerade exporter och redan importerade hanterade kopior bredvid varandra.
Använd bevis från exakt innehåll för verkliga dubbletter och behåll redigerade derivat när de innehåller avsiktliga ändringar. Enbart visuell likhet är ingen säker regel för radering.
Välj en enda importgräns och verifiera
När du har valt den auktoritativa källan ska du endast ta bort den överlappande biblioteksdefinitionen eller den duplicerade hanterade kopian med programmets stödda åtgärder. Behåll en oberoende säkerhetskopia tills album- och delningsbeteendet har verifierats.
Det relaterade ZimaSpace-arbetsflödet för migrering av dubblettfoton är användbart här eftersom det behandlar rensning av dubbletter som ett migreringsbeslut i stället för en genväg för massradering.
Testa igen med en ny uppladdning från telefonen och en fil som läggs till i den externa mappen. Lösningen är stabil när varje ny tillgång importeras exakt en gång och finns kvar efter en reskanning utan att skapa en andra post.
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.
