- État Nouveau
- Pourcentage achevé
- Type Anomalie
- Catégorie Services locaux
- Assignée à Personne
- Système d'exploitation Freebox Server V7 (Delta)
- Sévérité Basse
- Priorité Très Basse
- Basée sur la version 4.9.2
- Due pour la version Non décidée
-
Échéance
Non décidée
- Votes
- Privée
Concerne le projet: Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)
Ouverte par Niiiko68 - 14/04/2025
Ouverte par Niiiko68 - 14/04/2025
FS#40231 - Problème sur Client Jellyfin AppleTV depuis passage en 4.9.x
Bonjour,
Petite bouteille à la mer concernant mon problème.
Du jour au lendemain, mon client Jellyfin sur Apple TV (Swiftfin) n’a plus été en mesure de lancer des films.
Le client se connecte à une VM Debian Bookworm sur laquelle tourne Jellyfin 10.10.7
J’écris ici car la seule chose qui a changé dans mon écosystème entre le moment où tout marchait et où tout a cassé est le passage de ma freebox en 4.9.0 (puis .1 et .2)
Sur le github du client Jellyfin que j’utilise, un développeur indique que le player Swiftfin utilise VLCKit et que ce dernier n’est pas compatible TLS 1.3
Y a-t-il eu des changements à ce niveau qui pourraient expliquer la régression observée ?
Merci d’avance !
Nicolas
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
bonjour,
il y a un changement dans la topologie virtuelle présentée par l'hyperviseur dans le firmware 4.9.0.
Cela est problématique pour les distributions où le nom d'interface se base sur la topologie PCIe. Toutes les distributions ne sont pas affectées, et c'est pourquoi le bug n'a pas été vu avant la sortie du firmware.
Un effet de bord est que pour les distributions où le nom des interfaces réseau reflète cette topologie, la configuration est invalide.
Malheureusement, cela ne peut être "corrigé" dans une future version de firmware: toutes les personnes qui ont dû modifier leur VM suite au passage en 4.9.0 seront à nouveau obligées de le faire en passant à un nouveau firmware. Autant limiter le nombre d'interventions manuelles…
Pour corriger: dans la VM il faut indiquer le nouveau nom d'interface.
Le comment dépend de la distribution utilisée (sur debian par exemple, il faut modifier enp0s3 par enp0s5 /etc/networks/interfaces).
Selon les services, il est possible qu'il faille mettre à jour leur configuration spécifique en indiquant le nouveau nom d'interface (jellyfin en l'occurrence).
Si votre VM est déjà accessible sur le réseau local, c'est vraisemblablement juste la configuration jellyfin qui doit être adaptée.
Sinon il y a la solution de revenir à eth0 qui avait l'avantage de ne pas bouger.
On ajoute sur la ligne de boot kernel :
Bonjour mmakassikis, Bonjour Padrys,
Merci beaucoup pour vos réponses rapides !
J'ai exécuté "ip a" et la console indique que l'interface est déjà enp0s5.
Côté Jellyfin, le paramètre "Lier à l'adresse de réseau local" est vide ce qui est censé indiquer : "Si le champ est laissé vide, le serveur s'attachera à toutes les adresses disponibles. La modification de cette valeur nécessite un redémarrage."
Je précise que le serveur Jellyfin est accessible et semble fonctionner normalement (il reconnaît les nouveaux fichiers déposés sur les disques /mnt etc..) C'est vraiment cantonné à la lecture des fichiers, le player reste noir (alors que côté serveur, il indique que la lecture a commencé et aucune erreur dans les logs)
J'ai tenté de modifier le fichier /etc/default/grub pour passer GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0 biosdevname=0"
puis sudo-update-grub
Mais au redémarrage, j'étais toujours en enp0s5.
Nicolas
Pardon, ma remarque était pour ceux qui avaient eu une perte de réseau suite au changement de nom d'interface.
Ça ne vous concerne peut-être pas du coup, oups :o)
ok, dans ce cas là, pas de configuration spécifique à faire.
pas nécessaire de toucher à net.ifnames si le serveur Jellyfin est joignable.
la version de TLS est négocié en fonction de ce qui est supporté à la fois par le serveur et le client. Je doute que Jellyfin soit configurer pour nécessiter sur TLS1.3.
Vu que c'est dans le réseau local, vous pouvez essayer d'utiliser l'API HTTP plutôt que HTTPS (donc pas de TLS du tout). Je ne pense pas que cela change quelque chose: si le client arrive à lister et sélectionner le fichier, c'est que l'API répond en principe.
L'écran noir me fait penser à un problème de codec; d'autant plus qu'il semble y avoir quelques limitations selon la plateforme: https://jellyfin.org/docs/general/clients/codec-support
est-ce qu'il y a eu une mise à jour du serveur jellyfin ?
est-ce que le player a un fichier de log ?
est-ce que le comportement est le même quelque soit le fichier ?
Merci pour ces éclaircissements !
En effet, j'utilise du HTTP pour accéder au serveur, donc l'incompatibilité TLS 1.3 est donc à écarter.
Problème de codec:
J'ai écarté cette hypothèse car le client n'a pas été mis à jour depuis des lustres et avant le redémarrage de la box en 4.9.x il était capable de lancer un film qui aujourd'hui ne marche plus.
Aussi, l'appli VLC de l'Apple TV (qui utilise aussi VLCKit) est capable de lire le film quand j'accède au film sur le disque dur réseau.
MAJ du serveur Jellyfin :
J'ai également écarté cette piste car je n'avais pas fait de maj. Entre temps j'ai réinstallé toute la VM et donc je suis passé sur la dernière version du serveur, mais le problème est toujours le même.
Log du player:
Hélas non, enfin à ma connaissance je ne peux pas y accéder depuis l'appli Apple TV.
est-ce que le comportement est le même quelque soit le fichier ?
C'est là où ça se complique encore. Parfois pour un même fichier, j'arrive à lancer la lecture et parfois non ; mais je n'arrive pas à reproduire à tous les coups… Ce qui marche parfois, c'est de lancer le film sur le client web, puis de relancer la lecture sur le client iOS.
Nicolas
dans ce cas, c'est bien côté jellyfin qu'il semble y avoir un problème.
dans ce cas là, est-ce que jellyfin a des logs côté serveur ? éventuellement voir si cela est paramétrable pour avoir des logs de debug.
l'objectif étant de voir ce qui se passe notamment avec l'astuce de d'abord lancer avec le client web