KodiとJellyfinを組み合わせた構成と、スタンドアロンのJellyfinクライアントは、2つの異なるメディアサーバーではありません。同じJellyfinサーバーを中心とした、2種類のクライアントアーキテクチャです。Kodiは強力なローカルメディアセンター層を追加し、スタンドアロンのJellyfinクライアントは、より多くの処理をサーバー主導で行います。
どちらが適しているかは、Kodiのローカルライブラリ統合とカスタマイズ性を重視するか、それとも、より簡単なユーザー切り替え、クライアント側での同期負荷の軽減、テレビ・スマートフォン・ブラウザー・リモートネットワーク間での一貫した体験を好むかによって決まります。
リビングルームのインターフェースを重視するならKodi
Kodiは高度にカスタマイズでき、JellyfinのメディアをKodiのネイティブなローカルライブラリのように扱えます。専用のHTPCやテレビボックスなら、リビングルームの1画面に合わせて、スキン、リモコン操作、音声パススルー、コーデック対応を最適化できます。
ZimaSpaceのKodiメディアセンターのワークフローは、このモデルがテレビ中心のユーザーに支持される理由を示しています。再生端末を、リモコンで操作しやすいローカルインターフェースに合わせて細かくカスタマイズできるためです。
その代わり、クライアント側の状態が増えます。各Kodiのインストール環境がローカル設定、アドオン、キャッシュ、さらに統合モードによってはライブラリデータベースの状態を保持するため、その端末上で正常な状態を維持する必要があります。
サーバー主導の一貫性を重視するならスタンドアロンのJellyfinクライアント
スタンドアロンのJellyfinアプリやWebクライアントは、サーバー上の最新のライブラリ、ユーザー、再生プロファイルをより直接的に利用します。Kodi固有のローカルライブラリ状態を維持する必要が少なく、通常は各端末でKodiライブラリを再構築するのではなく、同じサーバーにログインするだけで端末を切り替えられます。
Jellyfinの現在のクライアント一覧には、デスクトップ、Android、Android TV、iOSなど、さまざまなプラットフォーム向けの公式クライアントが含まれています。そのため、家庭内の異なる端末へサーバー主導のモデルを展開しやすくなっています。
一方で、クライアントによって対応するコーデック性能は異なります。ブラウザーやテレビアプリは、性能の高いKodi端末より対応フォーマットが少ない場合があり、その結果、サーバー側でのトランスコードが増えることがあります。
Jellyfin for Kodiは、ネイティブなKodiブラウジングのために同期作業を受け入れる構成
同期統合を使用すると、選択したJellyfinライブラリがKodiのローカルメディアデータベースに登録されます。これにより、Kodiネイティブの「映画」や「テレビ番組」ビューを利用でき、同期後は非常に高速にローカルブラウジングできます。
その代わり、クライアントのライフサイクル管理が必要になります。各Kodi端末で、起動時や追いつき同期が発生する場合があり、それぞれが独自のデータベース状態を持ちます。安定して使い続けるリビングルームの端末が1~2台の場合には魅力的ですが、多数のクライアントを頻繁に再インストールしたり、長期間電源を切ったりする環境にはあまり向きません。
Kodi独自のプロファイルモデルは、ユーザー設定とメディア情報をクライアント側に個別に保存します。これは、Kodi中心の体験では、Jellyfin自体の外部にも相応の端末側状態が存在するという、より大きな特徴を裏付けています。
JellyConは、ライブサーバーリクエストのためにローカル同期を省く構成
JellyConは、一般的なストリーミングアドオンに近い動作をします。Jellyfinライブラリ全体をKodiのデータベースへ同期する必要がないため、他のKodiメディアソースと併用しやすく、ユーザーやサーバーの切り替えも簡単です。
JellyConプロジェクトは、自らをJellyfinサーバーから直接メディアを閲覧・再生する軽量なKodiアドオンと説明しています。その代わり、ブラウジングはライブサーバーリクエストとローカルクライアントの速度により大きく左右されます。
Kodiのカスタマイズ性を重視しつつ、完全なローカルライブラリ同期までは必要ない場合は、JellyConを使用してください。
家庭内の利用方法で2つのアーキテクチャを比較する
| 要件 | Kodi中心のクライアント | スタンドアロンのJellyfinクライアント |
|---|---|---|
| 高度にカスタマイズしたテレビUI | 非常に適している | クライアントによる |
| ネイティブなKodiライブラリの使用感 | 非常に適している | 不可 |
| 複数端末への簡単なセットアップ | 端末ごとのメンテナンスが増える | より適している |
| ユーザーやサーバーの簡単な切り替え | JellyConのほうが適している | 通常は簡単 |
| HTPCでの幅広いダイレクトプレイ | 多くの場合、優れている | クライアントによる |
| リモート・モバイル利用 | あまり自然ではない | より適している |
Kodiを追加したからといって、サーバーハードウェアを変更する必要はありません。まずクライアントアーキテクチャを選び、その後、実際の再生コンテンツの構成で再テストしてください。ダイレクトプレイへの対応が向上すれば、サーバーのトランスコード需要を減らせる可能性があります。
よくある質問
JellyfinとKodiを組み合わせると、Jellyfinサーバーは不要になりますか?
いいえ。Kodiは再生クライアントおよびインターフェース層です。Jellyfinは、ライブラリの状態、ユーザー、メタデータ、リモートアクセスを管理する中心的なサーバーとして機能します。
JellyConは、同期型のJellyfin for Kodiワークフローと同じものですか?
いいえ。JellyConはサーバーを動的にブラウジングします。一方、同期型のKodiワークフローでは、Jellyfinライブラリの状態をKodiのローカルデータベースにより多く保持します。
製品比較
もっと読む

JellyfinメディアボリュームにはZFS、Btrfs、ext4のどれが適している?
リカバリーモデルに応じてJellyfinのメディアファイルシステムを選択しましょう。プールの整合性を重視するならZFS、LinuxネイティブのCoWならBtrfs、運用の複雑さを抑えるならext4がおすすめです。

Jellyfin内蔵バックアップとファイルレベルバックアップ:どちらを使うべき?
便利なアプリ状態の復元にはJellyfin内蔵のバックアップを使用し、ホストやデプロイメントのより広範な状態も復元する必要がある場合は、停止した状態でファイルレベルのバックアップを使用してください。

JellyfinのCPUコア数を増やすと、実際にいつ高速化するのか?
Jellyfinでコア数を増やす効果があるのは、制御された低コア数の候補がCPUバウンドになり、同じワークロードがより大きなプロセッサでスケールする場合に限られます。

