I file di transcodifica temporanei continuano a riempire l’unità di sistema: come fermarli

Interrompi il carico di transcodifica attivo, verifica dove vengono scritti i segmenti temporanei, quindi imposta la pulizia automatica e sposta il percorso lontano dall’unità di sistema.

Un server multimediale può archiviare segmenti HLS, flussi rimuxati, output con sottotitoli impressi e file di sessione incompleti nella cache predefinita o nella directory dell’applicazione, anche quando la libreria di origine si trova su un ampio pool di archiviazione. L’unità di sistema si riempie quando questi file non vengono eliminati abbastanza rapidamente, la directory di transcodifica è mappata in modo errato o le sessioni abbandonate rimangono dopo la fine della riproduzione. Individua la directory e la sessione effettive prima di eliminare file o spostare la cache.

Individua la directory di transcodifica attiva e le sessioni più grandi

Avvia una transcodifica controllata e osserva quale directory aumenta di dimensioni. Registra l’impostazione dell’applicazione, il percorso del container, il bind mount dell’host, il filesystem, lo spazio disponibile, il numero di file e le sottodirectory delle sessioni più grandi.

Jellyfin espone una posizione scrivibile separata per i file temporanei di transcodifica, confermando che il percorso di transcodifica è distinto dalla libreria multimediale permanente e dal percorso dei metadati. L’impostazione pertinente è il percorso temporaneo di transcodifica.

Se l’applicazione mostra un percorso ma l’unità dell’host si riempie altrove, controlla i mount effettivi di Docker e il livello scrivibile. Un bind mount mancante può fare in modo che il container scriva i file temporanei nel filesystem del container basato sul sistema invece che nel volume cache previsto.

Interrompi il processo produttore prima della pulizia d’emergenza

Individua le sessioni di riproduzione attive e interrompi solo le transcodifiche associate ai file che crescono rapidamente. Salva l’ultimo log di FFmpeg, il titolo della sorgente, il client, il bitrate di output, i sottotitoli e l’ora di avvio prima di recuperare spazio.

In passato, alcuni vecchi file di transcodifica sono rimasti dopo la fine della riproduzione, causando il riempimento del disco fino a impedire l’avvio del server. Un problema di Jellyfin documenta un film che occupava ancora la cartella temporanea di transcodifica ore dopo che l’utente aveva smesso di guardarlo.

Non rimuovere file appartenenti a una sessione attiva mentre FFmpeg li sta ancora scrivendo. Interrompi la sessione o arresta il server correttamente, verifica che i file non siano più aperti, quindi rimuovi solo l’output temporaneo confermato, invece di eliminare l’intera cache o il database dell’applicazione.

Attiva l’eliminazione dei segmenti per le sessioni di streaming lunghe

Verifica se il server elimina i segmenti HLS scaricati durante la riproduzione. Senza l’eliminazione dei segmenti, un film lungo o uno streaming live potrebbe richiedere spazio sufficiente per conservare l’intero output generato.

Jellyfin descrive l’eliminazione dei segmenti come la rimozione dei segmenti meno recenti dopo che il client li ha scaricati, così il server non deve archiviare l’intero file transcodificato. L’opzione esiste specificamente per evitare l’archiviazione dell’intero flusso.

Attivala per un client di prova e monitora la riproduzione, la ricerca e la ripresa. Lasciala disattivata solo quando un problema riproducibile del client richiede la conservazione dei segmenti e compensa con un volume di transcodifica dedicato più grande e una pulizia delle sessioni più rigorosa.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Sposta il percorso di transcodifica su un volume veloce dedicato

Scegli un SSD dedicato, una cache NVMe o un filesystem temporaneo di dimensioni adeguate, separato dalla radice del sistema operativo. La destinazione deve sostenere scritture simultanee e avere capacità sufficiente per le sessioni di transcodifica previste nel caso peggiore.

Gli utenti che collocano le transcodifiche su piccoli dischi RAM hanno richiesto un limite della cache perché la directory può continuare a crescere fino a esaurire il dispositivo temporaneo. Il limite del problema è una cache di transcodifica senza limiti, indipendentemente dal fatto che il dispositivo sottostante sia RAM o SSD.

Arresta il server, crea la nuova directory con la proprietà corretta per il servizio, mappala esplicitamente nel container e aggiorna l’impostazione dell’applicazione indicando il percorso visibile dal container. Esegui una transcodifica e verifica che l’unità di sistema dell’host non aumenti più di dimensioni.

Individua le sessioni obsolete e i problemi di pulizia

Confronta le directory temporanee delle sessioni con gli ID delle sessioni di riproduzione attive e i processi FFmpeg. I file senza una sessione corrispondente, senza processi aperti e con date di modifica obsolete sono candidati alla pulizia supportata.

Non dare per scontato che un’attività generica di pulizia della cache rimuova ogni artefatto di transcodifica. Il precedente report di pulizia di Jellyfin ha rilevato che la normale attività di cache non rimuoveva il file di transcodifica obsoleto; il controllo effettivo consiste quindi nel verificare se la pulizia specifica della sessione è stata completata.

Esamina il log del server in corrispondenza delle disconnessioni dei client, dei riavvii dei container, degli arresti anomali, delle perdite di rete e delle terminazioni forzate dei processi. Risolvi la condizione che impedisce al server di ricevere un evento di arresto corretto, invece di affidarti a uno script di eliminazione giornaliero come unico controllo.

Misura l’ingombro massimo delle transcodifiche simultanee

Esegui una transcodifica remota rappresentativa e misura i byte temporanei al minuto. Ripeti con impressione dei sottotitoli, mappatura dei toni HDR e il bitrate di output massimo supportato, quindi moltiplica il risultato per il numero di sessioni simultanee previste e per la durata della conservazione.

Un’unità di sistema piena può compromettere il server multimediale oltre alla riproduzione. Un caso di assistenza di Jellyfin ha rilevato che le transcodifiche che riempivano l’unità potevano essere correlate alla mancata connessione dell’interfaccia web, dimostrando che l’esaurimento del volume di sistema compromette la disponibilità dell’applicazione.

Riserva spazio libero per il sistema operativo, i log, i database, gli aggiornamenti dei pacchetti e i metadati di Docker. Il volume di transcodifica dovrebbe esaurirsi indipendentemente, senza impedire l’avvio del server o l’apertura dell’applicazione multimediale.

Verifica la pulizia e aggiungi avvisi sulla capacità

Prova l’avvio della riproduzione, la ricerca, la pausa, la disconnessione del client, il riavvio del server e le sessioni simultanee. Conferma che i file attivi crescano solo nel percorso di transcodifica dedicato e si riducano al termine delle sessioni.

La guida di ZimaSpace per la creazione di un server multimediale domestico offre il percorso di convalida più ampio per separare l’archiviazione delle sorgenti dai carichi di lavoro dell’applicazione e temporanei.

La riparazione è completa quando le sessioni obsolete non rimangono più, l’eliminazione dei segmenti funziona per i client supportati, l’unità di sistema conserva una riserva di sicurezza e gli avvisi vengono attivati prima che il volume di transcodifica dedicato o il filesystem radice raggiunga la soglia di capacità.