Les fichiers de transcodage temporaires continuent de remplir le disque système : comment y remédier ?

Arrêtez la tâche de transcodage active, vérifiez où sont écrits les segments temporaires, puis appliquez leur nettoyage et déplacez le chemin hors du disque système.

Un serveur multimédia peut stocker des segments HLS, des flux remultiplexés, des sorties avec sous-titres incrustés et des fichiers de session incomplets dans son cache par défaut ou son répertoire d’application, même lorsque la bibliothèque source se trouve sur un grand pool de stockage. Le disque système se remplit lorsque ces fichiers ne sont pas supprimés assez rapidement, lorsque le répertoire de transcodage est mal mappé ou lorsque des sessions abandonnées subsistent après la fin de la lecture. Identifiez le répertoire et la session concernés avant de supprimer des fichiers ou de déplacer le cache.

Localiser le répertoire de transcodage actif et ses sessions les plus volumineuses

Lancez un transcodage contrôlé et observez quel répertoire augmente. Notez le paramètre de l’application, le chemin du conteneur, le montage lié de l’hôte, le système de fichiers, l’espace disponible, le nombre de fichiers et les sous-répertoires de session les plus volumineux.

Jellyfin expose un emplacement accessible en écriture distinct pour les fichiers temporaires de transcodage, ce qui confirme que le chemin de transcodage est distinct de celui de la bibliothèque multimédia permanente et des métadonnées. Le paramètre concerné est le chemin temporaire de transcodage.

Si l’application affiche un chemin, mais que le disque de l’hôte se remplit ailleurs, inspectez les montages effectifs de Docker et sa couche accessible en écriture. L’absence d’un montage lié peut amener le conteneur à écrire les fichiers temporaires dans le système de fichiers du conteneur adossé au disque système, au lieu du volume de cache prévu.

Arrêter le processus producteur avant le nettoyage d’urgence

Identifiez les sessions de lecture actives et arrêtez uniquement les transcodages associés aux fichiers qui augmentent rapidement. Enregistrez le dernier journal FFmpeg, le titre source, le client, le débit de sortie, les sous-titres et l’heure de début avant de récupérer de l’espace.

Des fichiers de transcodage obsolètes sont déjà restés présents après la fin de la lecture, provoquant le remplissage du disque jusqu’à empêcher le démarrage du serveur. Un problème Jellyfin documente un film occupant encore le dossier temporaire de transcodage plusieurs heures après l’arrêt du visionnage.

Ne supprimez pas les fichiers appartenant à une session active pendant que FFmpeg les écrit encore. Arrêtez proprement la session ou le serveur, confirmez que les fichiers ne sont plus ouverts, puis supprimez uniquement les sorties temporaires identifiées, plutôt que de supprimer l’intégralité du cache ou de la base de données de l’application.

Activer la suppression des segments pour les longues sessions de streaming

Vérifiez si le serveur supprime les segments HLS téléchargés pendant la lecture. Sans suppression des segments, un long film ou un flux en direct peut nécessiter suffisamment d’espace disque pour conserver l’intégralité de la sortie générée.

Jellyfin décrit la suppression des segments comme l’élimination des anciens segments après leur téléchargement par le client, afin que le serveur n’ait pas besoin de stocker le fichier transcodé complet. Cette option existe précisément pour éviter le stockage du flux complet.

Activez-la pour un client de test et surveillez la lecture, la recherche et la reprise. Ne la désactivez que lorsqu’un problème reproductible du client exige de conserver les segments, et compensez avec un volume de transcodage dédié plus grand ainsi qu’un nettoyage plus strict des sessions.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Déplacer le chemin de transcodage vers un volume rapide dédié

Choisissez un SSD dédié, un cache NVMe ou un système de fichiers temporaire suffisamment dimensionné, distinct de la racine du système d’exploitation. La destination doit prendre en charge les écritures simultanées et disposer d’une capacité suffisante pour les sessions de transcodage les plus exigeantes prévues.

Des utilisateurs qui placent les transcodages sur de petits disques RAM ont demandé une limite de cache, car le répertoire peut continuer à croître jusqu’à épuiser le périphérique temporaire. Le problème est un cache de transcodage non limité, que le périphérique sous-jacent soit une mémoire RAM ou un SSD.

Arrêtez le serveur, créez le nouveau répertoire avec les droits du service appropriés, mappez-le explicitement dans le conteneur et mettez à jour le paramètre de l’application avec le chemin visible depuis le conteneur. Lancez un transcodage et vérifiez que le disque système de l’hôte n’augmente plus.

Rechercher les sessions obsolètes et les échecs de nettoyage

Comparez les répertoires de session temporaires avec les identifiants des sessions de lecture actives et les processus FFmpeg. Les fichiers sans session correspondante, sans processus ouvert et dont la date de modification est ancienne sont des candidats à un nettoyage pris en charge.

Ne supposez pas qu’une tâche générique de nettoyage du cache supprime tous les artefacts de transcodage. Le précédent rapport de nettoyage Jellyfin a établi que la tâche normale du cache n’avait pas supprimé le fichier de transcodage obsolète ; la vérification réelle consiste donc à déterminer si le nettoyage spécifique de la session est terminé.

Examinez le journal du serveur autour des déconnexions des clients, des redémarrages du conteneur, des plantages, des pertes réseau et des arrêts forcés de processus. Corrigez la condition qui empêche le serveur de recevoir un événement d’arrêt propre, plutôt que de vous en remettre uniquement à un script de suppression quotidien.

Mesurer l’empreinte maximale de transcodage simultané

Lancez un transcodage distant représentatif et mesurez le nombre d’octets temporaires générés par minute. Recommencez avec l’incrustation des sous-titres, le mappage de tons HDR et le débit de sortie maximal pris en charge, puis multipliez le résultat par le nombre de sessions simultanées prévu et la durée de conservation.

Un disque système plein peut affecter le serveur multimédia au-delà de la lecture. Un cas d’assistance Jellyfin a indiqué que des transcodages remplissant le disque pouvaient être liés à l’impossibilité de se connecter à l’interface web, montrant que l’épuisement du volume système affecte la disponibilité de l’application.

Réservez de l’espace libre pour le système d’exploitation, les journaux, les bases de données, les mises à jour des paquets et les métadonnées Docker. Le volume de transcodage doit pouvoir tomber en panne indépendamment, sans empêcher le démarrage du serveur ni l’ouverture de l’application multimédia.

Vérifier le nettoyage et ajouter des alertes de capacité

Testez le démarrage de la lecture, la recherche, la pause, la déconnexion du client, le redémarrage du serveur et les sessions simultanées. Confirmez que les fichiers actifs augmentent uniquement dans le chemin de transcodage dédié et diminuent une fois les sessions terminées.

Le guide ZimaSpace consacré à la création d’un serveur multimédia domestique fournit la procédure de validation générale pour séparer le stockage source des charges de travail applicatives et temporaires.

La réparation est terminée lorsque les sessions obsolètes ne subsistent plus, que la suppression des segments fonctionne pour les clients pris en charge, que le disque système conserve une réserve suffisante et que les alertes se déclenchent avant que le volume de transcodage dédié ou le système de fichiers racine n’atteigne son seuil de capacité.