Så stoppar du en medieserver från att skanna om ett oförändrat bibliotek efter att en nätverksresurs monterats om
En medieserver kan skanna om ett oförändrat bibliotek efter att en nätverksdelning monterats om, om lagringen tillfälligt försvinner eller återkommer med en filsystemsvy som skannern tolkar som ändrad.
Detta är mer specifikt än en vanlig uppstartsskanning. Låt medieserverprocessen fortsätta köras om det är säkert, montera samma SMB- eller NFS-delning medvetet igen och dokumentera vad servern ser före, under och efter övergången. Den viktiga gränsen är om bibliotekssökvägen blir tom, otillgänglig, nyligen monterad eller genererar en annan ändringssignal trots att mediefilerna själva är oförändrade.
Bevisa att omskanningen följer på att delningen monteras om
Inaktivera tillfälligt orelaterade schemalagda skanningar och registrera bibliotekets skanningslogg medan du avmonterar och monterar om en testdelning under ett planerat underhållsfönster. Jämför skanningsutlösaren med en vanlig omstart av servern där delningen aldrig försvinner.
Jellyfin varnar för att otillgänglig lagring kan ta bort objekt om schemalagt underhåll körs medan fjärrmedier saknas.
Om omskanningen börjar först efter övergången för delningen bör du begränsa felsökningen till lagringens synlighet och skannerhändelser. Om servern skannar om utan någon monteringsändring bör du i stället undersöka schemalagda uppgifter eller ett bestående databastillstånd.
Se till att bibliotekssökvägen finns kvar under omintervallet
Inspektera värdens monteringspunkt före, under och efter att fjärrdelningen återansluter. En tom vanlig katalog på samma sökväg kan vara farligare än ett uttryckligt monteringsfel, eftersom medieservern kan tolka den som ett giltigt men tomt bibliotek.
En aktuell felsökningsguide för Jellyfin visar hur monteringsfel kan tömma bibliotek och utlösa omfattande korrigerande skanningar.
Välj helst en monteringsstrategi som tydligt misslyckas i stället för att visa en tom reservkatalog. Validera värdens vy innan medieservercontainern eller -tjänsten får åtkomst till sökvägen igen.
Skilj nätverksfilsystem från lokala ändringsaviseringar
Kontrollera om servern förlitar sig på filsystemsbevakare, periodiska skanningar, återkopplingar från program eller en mediehanterare från tredje part. Fjärrmonteringar levererar inte alltid samma lokala ändringsaviseringar som direktanslutna filsystem.
Plex dokumenterar att nätverksdelningar saknar ändringsutlösare och därför kan kräva periodiska eller uttryckliga skanningar.
Aktivera inte både frekventa periodiska skanningar och omfattande externa uppdateringsanrop som tillfällig lösning. Välj en tillförlitlig strategi för aviseringar så att en ominterval inte skapar flera överlappande skanningar av hela biblioteket.
Gör lagringen klar innan containrar återansluts
Om medieservern körs i Docker ska du jämföra fjärrmonteringens tidpunkt för när den blir klar med containerns start- eller omstartstid. En container kan binda värdens monteringspunkt medan den fortfarande är en tom lokal katalog och senare se NAS-enheten dyka upp under den.
En Linux-guide för hemmaservrar visar att lagringen måste monteras före Docker när program är beroende av fjärrlagring.
Använd ett begränsat monteringsberoende eller en beredskapskontroll i stället för en lång fast väntetid. Medieservern ska antingen starta när det riktiga biblioteket är tillgängligt eller misslyckas så tydligt att den inte kan indexera en tom platshållare.
Förvänta dig inte att Inotify beskriver varje NAS-ändring
I Linux bygger automatisk mediedetektering ofta på händelser från det lokala filsystemet. Kontrollera om en fil som läggs till direkt på NAS-enheten genererar en bevakarhändelse på medieserverns värd och om en ominterval skapar bredare signaler om katalogändringar.
En guide om automatisk montering för hemmaservrar förklarar att Inotify missar ändringar i nätverksfilsystem och rekommenderar uttryckliga programaviseringar när det är lämpligt.
Om bevakarbeteendet är opålitligt kan du använda mediehanteraren eller serverns API för att begära en riktad skanning av nytt innehåll i stället för att tvinga servern att upptäcka hela det oförändrade biblioteket på nytt.
Verifiera en kontrollerad ominterval utan en fullständig omskanning
När du har korrigerat monteringssynlighet, startordning eller skanningsutlösare ska du montera om delningen två gånger medan du övervakar biblioteksdatabasen, antalet objekt och skanningsloggen. Lägg därefter till en testfil för att bevisa att nytt media fortfarande upptäcks korrekt.
En jämförelse för hemmedia noterar att NAS-protokoll ändrar monteringsbeteendet i stället för att medieservern äger fjärrfilsystemet direkt.
Åtgärden är klar när det oförändrade biblioteket överlever en ominterval utan en fullständig omskanning och en ny fil fortfarande visas genom den valda uppdateringsmetoden. Den relaterade ZimaSpace-artikeln om omskanningar i Jellyfin efter omstart är fortfarande rätt spår om problemet bara uppstår efter omstart av värden.
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.
