Jellyfin peut-il continuer à fonctionner pendant une panne temporaire d’Internet ?

Oui. Jellyfin peut continuer à diffuser des médias locaux pendant une interruption temporaire d’Internet lorsque le serveur, le stockage multimédia, le réseau local et le client peuvent toujours communiquer entre eux localement.

La précision importante est que « Jellyfin est auto-hébergé » ne signifie pas que toutes les dépendances environnantes fonctionnent hors ligne. Un chemin DNS public, un tunnel cloud, un fournisseur de métadonnées distant, une feuille de style CSS personnalisée hébergée à l’extérieur ou même le lanceur intégré de l’appareil de streaming peuvent tomber en panne alors que le serveur Jellyfin reste opérationnel. Testez l’ensemble du parcours de visionnage local avant de compter dessus pendant une interruption.

Distinguez la perte d’Internet de la perte du réseau local

Une panne du WAN signifie que le routeur ne peut plus atteindre Internet ; cela ne signifie pas nécessairement que le commutateur Ethernet, le point d’accès Wi-Fi, le DHCP et le routage local cessent de fonctionner. Gardez le serveur et le client sur le même réseau local opérationnel et testez le serveur Jellyfin avec son adresse locale ou un nom DNS local.

Les tests de panne rapportés par la communauté indiquent systématiquement que la lecture locale peut continuer lorsque l’accès au WAN est interrompu, tout en signalant que certains appareils clients peuvent avoir leurs propres dépendances Internet. Cette différence explique pourquoi le serveur et le client doivent être testés séparément.

Si le routeur redémarre dans un mode qui désactive le Wi-Fi ou le DNS local lorsque le WAN est absent, corrigez d’abord ce comportement réseau. Jellyfin ne peut pas servir un client qui n’a plus de route vers l’hôte, même si l’application n’a pas besoin d’une authentification cloud.

Donnez aux clients locaux un accès qui ne dépend ni du DNS public ni d’un tunnel cloud

Si chaque téléviseur accède à Jellyfin uniquement via un nom d’hôte public dont le DNS, le proxy inverse ou le tunnel dépend d’Internet, le service local peut sembler indisponible pendant une panne du WAN. Conservez une adresse IP locale ou un nom DNS local documenté comme solution de secours, ou configurez un DNS fractionné afin que le nom habituel du foyer soit résolu localement lorsque les clients sont à domicile.

Un accès local doit se terminer à l’intérieur du réseau local et atteindre la même instance Jellyfin prévue, sans transiter par un VPS ou un service cloud. Testez le comportement du certificat et du nom d’hôte requis par vos clients réels ; certaines applications acceptent une adresse HTTP locale directe comme solution de secours, tandis que d’autres sont configurées autour d’une seule URL HTTPS enregistrée.

L’explication de ZimaSpace sur l’accès local et l’accès distant comme deux chemins distincts constitue le bon modèle mental : l’échec du chemin WAN ne doit pas nécessairement entraîner la panne du chemin LAN.

Attendez-vous à une dégradation des métadonnées et des intégrations dépendantes d’Internet

Les médias déjà stockés, l’état de la base de données, les illustrations et les métadonnées peuvent rester disponibles localement. Les nouvelles recherches de métadonnées, les mises à jour des plug-ins, le téléchargement des sous-titres, les images distantes et les autres appels vers des fournisseurs externes peuvent échouer ou attendre l’expiration des délais jusqu’au rétablissement d’Internet.

Un test communautaire de Jellyfin avec des médias locaux hors ligne indique que les métadonnées locales existantes restent utilisables, tandis que le téléchargement de nouvelles informations devient indisponible. Concevez l’expérience en cas de panne autour des ressources locales mises en cache, plutôt que de supposer que chaque fonction d’enrichissement fait partie du parcours de lecture essentiel.

Si un thème personnalisé importe des polices ou du CSS depuis une URL publique, hébergez ces ressources localement si elles sont importantes pour l’interface hors ligne. De même, évitez de rendre obligatoire une passerelle d’identité distante pour les utilisateurs locaux du foyer, sauf si vous avez consciemment accepté cette dépendance en cas de panne.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Testez l’appareil client, pas seulement la page Web de Jellyfin

Certaines plateformes de téléviseurs connectés et certaines clés de streaming exigent un accès à Internet pour leur écran d’accueil, le lancement des applications, la vérification des comptes ou les services de la plateforme, même si le client Jellyfin peut communiquer localement une fois lancé. La réussite d’un navigateur sur ordinateur portable pendant une panne ne prouve pas que l’appareil du salon fonctionnera.

Des témoignages de foyers décrivent des comportements propres à chaque client sur un réseau local sans Internet, ce qui fait de la plateforme de l’appareil un élément de la conception de la disponibilité. Testez chaque catégorie de client que le foyer prévoit d’utiliser.

Gardez au moins un client de secours capable d’ouvrir une URL locale sans démarrage via le cloud. Il peut s’agir d’un ordinateur portable, d’une tablette, d’un HTPC ou d’un autre appareil que vous avez réellement testé. L’objectif n’est pas de prévoir le comportement de chaque fabricant, mais de démontrer l’existence d’un parcours utilisable par le foyer avant la prochaine panne.

Effectuez un exercice contrôlé de déconnexion du WAN

Ne faites pas le test en éteignant le routeur ou le Wi-Fi. Déconnectez ou bloquez uniquement la liaison WAN tout en laissant le réseau local intact. Ouvrez ensuite Jellyfin depuis un client redémarré, connectez-vous si nécessaire, parcourez les métadonnées existantes, lancez un fichier en lecture directe, lancez un transcodage si le foyer en dépend, avancez dans la vidéo, reprenez la lecture et changez d’utilisateur.

Pendant le test, notez quelles actions restent locales et lesquelles expirent lors d’appels vers des services externes. Reconnectez le WAN et vérifiez que les tâches de métadonnées ou de mise à jour ayant échoué reprennent sans corrompre l’état de la bibliothèque. Si l’interface se bloque parce que des appels externes empêchent les actions locales, notez précisément cette fonction comme dépendance en cas de panne.

La conception est validée lorsqu’un client habituel du foyer peut trouver le serveur, s’authentifier localement, parcourir le contenu stocké et lire des médias représentatifs alors que le WAN est absent. Tout élément qui échoue doit être identifié comme une dépendance du réseau local, de la plateforme cliente, de l’accès public ou d’une intégration externe, plutôt que résumé par « Jellyfin a besoin d’Internet ».

FAQ

Mes affiches et métadonnées Jellyfin existantes vont-elles disparaître lorsque la connexion Internet sera interrompue ?

Normalement, non. Les métadonnées et les illustrations déjà stockées par le serveur restent locales. Ce qui s’arrête, c’est la récupération de nouvelles informations auprès de fournisseurs dépendant d’Internet ; les nouveaux médias ou l’enrichissement à la demande peuvent donc rester incomplets jusqu’au rétablissement de la connexion.

Pourquoi un téléphone peut-il accéder à Jellyfin hors ligne alors qu’un téléviseur ne le peut pas ?

Le serveur Jellyfin peut être opérationnel alors que la plateforme du téléviseur dépend d’Internet pour le lanceur, le démarrage de l’application, le DNS ou la validation du réseau. Testez précisément le téléviseur ou le boîtier de streaming lors d’une déconnexion du WAN uniquement et gardez un client local de secours si le visionnage pendant les pannes est important.