Comment déterminer si le retard de Plex vient du client ou du serveur
Le délai de Plex relève du client lorsque le même chemin côté serveur fonctionne ailleurs, et du serveur lorsque plusieurs clients reproduisent le même goulot d’étranglement.
Les cas difficiles se situent entre ces deux extrêmes : utilisez donc des substitutions plutôt que votre intuition. Gardez le fichier multimédia et le réseau inchangés, remplacez uniquement le client, puis recommencez avec un autre fichier ou un autre mode de lecture. En parallèle, surveillez la saturation des ressources du serveur et les journaux afin que le test permette de distinguer le rendu, le décodage, la diffusion réseau et le traitement côté serveur.
Reproduire le délai avec le même fichier multimédia
Changer à la fois le fichier et le client détruit la comparaison. Un seul fichier de test connu fournit une charge stable pour vérifier si un appareil est particulièrement lent.
Les régressions Plex spécifiques à certains clients peuvent toucher certaines plateformes tandis que d’autres restent fonctionnelles.
Lisez le même élément avec la même qualité sur deux clients connectés au même réseau, puis comparez le temps de démarrage et les erreurs. Si un seul client reproduit le délai, vérifiez les codecs pris en charge par le client, la version de l’application et le décodage de l’appareil avant de modifier le serveur.
Vérifier si le serveur est saturé
Un délai côté serveur devrait laisser des traces au niveau du processeur, de la mémoire, du disque, du réseau ou de l’activité des processus lorsque la requête lente se produit. Si l’hôte reste largement sous le seuil de saturation, le client ou le chemin réseau devient plus probablement en cause.
Les vérifications de l’utilisation, de la saturation et des erreurs permettent de distinguer une ressource très sollicitée d’une ressource réellement limitée ou défaillante.
Relevez les mêmes métriques de l’hôte pendant une session rapide et une session lente. Si le client lent ne génère aucune pression correspondante sur le serveur, examinez le point d’accès ou le transport avant d’augmenter les ressources du serveur.
Forcer séparément la lecture directe et le transcodage
Un client peut être rapide en lecture directe, mais lent lorsque sa compatibilité oblige le serveur à utiliser un autre chemin de lecture. Tester les deux modes permet de déterminer si le délai suit le client lui-même ou la charge de transcodage qu’il déclenche.
Lorsque le transcodage Plex est requis, la compatibilité du client déplace le travail de décodage et d’encodage vers le serveur.
Utilisez un fichier multimédia dont vous savez qu’il est lu directement sur les deux clients, puis introduisez le format problématique ou les sous-titres concernés. Lorsque le délai apparaît uniquement au démarrage de la conversion, examinez le transcodeur et le stockage temporaire plutôt que l’interface du client. Pour les délais limités au WAN, répétez la même matrice avec un chemin de diffusion Plex à distance connu afin de ne pas mélanger les comportements locaux et distants.
Utiliser une matrice des chemins plutôt que des tests isolés
Le diagnostic le plus rapide consiste à comparer les clients A et B en lecture directe et transcodée, dans les mêmes conditions réseau. Cette matrice montre quelle variable accompagne l’échec, au lieu d’accumuler des modifications de réglages sans rapport.
La diffusion Plex 4K à distance dépend d’un débit montant durable et peut également déclencher une conversion côté serveur.
Notez quatre résultats : client A/direct, client A/converti, client B/direct et client B/converti. Si une ligne échoue systématiquement, corrigez d’abord cette couche, puis relancez la matrice avant de passer à l’hypothèse suivante.
Produits recommandés
Centre Tech & IA
Plus à lire
Pourquoi l’architecture d’un serveur personnel Jellyfin évolue à mesure que vous ajoutez des services
Un boîtier Jellyfin devient une pile de services à mesure que l’on ajoute des applications : la gestion du processeur, du stockage, du réseau,...
Comment mesurer les performances de Jellyfin sans confondre cache et capacité
Un benchmark Jellyfin fiable distingue les états à froid et à chaud afin que les métadonnées mises en cache ou les pages du système...
De quelle marge de manœuvre l’iGPU de Jellyfin multi-utilisateur a-t-il besoin ?
La marge disponible de l’iGPU pour Jellyfin dépend de la charge de travail : prévoyez une marge au-delà du scénario de transcodage simultané reproductible...
