ナマケモノの家

ナマケモノ

注意：このテキストの内容は古いです。

目的

Raspberry Pi 3B+ ＋ Raspbian ＋ PX-Q3U4 + epgrecUNA で録画サーバーを 構築して試行したが、思った以上にドロップがあるので、 録画したファイルの全数の drop 数をカウントし、対策を検討する。

drop 数のカウント結果 (その１)

条件

  1. 期間 ： 2019/01/20 〜 2019/02/21
  2. 対象は主に BS の 30分番組
  3. カウント方法は tsselect を実行し、パケット数の上位 10 番目までの PID に限定する。
drop数 本数 備考
0以上 10未満 137 本  
10以上 50未満 14 本 3本同時が 1組, 2本同時が 4組
50以上 100未満 4 本 2本同時が 1組,単独が2本
100以上 17 本 3本同時が 2組, 2本同時が 2組,EPGと重複？4本
計 172 本  

考察

  1. 録画中に 定期の EPG 取得があるとドロップする。
  2. epgrecUNA の機能として、録画の3分前に EPG 取得の動作があるが、 それが録画中に起きると、ドロップする。
  3. 3本はもちろん、2本同時録画でもドロップしやすい。
  4. その他に、原因不明だが “Cannot tune to the specified channel” で録画や EPG取得に失敗する事が数回あった。(reboot しないと復帰せず。)

対策案

根本的原因は、CPU が非力なのでデータの転送に間に合わない事によると思われる。 従って対策は次のものが考えられる。

  1. ドライバ(カーネル) の動作を極力妨害しないように、 それ以外のプロセスの優先度を下げる。

  2. 試験的に mysql を別のマシンに移設して mysqld の停止。 (スタンドアロンで無くなるのは問題なので、結果が良ければ DB を sqlite に換装することを検討する。)

  3. 録画と同時に行っていた b25 エンコードを、別のタイミングで行うように。

  4. 録画中は 定期の EPG取得のスクリプトを動かさないように。

  5. 録画開始前の EPG取得を止める。

  6. MTA の postfix を止め、msmtp に替える。

  7. 予防的に毎朝 OS をreboot する様に。

対策後の drop 数のカウント結果

上記の対策をした結果は次の通り。

条件

  1. 期間 ： 2019/03/07 〜 2019/03/20
  2. 総録画時間は 95 時間
  3. 内訳は, ３本同時 28本、２本同時 49本、単独 96本
  4. その他の条件は、その１と同じ
drop数 本数 備考
0 126  
1 〜 10 36  
11 〜 25 2  
26 〜 50 6  
51 〜 100 3  
計 173  

以上のことから、BS ３本同時までならば実用的には問題ない範囲と判断する。 (残る問題は mysql のサーバーをどうするか。)

参考データ

地デジ,BS,CS を組みわせた場合の、可否は次の通り。

条件 ビットレート(Mbyte/秒) drop数 判定
地デジ × 3 5.81 0 ○
BS × 3 7.24 たまに小 ○
地デジ × 4 7.75 小 ×
BS × 2 + CS × 1 9.06 多 ×
BS × 4 9.31 多 ×