Dernier blog

Jellyfin prend en charge le reverse proxying avec sous-chemin, mais l’URL de base, la route du proxy, le chemin WebSocket et l’adresse du serveur client doivent correspondre.

Vérifiez si Jellyfin peut écrire en toute sécurité en testant son identité, le mode de montage et un chemin temporaire avant de modifier les autorisations en production.

Commencez avec un seul propriétaire de base de données et mesurez le comportement des verrous SQLite ; n’ajoutez un autre backend que lorsque la concurrence et la récupération justifient cette complexité.

Le travail en double provient généralement de planificateurs qui se chevauchent ou de plusieurs rédacteurs ; désignez un responsable, un chemin et une vérification d’achèvement uniques.

Arrêtez les écritures, préservez la base de données et les fichiers WAL, libérez de l’espace sans supprimer aveuglément l’état, puis vérifiez l’intégrité et la charge de travail d’origine.

Une propriété incorrecte provient généralement d’une incohérence d’identité ou d’un chemin d’importation différent ; vérifiez l’utilisateur actif du conteneur avant de modifier les autorisations.

Des données obsolètes dans Jellyfin après une modification de chemin signifient généralement que le service utilise encore l’ancien chemin, ne peut pas lire le nouveau point de montage ou n’a pas terminé une analyse valide.

Retirez l’ancien serveur Jellyfin uniquement après avoir vérifié qu’une restauration propre passe les contrôles d’état, de chemins, d’utilisateurs, de lecture, de redémarrage et de sauvegarde.