Jellyfin mostra dati obsoleti dopo una modifica del percorso di archiviazione
Jellyfin mostra solitamente dati obsoleti dopo lo spostamento dello spazio di archiviazione perché il servizio vede il vecchio percorso, non riesce a leggere il nuovo mount oppure non ha completato una scansione valida nella nuova posizione.
La dashboard mostra elementi vecchi, elementi mancanti o una combinazione di entrambi? Non eliminare subito la libreria né svuotare il cestino. Acquisisci i percorsi esatti vecchio e nuovo, lo stato del mount, la proprietà del servizio e il risultato della scansione, così ogni ramo può essere verificato senza distruggere i metadati.
Verifica quale percorso Jellyfin riesce effettivamente a vedere
Controlla il percorso dall’interno del processo o del container Jellyfin, non solo dalla shell dell’host. Verifica che il mount esista dopo l’avvio, che l’account del servizio possa elencare e leggere un file di esempio e che la mappatura del container corrisponda al percorso memorizzato nella configurazione della libreria.
Se il percorso è vuoto o inaccessibile, correggi prima il mount, l’UID/GID o il volume del container. Un mount dello spazio di archiviazione che compare dopo l’accesso manuale può lasciare Jellyfin a scansionare una directory vuota all’avvio.
Confronta il vecchio e il nuovo percorso nella configurazione della libreria e in un record del database. Se sono ancora presenti entrambi, Jellyfin può legittimamente mostrare un elemento valido e un riferimento obsoleto.
Distingui i metadati obsoleti da una scansione non riuscita
Dopo aver reso leggibile il percorso, esegui una scansione controllata e osserva nei log il nome della libreria, il numero di elementi, gli errori di autorizzazione e i file ignorati. Confronta un vecchio elemento noto e un file aggiunto di recente. Se la scansione termina ma rimangono i vecchi percorsi, il database contiene ancora la posizione precedente oppure il nuovo percorso è stato aggiunto senza rimuovere il vecchio riferimento.
Non considerare un poster memorizzato nella cache come prova che il file multimediale sia disponibile. Le regole sui percorsi di archiviazione rendono il filesystem montato e il percorso dell’applicazione due verifiche separate.
Esegui una sola scansione controllata dopo aver corretto la mappatura, quindi confronta il numero di elementi e un file noto. Ripetere le scansioni prima di correggere il percorso può creare uno stato ancora più confuso.
Ripara solo dopo aver verificato il ramo corretto
Correggi la mappatura del percorso o le autorizzazioni, riavvia una sola volta ed esegui una nuova scansione. Se il percorso nel database è errato, aggiorna la posizione della libreria con la modifica più limitata possibile e verifica il numero di elementi previsto prima di eliminare le voci obsolete. Conserva i dati dell’applicazione e un backup prima di eseguire qualsiasi operazione di massa sui metadati.
Il ripristino è verificato quando il servizio continua a vedere il nuovo percorso dopo il riavvio, un client rappresentativo riproduce un elemento e una seconda scansione non ricrea lo stato obsoleto. Procedi all’escalation quando il filesystem segnala corruzione, il database contiene percorsi in conflitto oppure il problema si ripresenta dopo un mount e un riavvio puliti.
Dopo la riparazione, riavvia con il mount disponibile all’avvio e ripeti la scansione. I dati obsoleti non sono risolti finché lo stesso percorso non rimane visibile dopo il riavvio.
Procedi all’escalation quando il percorso continua a ricomparire
Mantieni la mappatura riparata quando un riavvio pulito, una scansione e la riproduzione di un elemento rappresentativo utilizzano tutti il nuovo percorso senza ricreare la vecchia voce.
Interrompi la pulizia quando il vecchio percorso ricompare, il database contiene identità in conflitto oppure il mount dello spazio di archiviazione cambia tra una scansione e l’altra. Conserva prima il database e la mappa dei percorsi attuale.
Procedi al ripristino da un backup o a una riparazione specifica del database quando il filesystem è integro ma i riferimenti obsoleti persistono dopo una mappatura e un riavvio puliti.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Come ottimizzare le connessioni al database di Jellyfin per container simultanei
Inizia con un unico proprietario del database e monitora il comportamento dei blocchi di SQLite; aggiungi un backend diverso solo quando la concorrenza e...
Come impedire la duplicazione di processi o importazioni in Jellyfin
Il lavoro duplicato di solito deriva da pianificatori sovrapposti o da più di un autore; assegna un unico responsabile, un unico percorso e un’unica...
Come riparare Jellyfin dopo che il volume del database si è riempito
Interrompi le scritture, conserva il database e i file WAL, libera spazio senza eliminare indiscriminatamente lo stato, quindi verifica l’integrità e il carico di...
