PT3を用いた視聴環境をmirakurunで再構築した対応のメモ

PCにおけるTV視聴環境の再構築

これまでPT3をWindowsマシンにインストールして利用していた環境を、引っ越しに伴う配線の都合もありLinux+mirakurunで再構築を行ったところ、いろいろと想定と異なる事態が起きてトラブルシュートを行ったのでその対応メモを残す。

視聴環境

昨今の情勢もあって引越し先ではリモートワーク用の部屋を用意したが、その部屋にはTV端子がなく、寝室にTV端子がある状態なので、寝室に古いサーバを置いてそれを録画サーバとし、クライアントからはネットワーク経由で視聴できる環境を構築することにした。

録画サーバにはASRock Rackのc2550d4iを使うことにした。Avoton C2550という骨董品だが、録画サーバぐらいにはなるかと思いすでに引退していたのを引っ張り出してきた。(これが後のトラブルを引き起こす)

Ubuntu Server(LTS)のインストールとMirakurunのセットアップ

なにはともあれまずはサーバにPT3を装着し、OSを入れないと話にならない。
幸い、d2550d4iにはPCIeが1スロットだけあのでPT3装着に物理的な問題はない。

Linuxと録画サーバ構築をキーワードに検索すると、現在(2021年)はMirakurunで録画環境を構築するのが主流の様子で、無駄に古い構成を使う理由はないので採用することとし、推奨されているUbuntu Server(LTS)のインストールを行った。
dockerのインストールはネットに溢れかえっている情報を参照すれば問題なし。Mirakurunもオフィシャルのドキュメントに従ってデプロイを実施した。

視聴ソフトで視聴できないトラブル

録画サーバの構築が完了したので、動作確認のためTvTestやVLCで視聴確認をしたところ、音声も映像も出ない。この状態から切り分けが始まった。

まずサーバ側でそもそも放送波を受信できていない可能性を考えたが、EPGデータの受信は行えているので、放送波の信号は受信できており、PT3は正しく動作していると判断した。
Mirakurunのログを追っていくと、クライアント側から視聴をおこなった場合にデコーダーがプロセスダウンしているように見えたため、おそらくC2000系の古いAtomプロセッサではデコードに対応していないと判断した。ハードウェア問題となると根本的にはCPUなど一式を交換せざるを得ないが、現時点でそこまでやる気はないので、別の手段で解決策を図ることにした。

Mirakurun多段構成の活用

自宅のPC環境は、ファイルサーバやVPNサーバを仮想環境(KVM)上で動かしているRHELホストマシン(RHEL8)がある。Mirakurunの仕様を確認すると、多段の構成が取れるので、RHELホストマシンでもMirakurunを動かし、リモートチューナー指定してデコードはRHELホストマシンで実行させることで、追加投資せず視聴環境を構成できるのでは、と考えた。

KVMとdocker

RHELホストマシンでdockerを動かすためインストールを行おうとしたところ、RHELネイティブに対応したdokcerがない¹ため、CentOS用のdockerをインストールする必要があった。

最初にレポジトリを追加する。

bash

sudo dnf config-manager --add-repo=https://download.docker.com/linux/centos/docker-ce.repo

続けてdockerをインストール

bash

sudo dnf install docker-ce

これでdockerのインストールまで完了となる。

dockerの有効化とKVMゲスト通信のトラブル

インストールしたdockerをsystemctlで有効化したところ、KMVゲストが外部と通信不可となる事象に遭遇した。
自環境のKVMゲストは外部との通信にホストのネットワークをbridgeする設定で利用している。dockerを有効にするとネットワークを分離するためiptablesを利用するみたいだが、このルール追加によってbridge通信に影響が出るようだ。
試しにfirewalldを無効化し、iptablesでbridge通信を許可すると、ゲストの外部通信が正常化した。

そうなるとdockerを有効にしてもbridgeが有効になるように設定追加をする必要がある(RHELホストマシンはクローズドな環境なので多少乱暴でもいいからdocker有効後もKVMのbridgeが動くように割り切る)。
起動時のiptablesフィルタルール追加か、カーネルパラメータの設定か、ネットの情報を見てもどちらが推奨方式なのか判断つかなかったが、ひとまずカーネルパラメータで対処することにした。

sysctl

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

dockerとKVMの共存が構成できたので、RHELホストマシンにmirakurn on dockerをデプロイしたところ、初期設定で/dev/dvbがないと怒られた。RHELホストマシンは元々TV視聴環境を組んでおらずPTも組み入れていなかったので当然である。docker-composeの指定を修正すればいいだけであろうが、もうこの頃は切り分けで疲れていたので、未稼働のPT1をRHELホストマシンに装着し、/dev/dvbを作り出す力技で一旦逃れることにした。

無事、RHELホストマシンでmirakurunもデプロイできたので、/opt/mirakurun/configのtuners.ymlをリモートチューナー多段構成の設定に修正し、TvTestやvlcで視聴テストしたところ、今度は無事に視聴できた。一通り視聴ができるまでが長かった。

残課題

これで視聴環境の構成はできたものの、残課題が残ってしまっている。

• sysctlでbridge関係のパラメータが起動時に設定されるようにしているが、dockerが起動後に設定しないと意味がない。dockerの起動イベントの後にsysctl --systemで有効化をさせたいが手段が不明。

きちんと調べれば起動スクリプトの調整で指定できると思われるが、そんなに頻繁に再起動はしないので、当面は手動でsysctl --systemを使う運用で凌いでいる。とはいえこのままだと停電など発生時に、復電後コマンドを叩くまでKVMゲストからの通信が外に出られないので、早めに手を打つ必要がある。

1. どうやらPodmanをRedHat社は推奨している様子だが未調査 ↩