Comment déterminer si une erreur Jellyfin provient du client ou du serveur

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

How to Tell Whether a Jellyfin Error Comes From the Client or Server - Zima Store Online

Une erreur Jellyfin suit généralement le client lorsqu’un appareil échoue alors qu’un client de contrôle fonctionne, et suit le serveur lorsque plusieurs clients échouent avec le même chemin multimédia. Commencez par un test de contrôle local avant de modifier les codecs ou le matériel.

Gardez le serveur, le compte, le média et la qualité inchangés lorsque vous comparez le client concerné à un client connu comme fonctionnel, puis comparez la lecture locale directe avec le chemin distant ou passant par un proxy. Le résultat indique s’il faut modifier les capacités du client, les paramètres de transcodage de Jellyfin ou le routage réseau, et quand s’arrêter parce que les éléments disponibles sont contradictoires.

Utiliser un client de contrôle sur le même serveur

Un client signale une erreur de lecture. Commencez par la vérification la moins intrusive : lisez le même élément avec le même compte et la même qualité sur un client de contrôle. test de contrôle sur le même serveur

L’observation utile est précise : le contrôle réussit, les deux échouent, ou le contrôle choisit un mode de lecture différent. Notez le résultat avant de modifier une autre variable.

Interprétez la branche au lieu de deviner. Si seul le client concerné échoue, la responsabilité du client est privilégiée ; si les deux échouent, examinez le serveur ou le chemin réseau ; si les modes diffèrent, comparez d’abord le codec et le chemin des sous-titres.

Vérifier le mode de lecture et les journaux du serveur

Le client de contrôle échoue également ou demande le même chemin au serveur. Commencez par la vérification la moins intrusive : comparez le mode de lecture affiché dans le tableau de bord ainsi que les entrées FFmpeg ou du journal du serveur correspondant aux sessions concernée et de contrôle.

L’observation utile est précise : la lecture directe échoue dans les deux cas, le transcodage s’arrête dans les deux cas, ou un seul client transcode. Notez le résultat avant de modifier une autre variable. éléments probants des journaux FFmpeg

Interprétez la branche au lieu de deviner. Si les deux sessions partagent une erreur du serveur, la responsabilité du serveur est privilégiée ; si une seule session transcode, revenez aux capacités du client ; si les journaux sont propres, testez le chemin réseau et l’état du navigateur.

Comparer les chemins local direct et distant

La responsabilité du client ou du serveur n’est pas établie de manière concluante. Commencez par la vérification la moins intrusive : utilisez le même client et le même média via l’URL du réseau local, puis via l’URL distante ou passant par un proxy.

L’observation utile est précise : la lecture locale réussit, la lecture distante échoue, les deux échouent, la lecture distante réussit ou la lecture locale échoue. Notez le résultat avant de modifier une autre variable. chemin local par rapport au chemin distant

Interprétez la branche au lieu de deviner. Si seul le chemin distant échoue, limitez la recherche au proxy, au DNS, au routage ou à la bande passante ; si les deux échouent, réexaminez les éléments concernant le serveur ; si seul le chemin local échoue, examinez la liaison ou le DNS local.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

Revoir le déclencheur initial et s’arrêter au niveau responsable

La responsabilité est attribuée sous conditions. Commencez par la vérification la moins intrusive : appliquez une seule modification ciblée, puis relancez la session d’origine et une session de contrôle.

L’observation utile est précise : la session d’origine réussit et le contrôle reste stable, la session d’origine échoue toujours, ou les deux chemins changent. Notez le résultat avant de modifier une autre variable.

Interprétez la branche au lieu de deviner. Si la session d’origine réussit et que le contrôle reste stable, arrêtez-vous ; si elle échoue toujours, annulez la modification et poursuivez l’escalade auprès du responsable désigné ; si les deux changent, revenez à la première variable qui n’a pas été contrôlée.