Jellyfin 12 polit la réécriture 10.11 et impose un scan complet après migration
Le 8 septembre, Jellyfin a publié la version 12.0, qui abandonne le préfixe « 10. » et concentre l’essentiel de son travail sur la performance héritée de la réécriture 10.11. La migration change la base de données sans retour en arrière possible : sauvegarde, retrait des plugins et scan complet obligatoire avant de profiter du gain.
8 septembre 2026. Jellyfin publie la version 12.0 de son serveur multimédia auto-hébergé, trois mois seulement après 10.11. Le changement de numérotation n’est pas anodin : le projet abandonne le préfixe « 10. » — 10.11.x devient 12.x — parce qu’aucune rupture d’API majeure n’est à l’horizon et que le schéma semait la confusion sur ce qu’était une version « majeure ». Le fond de la sortie, lui, tient en un mot : performance.
Une consolidation, pas une révolution
10.11 avait livré une réécriture majeure du backend. Fonctionnelle dans l’ensemble, elle accumulait des défauts de jeunesse. 12.0 existe pour les polir et rendre la rapidité à tous les utilisateurs.
La version ne se présente pas comme une refonte. Elle ajoute des fonctions attendues — support propre des livres, versions multiples pour les épisodes, fournisseurs de similarité et de recommandation améliorés, fournisseurs de recherche que les plugins peuvent étendre ou remplacer, corrections SchedulesDirect et EPG, correctifs du système de classification parentale, élagage des données au remplacement ou à la suppression des fichiers, numéros d’épisodes à triple chiffre, filtrage BoxSet et Playlist par bibliothèque — mais le cœur du travail est invisible : la base de données. Les utilisateurs rapportent des temps de chargement nettement réduits, et une nouvelle interface « moderne » accompagne la sortie côté web.
Les nouveaux fournisseurs de recherche et de recommandation sont plus qu’un nettoyage. Un fournisseur de recherche permet à un plugin de remplacer ou d’étendre la façon dont les résultats sont produits — une bibliothèque peut remonter des correspondances depuis un index maison ou une source de métadonnées de niche. Un fournisseur de recommandation confie la logique du « vous aimerez aussi » à du code branchable, ouvrant la porte à des recommandations communautaires ajustées à une collection précise. Les deux vont dans le même sens : Jellyfin pousse la personnalisation vers les plugins plutôt que de la figer dans le cœur.
Une migration qui ne permet pas le retour en arrière
C’est le point que tout administrateur doit lire avant de cliquer. 12.0 inclut des changements de base de données qui empêchent un retour à la version précédente sans une restauration complète. La consigne est nette : sauvegarde intégrale du répertoire de données avant la mise à niveau.
Les mises à niveau directes depuis 10.10.7 et 10.11.x sont prises en charge, sans étape intermédiaire. Les utilisateurs d’une version antérieure doivent d’abord passer par 10.10.7. Les plugins de dépôt installés — tout ce qui n’est pas natif — doivent être retirés avant la migration, puis ré-ajoutés après, le temps que les plugins s’adaptent aux nouveaux schémas de base.
Après la migration, un scan complet de la bibliothèque est obligatoire. Les notes de version le disent sans ambiguïté : les versions alternatives de médias résolues automatiquement seront supprimées à cause de problèmes de types de données, et seul un scan complet les reconstitue. Le premier scan est sensiblement plus long que d’habitude, et certains films peuvent réapparaître comme nouvellement ajoutés.
Le coût d’une base remise au propre
La pull request de performance #16062 illustre le travail. Le serveur lance une vérification complète basée sur les chemins de tous les éléments de la bibliothèque pour nettoyer les restes. Selon la taille de la collection, cela prend du temps. Le message est clair : la performance future se paie d’un scan unique, au moment de la migration.
Côté packaging, les paquets Debian Bullseye et Ubuntu Focal ne sont plus construits — un signal aux retardataires que ces distributions sortent du périmètre supporté.
Le contexte : la bifurcation de 2018
Jellyfin est né en 2018 d’un fork d’Emby, quand celui-ci a refermé son code. Huit ans plus tard, il est devenu la référence du media server auto-hébergé face à Plex, dont le modèle repose sur des services cloud et un abonnement. La promesse tient en une phrase : tout tourne chez vous, sans compte, sans télémétrie, sans dépendance à un service distant. C’est pourquoi une sortie « de performance » compte autant pour un homelab : la rapidité de chargement de la bibliothèque et la stabilité de la base sont le produit lui-même.
La réécriture 10.11 avait touché le cœur du serveur — la couche de données, l’accès aux médias, une partie de l’API — pour poser les fondations d’une base plus propre. 12.0 ne revient pas sur ces choix : il en corrige les conséquences, notamment les problèmes de types de données qui imposent le scan complet, et ajoute les fonctions que la réécriture avait mises en attente.
La checklist de migration en six étapes
La marche à suivre est explicite dans les notes de version, et elle ne pardonne pas les raccourcis.
- Sauvegardez le répertoire de données complet — la base change sans retour en arrière possible.
- Vérifiez la version source : 10.10.7 ou 10.11.x pour une mise à niveau directe, sinon passez d’abord par 10.10.7.
- Retirez les plugins non natifs avant la migration, et rebasculez le dépôt de plugins sur le manifeste stable.
- Migrez, puis laissez le premier démarrage exécuter ses migrations — plusieurs minutes, sans interruption.
- Lancez un scan complet de la bibliothèque pour reconstituer les versions alternatives supprimées.
- Ré-ajoutez les plugins un par un, en testant leur compatibilité avec les nouveaux schémas.
Le piège le plus fréquent n’est pas la migration elle-même, c’est l’impatience : interrompre le premier démarrage ou sauter le scan complet laisse une bibliothèque incomplète, avec des médias « disparus » qui ne reviendront qu’après un scan.
Ce que ça change pour un homelab
La sortie 12.0 est un bon cas d’école de migration à faire en conscience, pas à la va-vite. Le contraste avec Plex est éclairant : au moment où Jellyfin livre une version de consolidation, plus de 36 000 serveurs Plex n’ont toujours pas appliqué un correctif de sécurité urgent. L’avantage du self-hosting, c’est que la décision de migrer — et le risque — vous appartient entièrement.
- La sauvegarde n’est pas une option. Une base dont le schéma change sans retour en arrière possible est exactement le scénario où une sauvegarde préalable vaut des heures.
- Le scan complet est le prix du nettoyage. Planifiez la migration à un moment où la bibliothèque peut être indisponible ou ralentie pendant un long scan.
- Les plugins attendront. Retirez les plugins non natifs avant, ré-ajoutez-les après — un plugin incompatible peut faire échouer le chargement et provoquer des effets de bord.
La bonne nouvelle est que 12.0 ne demande pas d’apprendre un nouveau système : c’est la même interface, débarrassée de ses aspérités, avec une bibliothèque plus rapide à charger.
Verdict
Jellyfin 12.0 est une mise à niveau de consolidation qui vaut le coût de sa migration, à condition de la faire dans les règles.
Si votre serveur tourne sous 10.10.7 ou 10.11.x, planifiez la mise à niveau : sauvegarde complète, retrait des plugins, migration, puis scan complet de la bibliothèque. Le gain de performance et de stabilité est réel, et la disparition du préfixe « 10. » simplifie enfin le suivi des versions. Si vous êtes sur une version antérieure à 10.10.7, passez d’abord par 10.10.7 — et si vous n’avez pas de sauvegarde fiable, corrigez cela avant toute chose : une migration sans retour en arrière possible n’est pas le moment de découvrir que la sauvegarde ne fonctionne pas.