正直、ここまで時間がかかるとは驚きだね。Wiiは現代のテレビ解像度に対応してないから、あんまり理想的じゃないのかな。

それに、Plexは価格モデルを変えてコミュニティを本当に怒らせたよね。

家庭サーバーの旅はPlexから始めたけど、どんどん悪化していって、Jellyfinに切り替えざるを得なかった。個人的にはJellyfinも同じくらい機能してるし、メディアをストリーミングするためにお金を払わせるビジネスモデルにはまだ陥ってないみたい。そんなコア機能にペイウォールを設けるのはかなり厳しいよね。

Jellyfinのセキュリティについて誰かコメントできる？前に調べたとき、Jellyfinのセキュリティモデルがちょっと弱いように見えて、家族をPlexから移行するのが不安だったんだよね。

Plexは、もし彼らが実際にコア市場が求めている機能に優先的に取り組むことに決めたら、1週間でこの流れを逆転できると思う。

PlexとJellyfinのどちらにするか決めるとき、Plexはセルフホスティングでもアカウントが必須だったから（！）、Jellyfinより良いのか悪いのか分からなかったんだ。だから、試す気にもなれなかったんだよね。

Intel ARC 380は4Kリアルタイムトランスコードストリームに最適だよ。そして安いしね。いくつかのバックエンドでトランスコードを行うスティッキーラウンドロビンリバースプロキシができるかも。最大の問題は帯域幅だけど、そこは分かってるよね。

480pだよ。過去20年間に使ったどのボックスでも、楽々とそれを処理できたよ。

同意だね。正直、ブランドが好きだからJellyfinを選んだんだけど、何か見逃してるのかな。Jellyfinはすごく楽しんでるし、ほとんどのデバイスに何らかの形で対応してるみたい。彼女はiPadやスマホ、パソコンに設定してるし、テレビにもアプリがあって問題なし。家にはNetflixもあるけど、彼女は技術に詳しくないから、ログインを教えたら特に困ったことはないよ。唯一のトラブルは、講義中に見ようとした時かな。Jellyfinは家でしか使えないって説明しなきゃいけなかった ;) （今のところね）

ひとつのコツは、ファイル名と整理をしっかりすることだね。これについてのドキュメントも充実してるし。そうすればほとんど自動的に進むから、追加の手間はほぼゼロだよ。命名規則もそんなに悪くないし、結果としてできるファイルツリーもファイルを整理するには合理的な方法だと思う。

Jellyfinを諦めて、AndroidとiOSのクライアントが同期を失ったり、あるシーズンの番組が表示されなかったり、白い背景に白い文字の番組があったりして、upnp/dlnaに戻ったよ。痛みがどんどん増していった。大体は結構良かったんだけど、毎回スマホを手に取るたびに、どれだけひどくなるか心配だった。Jellyfinを辞めるのは良い選択だったと思う。upnp/dlnaはもっと粗いけど、BubbleUPnPクライアントが直感的で使いやすい。私にはすごく合ってる。トランスコーディングサーバーもかなり良くて、好きなマシンで動かせるし、何にも依存しないから簡単に切り替えられる。BubbleUPnPはタブレットをキャストスクリーンに変えられるから最高。これが大好き。良い一般プロトコルは最高だね。メディアサーバー、メディアレンダラー、そして別々のコントロールポイントがあるモデルは素晴らしい、UPnPお疲れ様。

へへ、Jellyfinのバグをデバッグするのに15分かかったよ。WebOSクライアントがスタートアップウィザードがまだ完了してないと思ってたんだ（何度も再起動を試みたけど、結局デバッグログを有効にしたらちゃんと動き出した—多分偶然だと思うけど）。Jellyfinはクラス最高だけど、基準が地獄だよね。高可用性の構成では運用できないから、唯一のインスタンスがダウンしたり問題が起きたりしたら、すぐに修正しないと使えなくなる。何かがうまくいかないとき、いくつかのログはstderrに表示されるけど、大半は単純なファイルとしてディレクトリに書き込まれる。フリーソフトウェアだから、払った分の価値はあるけど、結構バグが多いよ。

今のところは大好きなんだけど、両方のテレビで唯一の問題はサーバーのIPアドレスを常に再入力しなきゃいけないこと。数日間は覚えてるけど、また消えちゃうんだよね。

ハードウェアアクセラレーションに興味があるなら、リモートハードウェアアクセラレーション戦略について調べてみるといいかも… https://jellyfin.org/docs/general/post-install/transcoding/h... JellyfinのDBは残念ながらsqliteで、DBに依存してるんだよね。もしかしたら、1つのノードだけが書き込みを担当して、他のノードは読み込みを担当するようにハックできるかも… 安いノードを複数使うことで帯域幅が増えるなら。Jellyfinはメディアストリームの管理をすぐにやめると思うけど。まあ、トランスコーディングとデータパイプのサイズが唯一の「ハード」な部分だと思う。DBの読み書き自体は問題ないと思うけど。

そうそう、めんどくさいよね。SQLiteはクラスターの真実の唯一のソースには向いてないし、複数の高解像度トランスコーディングセッションを同時に処理できるハードウェアを買った方が安く済むよ、でも20世帯分は無理だね。

参考までに、ARC B580で10本の同時ライブトランスコードストリームを管理したことがあるけど、もう少し増やせたかも。いくつかあれば大丈夫だと思うよ。もう一つのポイントは、NFSを使ってメディアストレージを共有すれば、異なる世帯グループ用に複数のJellyfinインスタンスを動かせるってこと。2、3ノードあればうまくいくと思う。

トランスコーディング用のハードウェアアクセラレーション付きのCPUしか持ってないけど、それでも同時にいくつかのストリームを処理できるよ。一番大事なのは、ダイレクトプレイをサポートしているクライアントを使ってもらうことだね。

Jellyfinはクラスター用に設計されてないよ。君の使い方なら、複数のインスタンスを展開するのがベストだね。