もともとのSH170R8の位置付けはサーバ用途で購入したZBOX CI520+外付けディスクアレイと録画サーバ用途として購入したSH67H3を統合する事。GlusterFSとしての動作は特に問題なかったが、PX-Q3PEでの録画には何故かノイズが多かったので、SH67H3での運用に切り戻していた。そのときはCentOS7をkernel4系に上げていたので、それが原因かもと考えた。最近やっと、SH170R8でもCentOS7.2の標準kernelで構築できるようになったので、再び録画サーバとしての機能を移植してみる。

PX-Q3PEとSCR3310v2.0を繋ぎ変えるのは面倒だけど、録画サーバの移植は簡単。kickstartファイルを指定してvirt-installすれば録画用の仮想サーバが出来上がる。すぐに仕上がった録画サーバで試験してみると、悲しいことにどうしてもブロックノイズが乗ってしまう。SH170R8の設定はSH67H3で動かしていたときとまったく一緒のはず。とすると、やはりハードウェアの問題なのだろうか。この時点ではBSのブロックノイズが非常に目立った。

Shuttle SH170R8 ベアボーン 価格：33998円（税込、送料無料) (2016/10/27時点)

ブロックノイズの発生原因は基本的に受信波が強過ぎるか弱過ぎるか。15dB、10dB、6dBの3つのアッテネータを駆使して、まずはがっつり受信波を減衰してみる。アッテネータをPCの手前だけでなく、ルータ側の根元に入れてみたり、複数のアッテネータをスタックさせてみたり。強く減衰させる方が安定するように見えたので、同じアッテネータをもう1セット買って更に減衰させたりしてみた。結果、映らなくなるギリギリまで減衰しても安定しない。

もう少し正しく言えば、きれいに録画出来るときもあれば、同じ構成でもノイズが乗ってしまうこともある。つまり受信波の強弱でノイズが乗っているとは言えないと判断した。まあ、SH67H3なら何の問題もなく録画できていた訳だしね。次に考えたのはBIOSの設定。以前、キャプチャーボードによる録画でノイズが乗ったときにCPUのEISTが悪さをしていることがあった。BIOSの設定を見回して、怪しそうな設定を無効化していく。

CPUのEISTとCステート機能、オンボードのオーディオ機能もオフった。もう少し見ているとPCIEの設定でAUTO/Gen3/Gen2/Gen1を選択出来る箇所があった。PX-Q3PEもPCIEに刺しているので、ちょっと怪しいかも。移行前のSH67H3は製造年月からきっとPCIExpress 2.0で動いていたのではないかという想像してGen2に変更。これで再起動して録画試験をするとBSのノイズが消えた！やはりハードウェア的な問題を抱えていたのか。

簡単にまとめているけど、この時点で既に1週間くらいは悩んでいたので狂喜乱舞。1つ1つ設定を有効に戻しながら効果のある設定を絞り込む。やはりPCIEのGen2でした。これでノイズの問題は片付いたと判断。ここまで2号機の方で検証していたので1号機にも同じ設定を適用し、念のため録画試験をする。うんうん、何の問題もなく・・・という訳にはいかなかった。目を疑うような事実だったが、1号機では地上波にノイズが乗ってしまう。

新製品 Shuttle SH170R8 新デザイン!アルミ製シャーシ採用 キューブ型ベアボーン 価格 : 35,620円（税込、送料無料） by Yahoo! ショッピング

どれだけセンシティブなんだよ、とさじを投げたくなるが、あと一歩のところまで来ていることは事実。諦めずに問題を特定する。BIOSの設定をいろいろ組み替えてみるが、Gen2以上に効果のある設定は見つからない。2号機にはノイズが乗らないので、1号機2号機と同時録画を行って比較をしてみる。スクリプトは8チューナー同時に録画する形になっていて、かつ記録先がGlusterFSなので、合わせて16並列ｗ 調子に乗ったこの試験では、何と2号機の録画データにもノイズが乗ってしまう。

もしやGlusterFSがいけないのか。もしかしなくとも最初に疑えよと言われると返す言葉もないんだけど、SH67H3のときも記録先をGlusterFSにしていて問題なかったからねえ。いろいろな条件で調べた結果、同じノード内で録画データ記録先のbrickに別のI/Oが発生しているとノイズが乗るとわかった。1号機はsambaが動いており、ファイルサーバとしての処理があるためにノイズが乗り易かったのかと納得。GlusterFSというよりはHDDの問題でSSDだと大分まし。

記録処理を行うのはatに登録されるスクリプト。このスクリプト内でrecpt1の1次記録先をローカルのSSDに変更して、録画終了後にGlusterFSに移動させるような処理に変更した。epgrec UNAの場合、この辺りの処理はReservation.class.phpにあるので記録時の仕様を変えたければこれをいじるといい。記録後の処理をトランスコードで行うことも可能だが、私はわりとat内で全ての処理を行うように変更している。

ちなみにReservation.class.phpを修正しても既に登録されたatは変更されないので、一度予約データとatを消して再登録する必要がある。atの更新忘れは結構事故の元で、例えば録画ディレクトリを変更した時などもatを更新しないと古いディレクトリを使ってしまうはず。録画サーバ再構築時もDBは引き継ぐので予約データがあるかのように見えるが、実はatが消えてしまっているということも。こういうときも一旦予約データを消してatを再登録する必要がある。WebUIで1件1件消すのは手間なので、以下のコマンドで消し去っている。

rm -f /var/spool/at/a00*
mysql -uxxxx -p epgrec
delete from xxxx_reserveTbl where complete=0;

SH170R8で安定した録画環境を作るのは非常に骨が折れたが、それでも1つ1つ調べていけば何とかなった。不安定な印象のあるPX-Q3PEに全ての原因を押し付けたくなるが、今回のノイズはあくまで環境側の変更で改善することができた。これだけ様々な要素の影響を受けてしまうのが録画サーバの悩ましいところか。他のチューナーボードは使ったことないので、BIOS設定やI/Oの干渉を受けやすいのが、PX-Q3PEの問題かどうかは判断できないが。ともあれ、ようやく手に入れた安定的な録画環境。運用面でもかなり自信が付いたし、やっと本格的な利用開始かなｗ