テレビ録画メディアサーバー構築入門（第１１回）
優先順位
スタンドアローン（外部にデータ通信しない）
CMカット
オフライン再生（汎用mp4）
視聴履歴管理（別端末で再生再開、クロスプラットフォーム）
1.5-2倍速再生
スマートTV対応
次エピソードを自動再生、おすすめ
実際に運用してみて
EPGStation は録画管理サーバーでありながら、視聴用のメディアサーバーとしての機能も持ちあわせています。ただしそれは基本機能であって、現状実装されていない拡張機能については、近い将来に実装される可能性は極めて低い。
というわけで、上記の個人的要望を満たすべく、録画管理サーバー(EPGStation) と メディアサーバー(Jellyfin) を切り離して運用することにしました。
前回までの構成にて、ドラマや映画を無差別に予約録画しています。日を追うごとに、豊富なメディアコレクションが蓄積されており、とても満足しています。
「空フォルダの削除」（第９回）がしめすように、これまでは視聴後の動画は削除する流儀でした。動画を財産・コレクションとして保存しておく、という発想はありませんでした。
ネット配信ビジネスとの競合
撮り貯めしてわかったのは、テレビ番組の質は、かなり高いということです。撮っておかないと、大きな損をしているかのようにすら感じます。時間が重複して録画できなかった番組をなくすために、チューナーがもう１本欲しい気分になってきました。録画マニアの気持ちが理解できるようになりました。
PCを流用すれば、実質出費はUSBドングルチューナ１本（約５０００円）。自前のサーバー構築ふくめて、テレビ録画視聴は多くのひとにとって、よい趣味になるはずだと、あらためて実感しました。金銭面より、手間をかけられるかどうかが重要なので、やはり趣味の領域だとは感じます。
メディアサーバーを自己ホストするには、ある程度の技術的な知識や初期投資が必要です。とはいえ、こうしたユーザー数が増えれば、一般向けネット配信サイトのビジネスモデルを脅かす存在になりえます。しかし、そういう時期は訪れるでしょうか？
上記の優先順位の上位を重要視するユーザーは、一定の割合（少数派）で存在し続けるでしょうが、マーケットを脅かすほど拡大するとは考え難い気がします。
最大の理由は、撮り貯めして痛感したのですが、日々蓄積し続ける動画メディアファイルを個人的に（ローカルに）所有・管理し続けることは、現実的ではないという事実です。整理しないと、あっという間に保存領域が枯渇します。わざわざ手間をかけて自分で保管するコストはバカになりません（面倒）。
第２の理由は、購入時にインストールされているWindows OSを削除する勇気をもてるか？（不安）。慣れてしまえばLinux生活には、なんの問題もありません。（ワード、エクセルのような）マイクロソフト製品なしでは支障が生じるなら話は別ですが、Linux OSは使い勝手がすこし異なるだけです。サーバー用途にはGUI（デスクトップアプリ窓）は不要です。スマホやスマートTVから視聴することを考えると、むしろ色々と優秀で好都合だから Linuxを使うわけです（第２回）。
なぜ自己ホストするのか？
なんとしてもCMを見たくない。自分の流儀でコレクション。Linuxで遊びたい。（マイクロソフトふくむ）大企業の支配下から逃れたい。
こうした、ライトでプライベートな使用法が、自己ホストメディアサーバーが求められる「隙間市場」になります。
些細な問題発生
ここまで解説してきた構成にて、これまでのところ、おおむね、かなり満足に運用できています。
ただ、例外的に「不具合」が生じるケースがありました。こうした、細かな問題が時々発生するのが、自己ホストの難点ではあります。
録画動画が、EPGStationでは問題なく再生されるが、Jellyfin では二ヶ国語や解説つきになる場合がありました。
具体的には、「【連続テレビ小説】あんぱん」で、直前の番組によって音声が解説付きになる。「ニュースウオッチ９」で左音声が英語になる。理由は、m2tsとffmpegの仕様によるものです。
この問題は、ffmpegにかける前にtsreadexを通すことで解決します。
wget https://github.com/xtne6f/tsreadex/archive/refs/heads/master.zip
unzip -x master.zip.1
cd tsreadex-master
make
sudo cp tsreadex /usr/local/bin/対策: enc01.sh
前回追加した１行(#先頭をカットしてcopy)を置き換えるだけです。冒頭の変数は適宜変更のこと。
#!/bin/bash
SOURCEDIR="$HOME/docker-mirakurun-epgstation/recorded/"
WORKDIR="$HOME/work/"
OUTDIR="$HOME/media/"
NHK1="GR20"
NHK2="GR13"
NTFY_URL="https://fearow22.taile153a7.ts.net/PX-S1UD"
encoded=false
$WORKDIR/toprocess.py | while IFS= read -r FILE;
do
cd $SOURCEDIR
if [ -f "$FILE" ]; then
FILENAME=${FILE%.*}
GRSTRING=`echo $FILENAME | sed -n 's/.*\(GR[0-9][0-9]\).*/\1/p'`
cleaned_filename=$(echo -n "${FILENAME}" | sed 's/[ \/\&\*\$]/_/g')
# ffmpeg -ss 0.04 -i "$FILE" -c copy $WORKDIR/"$cleaned_filename".m2ts #先頭をカットしてcopy
# tsreadex -x 18/38/39 -n -1 -a 13 -b 5 -c 1 -u 1 -d 13 "$FILE" > $WORKDIR/"$cleaned_filename".m2ts
ffmpeg -ss 0.04 -i "$FILE" -c copy -f mpegts pipe:1 | tsreadex -x 18/38/39 -n -1 -a 13 -b 5 -c 1 -u 1 -d 13 - > $WORKDIR/"$cleaned_filename".m2ts
cd $WORKDIR
if [ -z $GRSTRING ] || [ $GRSTRING = $NHK1 ] || [ $GRSTRING = $NHK2 ]; then
# NHKならば
# ./enc0.sh $SOURCEDIR/"$FILE" ${FILENAME}.mp4
./enc0.sh "$cleaned_filename".m2ts "$cleaned_filename".mp4
else
# NHK以外
# ./enc1.sh $SOURCEDIR/"$FILE" ${FILENAME}.mp4
./enc1.sh "$cleaned_filename".m2ts "$cleaned_filename".mp4
fi
if [ -s "$cleaned_filename".mp4 ] ; then
# ./mvjf.sh ${FILENAME}.mp4 $OUTDIR
./mvjf.sh "$cleaned_filename".mp4 $OUTDIR
curl -H "X-Priority: 2" -d "mp4 created: $FILENAME" $NTFY_URL
rm "$cleaned_filename".m2ts
else
echo ERROR: mp4 not created
curl -H "X-Priority: 3" -d "ERROR: mp4 not created: $FILENAME" $NTFY_URL
fi
./processed.py "$FILE"
encoded=true
fi
done
$encoded && $WORKDIR/update_thumbs.sh
通知の重要度(X-Priority)を１段階下げてあります。使い慣れて、うるさくなってきたので。
デバイス認識不具合
第１回で「おすすめ」したカードリーダ（５００円）は、値段相応に「やぐい」（頑丈ではない）。
物理的にすこし位置を変えたためか、USB端子の接触不良によりBCASカードが読み取れない状態になり、録画が失敗していたことがありました。カード認識上の問題は、Mirakurunのlog に次のようなエラーを出します。
2025-05-07T21:59:45.023+09:00 error: TSDecoder#0 unexpected deadUSBチューナーPX-S1UD（または互換品MyGica S270）は、長期間使用し続けていると機能しなくなることがある。とりわけ、ライブ視聴には向かないようです。Mirakurunの新機能を見てみたくて遊んでいたら、認識しなくなることがありました。予約録画されないことで気づきました。Mirakurunのlogにはエラーは出ていませんでした。
このエラー、チューナーが瞬間的に電力消費した結果として、カードリーダーが機能停止して出ることがあります。こういうハードウェア的な不具合はカード処理をソフトウェア的に代替すれば解消するのですが。いわゆるsoftcas。第３回参照。
カードリーダ同様、チューナーの場合も、以下の手順で、USBを刺し直すか、もしくは、PCを放電すれば元に戻る。ただし、USBデバイスの抜き差しは、必ず手順を踏んで行う必要がある。PCが手元にあるならよいが、遠隔地にあるならkernel panicで応答不能になります。
USB再接続手順
USBデバイスを抜き差しする前には、必ず Mirakurun を停止させる。
cd
cd docker-mirakurun-epgstation
sudo docker-compose down簡単な順に、
USBを抜いて、放電して、刺しなおす。または、
USBを抜いて、刺して、再起動 sudo reboot。または、
USBを抜いて、sudo shutdown -h now。PCのコンセントを抜く。放置。刺す。PC起動。
そして、サーバー起動
cd
cd docker-mirakurun-epgstation
sudo docker-compose up -dPX-Q1UDは非推奨
チューナー数を増やしたいのであれば、PX-S1UD（MyGica S270）を複数ならべて用いるほうがよい。チューナーを増設したら、第３回の手順を最初からたどる方が、むしろ時間の節約になります。docker同梱のsetup.shがよくできているためです。
PX-S1UDを4台並べたものと同等な，PX-Q1UDというチューナがあります．USB端子が１つで済むというメリットはあるのですが，PX-Q1UD (４チューナー)は、PX-S1UDより不安定で、しばらく使用していると、録画データが「ドロップ」（欠落）ノイズを生じはじめることがあります。この場合、USBを抜き差しするのが、もっとも簡単な対処法になります。安定性の欠如は大きなデメリットなため、PX-Q1UDはおすすめとは言い難い。
なお、PX-S1UDでは、Q1UDのような「前兆」（前触れ）は少ないように感じます．録画失敗で異常を知るケースが多く，デバイス自体が認識されていない状態になります。（チューナーの安定性の低さは，これらがマニア向けではない最大の理由です。）
USBデバイス監視スクリプト
usb_monitor.sh
#!/bin/bash
NTFY_URL="https://fearow22.taile153a7.ts.net/PX-S1UD"
prev_file="$HOME/.usb_devices_prev"
curr_file="$HOME/.usb_devices_curr"
lsusb | sort -u >$curr_file
if [ -f "$prev_file" ]; then
DIFF=`diff $prev_file $curr_file`
if [ -n "$DIFF" ]; then
curl -H "X-Priority: 4" -d "$DIFF" $NTFY_URL
cp $curr_file $prev_file
fi
else
cp $curr_file $prev_file
ficrontab に登録:
* * * * * $HOME/work/usb_monitor.shうまいこと動作不良を検知してくれるか？ しばらく様子をみてみます。場合によっては、また次回（第１２回）があるかもしれません。
追記：usb_monitor.shはカードリーダー・チューナーの不具合検知には役立っていない。が、別の用途のためにそのまま利用している。
商用「専用アプリ＋クラウド型録画/再生」サービスに関して「気になる点」(2025/10/31追記メモ)
nasne／diga／REC-ON／miyotto のような「専用アプリによりネット経由で録画データにアクセスできる商用サービス」は便利ですが、懸念点が山ほどあります。
プライバシー（利用状況の収集）
問題点：視聴履歴、再生頻度、録画タイトル、デバイス情報、接続ログなどがメーカー／サービス側に送られる可能性。広告や解析に使われる。
対策：プライバシーポリシーを確認。設定でテレメトリ／解析をオフにできるか確認。ネットワークで送信先を監視（ファイアウォール／Pi-hole等）して不要な送信をブロック。
サービス終了（継続性／廃止リスク）
問題点：クラウド機能や認証サーバーが停止すると、リモート再生やアプリ連携が使えなくなる／機能が制限される。
対策：ローカルでの再生・ファイルのエクスポート方法を確保。重要録画は別媒体へバックアップ。
DRM／ロックイン（録画データの所有権）
問題点：録画ファイルが暗号化・非標準フォーマットでエクスポート不可だったり、再生に専用サーバー認証が必要。
対策：購入前に「録画をLAN上で普通にコピーして再生できるか」「ファイルフォーマット」「エクスポート機能」を確認。
セキュリティ（脆弱性・遠隔侵入）
問題点：ファームウェアやアプリの脆弱性で第三者に家中のネットワークや映像にアクセスされる恐れ。リモートアクセス機能は攻撃面を増やす。
対策：定期的なFW/アプリ更新、管理UIの強固なパスワード、可能なら管理UIをLAN内限定にする。公開ポートを避け、VPN経由でのみアクセス。
データ保持期間と削除（ログ/録画）
問題点：サーバー側に保管されるログやメタデータの保持期間・削除方法が不明瞭。退会後も残る可能性。
対策：プライバシーポリシーを確認。削除・アカウント削除の手順を把握。必要なら問い合わせで確認。
第三者への共有・売却（データ流用）
問題点：匿名化データの販売、広告会社への提供など。
対策：利用規約／プライバシーポリシーで第三者提供の有無を確認。オプトアウトできるか確認。
法的リスク（録画した番組の扱い）
問題点：地域／サービスにより録画・配信に関する制約や可視化要件がある（著作権、再配布等）。
対策：商用再配信や外部共有をしない、権利に注意する。
互換性・標準準拠（将来の機器変更での扱い）
問題点：独自プロトコルやクラウド依存だと別メーカー機器で再生不可。DLNA/UPnPなど標準を使っているか重要。
対策：購入前に標準プロトコル対応状況を確認。オープンなフォーマット／トランスコード機能があるか見る。
広告・マネタイズ（UI内広告や提案）
問題点：UIに広告表示、推薦データに基づく個人向けプロモーションが組み込まれることがある。
対策：広告オプションや有料で広告を消す設定があるか確認。
自動アップデートによる不具合（brick/機能削除）
問題点：自動アップデートで互換性が壊れたり、以前の動作が変更される／機能が削除される場合がある。
対策：自動更新の設定を確認。重大な更新前にはリリースノートを読む。可能ならアップデートをテスト環境で先に確認。
サポート・ドキュメント（技術サポートの質）
問題点：サポートが貧弱でトラブルシュートできない・長期サポートが期待できない。
対策：製品レビューやフォーラム、公式サポート体制を事前に確認。
可用性とパフォーマンス（ストリーミング負荷）
問題点：ネットワーク混雑やクラウド経由の遅延で再生が途切れる、画質低下が発生する。外出先回線の影響も。
対策：LAN内での直接ストリーミングを優先、必要ならトランスコード設定やQoSを調整。
メタデータの扱い（番組情報・位置情報）
問題点：番組メタデータ（視聴履歴・ジャンル嗜好）が分析に使われる。位置情報やIPベースで地域判定され得る。
対策：メタデータ送信設定を確認。アプリに不要な権限を与えない。
法執行機関／政府アクセス（データ開示）
問題点：司法令状等でログや視聴履歴が国や警察に提供される可能性。
対策：重大な懸念がある場合はローカル保存を徹底し、クラウドへの依存を減らす。
スマートホーム／音声アシスタント連携によるデータ連携拡散
問題点：Alexa/Google Home等と連携すると、利用データがさらに別のクラウドに渡る。
対策：連携を慎重に設定、必要最小限の連携に留める。
取引停止・価格変更（サブスク、追加課金）
問題点：サービスの無料機能が有料化されたり、サブスクで継続コストが増える。
対策：契約条件と料金体系を把握。重要機能が課金依存か確認。
ハードウェア故障時のデータ回収難易度
問題点：内蔵HDDをメーカーが暗号化していると故障時にデータ救出が困難。
対策：定期的に外部バックアップ。暗号化の有無を確認。
長期アーカイブの可搬性（フォーマット劣化）
問題点：録画の長期保存で再生可能なフォーマットが維持されない可能性。将来の互換性が不明。
対策：重要な録画は汎用フォーマット（mp4等）で保存しておく。
親子アカウント／アクセス制御の不備
問題点：誰でも視聴・削除できてしまう管理設計だと第三者に録画を消される等のリスク。
対策：アカウント管理・アクセス権限設定を確認・強化。
メーカーの透明性（ログの内容・共有先が不明瞭）
問題点：どのデータをどこへ送っているかが不明だと監査・管理ができない。
対策：トラフィックキャプチャ（例：一時的にWireshark/内部ログで確認）で送信先を確認。公開している監査レポートがあるか探す。
コメント