テレビ録画メディアサーバー構築入門（第１８回）
視聴が録画に追いつかない。内蔵ストレージ警告（第１０回）がでるようになった。
とりあえず「映画」ライブラリだけ、外付けHDDに移行することにした。
手順は次の通り。
フォーマット
マウント
ファイルコピー
Jellyfin再起動
設定変更
フォーマット
外付けHDDをUSB接続する。たいていの場合は問題なく認識するはず。認識していれば、「ユーティリティ」の「ディスク」アプリから見える。
まず、パーティションを作成し、初期化する。「Linux用の内蔵ディスクとして使用する(Ext4)」
linuxとwindowでは、ファイルシステムの書き込み仕様（ジャーナリングファイルシステム）が大きく異なります。ファイルシステムをlinux用にする必要があります。
マウント
フォーマットが終わったら、マウントオプションを編集。「デフォルト」は使用せず、マウントポイントにわかりやすい名前をつける。例： /buffalo
HDD（ストレージデバイス）は明示的にマウントしないと、OSからファイルシステムとしてアクセスできません。
「システム起動時にマウントする」「ユーザーインターフェースに表示する」
マウントすれば、通常のフォルダのように（マウントポイント/buffaloから）アクセスできます。「マウント」は再生ボタン（▶）です。取り外すときは、アンマウント：停止ボタン（■）。
他のUSB機器もそうですが、外部機器の接続・取り外しには、決まった手順を踏む必要があります（第１１回）。
ファイルコピー
編集済み映画は./movies に保存してあるので、新HDD/buffaloにそのままコピーする。新たな動画が書き込まれない時間帯に作業する。
mkdir /buffalo/movies
cd
rsync -avh --progress ./movies/ /buffalo/movies/Jellyfin再起動
前回からの変更点は、--mount type=bind,source=/buffalo/movies,target=/movies
sudo docker stop jellyfin
sudo docker rm jellyfin
sudo docker run -d --name jellyfin --user 1000:1000 --group-add="110" --device /dev/dri/renderD128:/dev/dri/renderD128 --net=host --volume ./jellyfin/config:/config --volume ./jellyfin/cache:/cache --mount type=bind,source=./media,target=/media --mount type=bind,source=/buffalo/movies,target=/movies --mount type=bind,source=./downloads,target=/downloads --restart=unless-stopped --volume /usr/share/fonts:/usr/share/fonts --volume /usr/share/fontconfig:/usr/share/fontconfig jellyfin/jellyfin:10.10.7（2025/11/7追記： 末尾にバージョン10.10.7を追加。Jellyfinは10/19に最新安定版10.11.0がリリースされた。大型アップデートのため、最新版に更新すると、バックアップなしでは、旧版には戻せない（新規インストールが必要となる）。基本機能が安定するまでは、10.10.7の使用を推奨します。）
設定変更
作業ディレクトリの設定を新ディレクトリ/buffalo/movies に書き出すように書き換える。どこを書き換えればよいかは、grep で調べる。
takya@fearow22:~/work2$ grep movies *.sh
enc01.sh:OUTDIR="/buffalo/movies/"
remove_empty_dirs.sh:MEDIA_ROOT="/buffalo/movies"
update_thumbs.sh:MEDIA_ROOT="/buffalo/movies"3つでてきたが、update_thumbs.shは第１３回でコメントアウトした（から修正不要）。
takya@fearow22:~/work2$ grep update_thumbs.sh *
enc01.sh:#$encoded && $WORKDIR/update_thumbs.shenc01.sh と remove_empty_dirs.sh を新ディレクトリ/buffalo/moviesに書き換える。
しばらく様子を視て、問題ないようなら、元のディレクトリは削除してよい。
rm -ir ./movies
ディスク圧迫対策1
ストレージを圧迫する最大の要因は、録画サーバーEPGStation が書き出す m2ts 動画ファイルです。
m2tsは番組情報等のメタデータを保持できるメリットがある一方で、ファイルサイズが巨大化する、互換性が低いなどの欠点があります。ここで紹介しているサーバー構築では、扱いにくいm2tsを捨てて、mp4で管理運用する前提で話をすすめています。このことに起因する「不具合」例は第１１回で触れています。
m2tsファイル膨張を軽減するには、第９回のdeleteold.py にて、削除までの保持期間「１週間」：
datetime_delete = now - timedelta(days=7) #1週間
を、できるだけ短くする。失敗した場合に備えての保持期間なので、毎日チェックできるなら「１日」にしてよい。
ちなみに「２日」で運用していると、m2ts（削除対象）が30-80GBになります。
takya@fearow22:~$ du -h --max-depth=1 ./ | sort -h
82G ./docker-mirakurun-epgstation
当然ですが、どれだけ貯めこむかは、その人の使い方によります。
通常録画./mediaは「見たら削除」で運用中。映画./moviesは見る暇がなく貯まっていくが、作品性が高いのと、見逃し無料配信がないので心理的に消去しにくい。
ディスク圧迫対策2
第２の対策法は、ffmpegのOPTIONを変更する。第５回のenc0.sh, enc1.sh で 画像のビットレート -b:v 5000k を小さくすれば、画質は落ちますが、ファイルサイズは小さくなります。ビットレートの適正値は解像度/フレームレートによります。
1080p（30fps）: 3000k～6000k
-b:v 3000k でも十分かもしれない。
可変ビットレートの場合も、同様に、好みで調整すればよい（第１６回）。
自分の視聴環境にあわせての最適化は、自サーバー運用の醍醐味ではあります。ただ、ファイルサイズ対策としては、エンコード、CMカット、この２つが最も効果大で、圧縮オプションの調整は、極端に画質を犠牲にしない限り、効果が薄い（最後の手段）です。
4K放送は必要？
つくづく思う。4K放送は必要なのだろうか。（単純にサイズが４倍になる。）
50インチ以下・視聴距離2m以上では4KとフルHDの差がほぼ識別不能になります。画質向上の最大の効果は、合法ユーザーが録画・バックアップすること、すなわちコンテンツを「所有すること」を困難にすることです。メディア産業が意図する「所有からアクセス権へ」の強制移行です。4Kがユーザー利益だけのために存在するとは、とても言い難いのではないでしょうか。
なぜ日本でJellyfinが流行らない？
わたしは録画マニアではない（なかった）ので、こんなこと考えることもなかったのですが、日本でJellyfinが流行らない理由は、日本人が著作権意識が高いから、というわけではなく、企業の思惑に乗らない頑固な個人が（持続可能なコミュニティを作るほど）多くないからでは、と思わずにはいられません。
自宅サーバー愛好家が増えてくれれば。
個人での録画動画所有がもっと普及してくれれば、と願っています。
技術は「利便性」と「自由」のバランスで発展すべき、と強く思わざるをえません。
ちなみに、最近では見逃し無料配信動画サービスが普及してきたので、（テレビチューナなしでも）ダウンローダとメディアサーバだけの最小構成でも大きな利用価値があります。
コメント