Question 1

親フォルダがない場合、Jellyfinがエピソードを削除できないのはなぜですか？

Accepted Answer

これは既知のバグで、親フォルダが削除された場合、ライブラリスキャンがエピソードを欠落としてマークできないというものです。この問題（#16628の重複）はJellyfin version 12.0で修正されました。version 12.0以降にアップグレードすることで問題が解決します。

Question 2

RAMディスクを使用する際に、Jellyfinのtranscode folderが一杯になってストリームが途切れるのはなぜですか？

Accepted Answer

Jellyfinのトランスコードセグメントの自動クリーンアップは、クライアントのウェブソケットイベントに依存していますが、これは保証されていません。そのため、多くの場合、ファイルはデイリープルーンまでトランスコードディレクトリに残り、限られたRAMディスクをすぐに埋めてしまいます。Jellyfin-Transcodes-cleanup (https://github.com/RTUnit/Jellyfin-Transcodes-cleanup) のようなクリーンアップスクリプトを使用してください。最新のJellyfin (10.11.x)向けに事前適応されたバージョンが、linuxserver/jellyfin Dockerイメージで利用可能です。これにより、再生済みセグメントが即座に削除され、RAM使用量を約1GBに制限します。代替案として、トランスコードディレクトリを容量が限られたストレージに配置しないでください。

Question 3

Jellyfin の「Recently Added in Series」が、v12.0 へのアップグレード後にシリーズのポスターではなくシーズンやエピソードのカバーを表示するのを修正する方法

Accepted Answer

これは v12.0 のリグレッションです。最新の TV アイテムがシリーズ別にグループ化されなくなり、シリーズのポスターではなくシーズン/エピソードの画像が返されます。これは「Restore series grouping for latest TV items」というタイトルの patch/PR で修正されています。その PR を含む v12.0 の patch リリースまたはより新しいビルドにアップグレードし、Jellyfin を再起動して、Ctrl+F5 でブラウザをハードリフレッシュしてください。Debian の場合: sudo apt update && sudo apt install --only-upgrade jellyfin && sudo systemctl restart jellyfin。Docker Compose の場合: docker compose pull && docker compose up -d。修正済みビルドが利用できない場合は、一時的な回避策としてアップグレード前のリリースにロールバックしてください。カバーアートを置き換えても、ライブラリを再スキャンしても、これは修正されません。

Question 4

なぜ Jellyfin は Docker 内で何千もの inotify watcher を作成し、起動が遅くなるのですか？また、それを修正するにはどうすればよいですか？

Accepted Answer

根本原因: .NET の `IConfiguration` は `JELLYFIN_CONFIG_DIR` 全体を再帰的に監視して変更を検知します。デフォルトの [linuxserver/docker-jellyfin](https://github.com/linuxserver/docker-jellyfin) のマウント構成では、すべてのメタデータが `/config` 内に配置され（`JELLYFIN_CONFIG_DIR=/config`）、そのため Jellyfin はメタデータファイルに対して 6,000 以上の inotify ウォッチを作成し、起動時に低速な再帰スキャンを実行します。これによりリクエストの処理開始が 3 分以上遅延し、システムの inotify 上限（`fs.inotify.max_user_watches`/`max_user_instances`）を使い果たして、他のサービスがクラッシュする可能性があります。

修正/回避策:
1. 環境変数 `DOTNET_HOSTBUILDER__RELOADCONFIGONCHANGE=false` を設定して、設定ファイルの監視を無効にします。その変数が実際にコンテナ内に渡されていることを確認してください（例: `docker run -e DOTNET_HOSTBUILDER__RELOADCONFIGONCHANGE=false ...`、または docker-compose の `environment:` 配下に記述）。最初の報告者は当初うまくいかないと思っていましたが、単に変数が正しく適用されていなかっただけでした。
2. 長期的により良い方法: メタデータを config ディレクトリ内に保存しないことです。ボリュームマウントを分割し、メタデータ（例: `config/data/metadata`）が `JELLYFIN_CONFIG_DIR` として使用されるパスの外に配置されるようにすれば、ウォッチャーが監視するのは少数の設定ファイルだけになります。メタデータの場所を移動すると、データベースパスの変更が必要になる場合があることに注意してください。
3. 一時的な緩和策として、ホスト側の上限を引き上げます: `sysctl fs.inotify.max_user_watches=524288` と `fs.inotify.max_user_instances=512`。

Jellyfin

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト