Pourquoi Jellyfin semble plus rapide sur certains clients que sur d’autres

Jellyfin peut sembler beaucoup plus rapide sur un client que sur un autre, car les capacités de lecture et le comportement de l’application modifient le travail effectué des deux côtés.

Une application TV native, un navigateur, un téléphone et un lecteur de bureau n’offrent pas exactement la même prise en charge des codecs, la même stratégie de mise en mémoire tampon, le même décodage matériel ni la même implémentation de l’interface. L’un peut utiliser la lecture directe, tandis qu’un autre déclenche une conversion, et l’un peut afficher les écrans de bibliothèque plus efficacement avec le même serveur. Comparez les clients avec les mêmes médias, le même réseau et le même état du serveur afin d’attribuer la différence aux capacités du client ou au comportement de l’interface.

La prise en charge des codecs peut modifier la charge de travail du serveur

La différence la plus importante tient à la capacité du client à accepter la vidéo source, l’audio, le conteneur, le mode HDR et les sous-titres. Un élément non pris en charge peut transformer une simple lecture de fichier en transcodage complet.

La même source HEVC peut suivre des chemins de compatibilité différents selon le client sur Android TV et les clients de type navigateur.

Lisez un fichier connu sur chaque client et notez s’il s’agit d’une lecture directe, d’un remultiplexage ou d’un transcodage. Si le client le plus lent crée le chemin le plus lourd côté serveur, la différence de performances ne relève pas uniquement de la latence de l’interface.

Le décodage matériel modifie la fluidité côté client

Un client capable d’utiliser le décodeur de l’appareil peut lire des contenus à haut débit avec moins de travail processeur local qu’un client qui dépend d’un chemin logiciel moins performant. Cela peut affecter le démarrage, la recherche, les images perdues et l’autonomie de la batterie.

Le même appareil Android TV peut se comporter différemment lorsque son chemin de sortie audio change ; le comportement du passthrough E-AC3 a bloqué la lecture directe dans un cas où le décodage PCM local évitait l’échec.

Conservez le même serveur et le même réseau en ne changeant que le client de lecture. Si le même média devient fluide sans modification côté serveur, le décodage ou la mise en mémoire tampon du client mérite votre attention.

La réactivité de l’interface est une mesure différente

Une lecture rapide ne garantit pas des grilles d’affiches ou une recherche rapides, car les requêtes de l’interface de bibliothèque dépendent de l’accès aux métadonnées, des requêtes de base de données, du chargement des images et du rendu côté client. Considérez la navigation et la lecture comme deux tests de performance distincts.

Le dépannage d’un tableau de bord lent présente les chemins de chargement des métadonnées et de l’interface comme un problème de performances distinct de la diffusion du flux.

Chronométrez séparément l’ouverture de la bibliothèque, la recherche et l’affichage de la première image. Un processus de diagnostic de la mise en mémoire tampon ne doit être utilisé que pour l’étape de diffusion réellement lente.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Utilisez un client fiable comme référence

Sans référence, une modification du serveur peut sembler résoudre le problème d’un client alors qu’elle ne fait que modifier sa décision de lecture. Un point de terminaison de référence stable facilite la classification des régressions entre clients.

La méthode USE aide à vérifier si le profil d’utilisation des ressources du serveur change réellement lorsque le client le plus lent est utilisé.

Conservez un client, un fichier multimédia et un réglage de qualité comme référence reproductible après les mises à jour de l’application ou du serveur. Cherchez la première mesure qui diverge plutôt que d’optimiser toutes les couches simultanément.