Lorsque Jellyfin fonctionne avant un redémarrage, mais que la lecture échoue ensuite, vérifiez les dépendances qui devaient être rétablies au démarrage avant de modifier la bibliothèque.
Le redémarrage peut modifier le moment du montage, les mappages des périphériques du conteneur, les autorisations, le DNS ou l’ordre dans lequel les services deviennent disponibles. Un processus Jellyfin sain ne garantit pas que son chemin d’accès aux médias ou son GPU sont utilisables. Comparez l’environnement après démarrage avec la référence fonctionnelle et réparez la première dépendance manquante.
Vérifiez que le montage des médias est réellement monté
Un répertoire peut exister même lorsque le NAS ou le disque qui l’occupe habituellement ne s’est pas monté. Jellyfin peut alors voir un chemin local vide et signaler l’absence de médias plutôt qu’une erreur de montage évidente.
La vérification du montage avant le démarrage des services empêche les applications d’écrire dans un point de montage vide ou d’y rechercher des fichiers.
Confirmez l’identité du système de fichiers avec `findmnt` ou l’équivalent de votre plateforme, puis lisez un fichier multimédia connu avec le compte du service Jellyfin. Ne relancez pas l’analyse tant que le stockage prévu n’est pas présent.
Vérifiez les propriétaires des données de l’application après le retour de l’environnement d’exécution
La recréation du conteneur ou des modifications de l’hôte peuvent changer l’utilisateur numérique qui accède à la configuration persistante. Le simple accès en lecture ne suffit pas, car Jellyfin doit également mettre à jour l’état de sa base de données et de sa configuration.
Les services conteneurisés restent prévisibles lorsque la correspondance des UID et GID concorde avec les propriétaires du système de fichiers sur les montages liés.
Effectuez un test temporaire de création et de suppression dans le répertoire parent des données de l’application avec l’identité du service. Le chemin persistant des données de l’application doit rester intact après le remplacement de l’environnement d’exécution, sans réparation récursive des propriétaires.
Confirmez que les périphériques matériels sont réapparus
Une transcodification qui utilisait l’iGPU avant le redémarrage peut basculer vers le processeur ou échouer si `/dev/dri` ou un autre mappage d’accélérateur est manquant. La lecture directe peut tout de même fonctionner, donnant l’impression que la panne concerne uniquement les médias.
Un mappage de périphérique défaillant peut faire passer la même lecture du matériel au logiciel ; un test de performance de transcodification Jellyfin montre à quel point la charge du processeur et du GPU varie entre les chemins accélérés matériellement et les chemins filtrés.
Lancez un test connu de transcodification matérielle et inspectez le processus actif ainsi que le mappage du périphérique. Réparez l’accès du périphérique dans l’environnement d’exécution avant de réduire la qualité ou de changer de codec.
Testez à nouveau le chemin réseau uniquement après le bon fonctionnement de la lecture locale
Les services DNS distants, VPN ou proxy peuvent démarrer après Jellyfin et provoquer une panne limitée à l’accès distant. Traitez la lecture locale et l’accessibilité distante comme deux tests de validation distincts.
La capacité réseau doit être vérifiée au niveau réel de diffusion ; un modèle de bande passante pour le streaming distingue les limites du LAN, du Wi-Fi, du NAS et du débit montant distant au lieu d’attribuer chaque échec de lecture aux capacités de calcul du serveur.
Validez d’abord la lecture avec un client local filaire, puis avec un client distant. Si la lecture locale fonctionne, limitez les réparations restantes à la configuration du routage, du DNS, du proxy ou du tunnel, plutôt que de reconstruire l’état du serveur.
Assistance et conseils
Plus à lire

Faut-il sauvegarder Jellyfin à chaud ou arrêter le service au préalable ?
Privilégiez les sauvegardes lorsque le service est arrêté pour plus de simplicité ; n’utilisez des instantanés à chaud que lorsque l’état de l’application est...

Pourquoi Jellyfin chauffe-t-il ou est-il bruyant lorsque personne ne regarde de contenu en streaming ?
La chaleur au repos indique généralement une activité en arrière-plan ou une charge de travail d’hébergement partagé. Identifiez donc le processus actif et la...

Quand faut-il reconstruire Jellyfin plutôt que le réparer ?
Choisissez la reconstruction plutôt que la réparation lorsque la dérive de l’environnement d’exécution est à l’origine du problème et que l’état persistant est sauvegardé...

