先日ANIME LOCKER機のチューナーカードを替え、システムを4系から6系にしたところ、なぜか地デジ録画のMP4ファイルが音ズレやブロックノイズでまくりに。BSは問題なし。以前は逆にBSの感度が低くてMP4変換が詰まることが多かったんですが、それは収まった模様（更新後一度も発生していない）。
MPEG2ファイルをのドロップ状況を調べて発生が確認できたので、受信環境の問題化と思いケーブルかえたりブースターを入れてみたものの改善せず。そもそも以前は同じケーブルまでの環境で問題なかったのでチューナー特性か個体差？と思って諦めてたんですが、ふとこちらの記事でエンコード負荷が高いとドロップするという指摘を拝見。
曰く、
- エンコード（ffmpeg）の同時実行スレッド数を抑える
- エンコードが実行される時間を録画が集中する時間からズラす
というアプローチ。とりあえず簡単に試せるのでトライ。たぶんシステムアップデートで上書きされて戻ってしまうのでとりあえずメモ。ちなみに本稿時点のシステムは6.1.4。
■エンコードのスレッド数を減らす
sshでログインして/home/foltia/perl/ipodtranscode.plを覗くと、確かに-threads 0というオプション指定をしてる箇所が多数見つかる。ffmpegの仕様を調べると0は自動でCPUのスレッド数の1.5倍で実行するらしい（どういう理屈？？）。ということで、ウチはi5/4570Tで2コア4スレッドなので、とりあえず-threads 4にしてみる（上記記事と同じ）。場合によってはもっと減らしてみてもいいかも知れない。
■エンコード実行時間を制限する
ユーザfortiaがcronで定期実行しているのはこれだけ。
25 5 * * * /home/foltia/perl/cron_foltia_dayly.sh >/dev/null 2>&1
25 4 * * 1 /home/foltia/perl/syobocalxml.pl 28 >/dev/null 2>&1
25 3 21 * * /home/foltia/perl/syobocalxml.pl 42 >/dev/null 2>&1
27 */5 * * * /home/foltia/perl/maintenancedb.pl LIGHT >/dev/null 2>&1
このうち、ipodtranscode.plを叩いているのはschedulecheck.plだけっぽい。ただし2番目の記事にあるrecwrap.plも録画実行スクリプトであるものの中でupodtranscode.plを呼んでるぽい。これがいつ呼ばれるかまでは追えていないですが、たぶん録画終了直後にこのブロックが実行されるんじゃないかと。ipodtranscode.pl自体は多重起動チェックをしているので、適当に呼んでも問題なさそう。なるほど、確かにschedulecheck.plとrecwrap.plからipodtranscode.pl呼び出しを押さえて、cronで任意のタイミングで実行するのは理に適ってそう。ウチの使い方ではそんなに即時エンコードは求めておらず、品質優先なので。
ということで有り難くパクらせていただき、schedulecheck.plとrecwrap.plの該当行（一箇所ずつ）をコメントアウト。
続いて、ユーザfoltiaのcrontabに
などとして朝5時過ぎにトランスコード処理が走るようにしてみた。
しばらくこれで様子見。ダメそうならスレッド数を更に減らす。またバージョンアップがあった時はこれを見て変更が戻されてないかチェックすること。
2019.06.22追記：あんまし効果なかったぽくて結局チューナーを増設しました..
「ANIME LOCKERのドロップ回避メモ」への2件のフィードバック