Qu’est-ce qui fait échouer la lecture sur un téléviseur alors qu’elle fonctionne sur les autres clients ?
La lecture échoue généralement sur un seul téléviseur parce que l’application, le décodeur, le chemin réseau ou le profil client de ce téléviseur diffère de ceux des appareils fonctionnels.
Lorsque les navigateurs, les téléphones ou un autre téléviseur lisent la même bibliothèque, le serveur multimédia et le stockage ne sont pas automatiquement mis hors de cause, mais le client défaillant devient l’élément de comparaison le plus pertinent. Utilisez un seul fichier, un seul compte et un seul réseau à la fois afin de comparer les décisions de lecture, la prise en charge des codecs, la gestion de l’audio et des sous-titres, la classification de la connexion, la version de l’application, l’état du cache et le journal du serveur généré par la requête exacte de ce téléviseur.
Reproduire l’échec avec le même fichier et le même compte
Lisez un titre concerné sur le téléviseur défaillant et sur un client fonctionnel en utilisant le même utilisateur, le même réglage de qualité, la même piste audio, la même piste de sous-titres et le même point de départ. Notez l’heure exacte de l’erreur et indiquez si l’affiche, l’audio ou la première image vidéo apparaît.
Un rapport Jellyfin Tizen décrit un téléviseur Samsung qui échouait alors que le même média fonctionnait sur un autre téléviseur, un client Android et d’autres appareils. L’indice déterminant était l’échec isolé à un seul client TV.
Si tous les clients échouent avec le même fichier, revenez à la corruption de la source, aux autorisations ou au traitement du serveur. Si un seul téléviseur échoue avec de nombreux fichiers, donnez la priorité à sa version d’application, à son profil de lecture, à son décodeur et à son chemin réseau.
Comparer la décision de lecture et la raison de l’échec
Ouvrez le tableau de bord du serveur multimédia pendant que chaque client lance la lecture. Notez s’il s’agit d’une lecture directe, d’un flux direct ou d’un transcodage, ainsi que les codecs vidéo et audio sélectionnés, la méthode de sous-titrage, le débit et toute raison liée au profil client.
Un problème de lecture sur Tizen signale explicitement que le média n’est pas pris en charge par le client, ce qui montre que la négociation des capacités du client peut bloquer la lecture avant que les capacités du serveur n’entrent en jeu.
Si le téléviseur demande une lecture directe et échoue immédiatement, forcez temporairement une qualité inférieure à des fins de diagnostic. Si le transcodage réussit, examinez le profil de codec du téléviseur ; si les deux modes échouent, inspectez le conteneur de diffusion, le journal du serveur, l’état de l’application et la requête réseau.
Isoler la compatibilité de la vidéo, de l’audio, du conteneur et des sous-titres
Testez d’abord une vidéo H.264 connue comme fonctionnelle, avec un son stéréo AAC dans un fichier MP4, puis modifiez un seul composant à la fois. Essayez la vidéo d’origine avec une piste audio compatible, les sous-titres désactivés, puis une piste de sous-titres en texte brut.
Un client peut prendre en charge la vidéo HEVC sans prendre en charge le profil exact, le niveau, la profondeur de couleur, le mode Dolby Vision, le codec audio, la disposition des canaux ou le format de sous-titres utilisés. Une discussion Jellyfin Tizen relie les échecs de lecture à un profil de codec vidéo non pris en charge, alors que le transcodage vidéo n’était pas disponible.
Utilisez le premier changement de composant qui rétablit la lecture pour choisir la solution. Sélectionnez une piste compatible, autorisez un transcodage pris en charge, utilisez un client plus performant ou préparez une version secondaire ; ne réencodez pas toute la bibliothèque à partir d’un seul échec non caractérisé.
Vérifier si le téléviseur utilise un chemin réseau différent
Comparez l’adresse du serveur utilisée par le téléviseur avec celle du client fonctionnel. Vérifiez l’utilisation d’une adresse IP locale ou d’un nom d’hôte public, l’accès direct ou relayé, l’utilisation d’un proxy inverse, le résultat DNS, le certificat TLS et la classification du téléviseur comme appareil local ou distant par le serveur.
La gestion du proxy propre au client peut interrompre la lecture même lorsque la navigation et la connexion fonctionnent. Un problème Jellyfin Tizen a montré qu’un fichier était lu via l’adresse du réseau local, mais échouait par le chemin passant par le proxy inverse.
Testez le téléviseur avec l’adresse locale directe du serveur uniquement à des fins de comparaison. Si cela fonctionne, corrigez les en-têtes du proxy, les routes WebSocket ou de diffusion, TLS ou la classification du nom d’hôte, plutôt que de conserver un contournement non sécurisé comme point d’accès permanent.
Mesurer la véritable connexion filaire ou Wi-Fi du téléviseur
Consultez le débit de liaison négocié par le téléviseur, la bande Wi-Fi, la qualité du signal, les pertes de paquets et les compteurs du commutateur ou du point d’accès. De nombreux téléviseurs connectés disposent d’une liaison Ethernet à 100 Mbit/s, même lorsque le serveur domestique utilise du 2,5 GbE.
Testez le téléviseur à la fois sur une liaison filaire connue comme fonctionnelle et sur un réseau Wi-Fi 5 GHz ou 6 GHz stable, lorsque celui-ci est pris en charge. Un test de débit réalisé sur un ordinateur portable placé à côté du téléviseur ne prouve pas que l’adaptateur du téléviseur reçoit le même débit.
Si la réduction du débit est la seule mesure qui rétablit la lecture du titre, comparez les pointes de débit de lecture du fichier avec celles du chemin réseau du téléviseur. Si l’échec persiste à faible débit et survient avant le début d’un trafic soutenu, revenez au diagnostic du codec, de l’application ou du profil.
Réinitialiser l’état du client et comparer les versions de l’application
Notez le modèle du téléviseur, la version du système d’exploitation, la version de l’application multimédia, la version du serveur, la version du bundle web lorsque cela est pertinent et la méthode d’installation. Comparez ces éléments avec ceux du téléviseur fonctionnel au lieu de supposer que les deux appareils utilisent le même client.
Des données web ou un cache d’application obsolètes peuvent faire se bloquer un client sur certains fichiers. Un rapport Jellyfin Tizen indique que l’effacement des données enregistrées par le navigateur du téléviseur a rétabli la lecture.
Déconnectez-vous, effacez uniquement le cache de l’application ou les données de navigation, redémarrez complètement le téléviseur, puis réinstallez ou mettez à jour l’application par la méthode prise en charge. Conservez les journaux du serveur générés avant la réinitialisation afin qu’un nettoyage temporaire du client n’efface pas le seul indice reproductible.
Vérifier le transcodage matériel uniquement lorsque le téléviseur le demande
Si le téléviseur défaillant est le seul à déclencher une conversion vidéo, inspectez l’activité de décodage GPU, de filtrage et d’encodage, ainsi que l’erreur FFmpeg exacte. Les clients fonctionnels en lecture directe ne prouvent pas que le serveur peut transcoder le format non pris en charge par le téléviseur.
La procédure ZimaSpace consacrée à la vérification du transcodage matériel aide à distinguer une demande liée à la compatibilité du client d’un problème de GPU ou de chemin vers le périphérique du conteneur.
Refaites le test avec les sous-titres désactivés et une piste audio compatible avant d’incriminer le GPU. Si un transcodage H.264 simple fonctionne, mais que le mappage des tons HDR ou l’incrustation des sous-titres échoue, identifiez l’étape de filtrage concernée au lieu de conclure que l’accélération matérielle est indisponible.
Confirmer la correction dans le véritable scénario de lecture du téléviseur
Après avoir appliqué la modification la plus limitée correspondant à la cause, testez le démarrage, la recherche, la pause, la reprise, les sauts de chapitre, les pistes audio alternatives, les sous-titres et un second titre utilisant des codecs similaires. Surveillez le journal du serveur pendant chaque transition.
La liste de vérification du serveur multimédia domestique de ZimaSpace recommande de tester plusieurs clients, car le comportement des codecs, des sous-titres et des applications peut varier selon les appareils.
Le problème n’est résolu que lorsque le téléviseur défaillant utilise un chemin de lecture prévisible, que le serveur ne signale plus d’erreur répétée propre à ce client et que le résultat persiste après un redémarrage électrique du téléviseur et de l’application. Conservez le fichier de test connu comme fonctionnel comme référence pour les futures mises à jour du client.
Produits recommandés
Assistance et conseils
Plus à lire
Pourquoi la restauration d’un volume Docker recrée-t-elle le contenu des fichiers, mais supprime-t-elle les attributs étendus ?
Un diagnostic de restauration de volume couvrant l’inventaire des xattr, les options de tar et de Rsync, les espaces de noms, la prise en...
Pourquoi un conteneur en cours d’exécution conserve-t-il son ancienne limite de mémoire après la modification du fichier Compose ?
Un diagnostic des limites mémoire couvrant les cgroups actifs, le redémarrage par rapport à la recréation, les champs Compose, les limites strictes et souples,...
Pourquoi le redémarrage d’un proxy inverse invalide-t-il toutes les sessions d’une application auto-hébergée ?
Un diagnostic de perte de session couvrant la portée des redémarrages, la propriété des cookies, la rotation des secrets, les sessions adossées au cache,...
