事象の水平線

2018年12月　4K8K本放送開始らしく、今までのFHD（フルハイビジョン=2K）放送の帯域を削って4K8Kに割り当てるべく、再編成だそうだ。

BS右旋の放送の帯域再編（周波数再編成）について

で、対処法を個人用メモ
recpt1が影響を受けるので、recpt1を再度コンパイルする。
その際、
Mercurial > pt1
の最新のパッチで対応できる。（メンテナンスありがとうございます。）

で、おわり。


なのだけど、
ストリーム配信のhttp版パッチ（参照先を後述）を当てているので、
最新のMercurial > pt1 のzipを持ってきて（Mercurial は入れてない。）http版パッチをそのまま当てると、最新のrecpt1がどうやら変数名を変えてるらしく、コンパイルでエラーが出てうまくいかない。
たしか、dec が decodeになってる。のと、argの型が合わないとか言われる。
無理やり合わせてコンパイルしたら、録画はできるが、http配信ができない。当然か。

ので、以前のrecpt1のソースを使い、それに新しいrecpt1のpt1_dev.hだけを置き換えてコンパイルすることにした。

EPGrecUNAは自動で対応してくれる。ので、まぁ、EPGを自動で取得するタイミングでなんかしてくれる。んだろう。実際、自動で変わったっぽい。

<<参考>>
recpt1　http版　怒られながら入れてみる
recpt1　http版　プロセスが落ちたときにphpで手動でブラウザからexecする
CentOS6.5　に　epgrec UNA

どうやら、明け方の雷で停電があったらしく、PT3-NASサーバーが再起動していた。
BIOSで停電復帰時にはPCが起動する設定にしているので、その後の予約も特に問題なく録画されていたのだが、ブラウザからアクセスすると、
プログラムテーブルが存在しないようです。インストールをやり直してください
や
construct:データベースに接続できない
といったことをのたまう。

以前もあって（そのときも確か停電）ソースを追ってごにょごにょいじって割と簡単に直った気がしていたけど、そのときどうしたか完全に忘れていたのと、またソース追うのめんどくさいのでぐぐったら割とビンゴなHPが有ったので、その通りやったらうまくいった。

いつもながらブックマーク的に個人用メモ。

[root@NAS ~]# service mysqld restart
Stopping mysqld:                                           [  OK  ]
Another MySQL daemon already running with the same unix socket.
Starting mysqld:                                           [FAILED]
[root@NAS ~]# rm -f /var/lib/mysql/mysql.sock
[root@NAS ~]# service mysqld restart
Stopping mysqld:                                           [  OK  ]
Starting mysqld:                                           [  OK  ]
[root@NAS ~]# 

これで、ブラウザからつながった。
予約が問題なく実行されていたのはatに入っていたからで、mysqlデーモンとは関係ないからでしょうね。
実際EPGrecのログのほうには予約が実行されたログがまったく残っていなかった。

<<参考>>
EPGrec運用における障害発生の記録と解決策 - 楪総研第三分室

EPGrec UNAで録画されるファイルネームの%TYPE%　%CH%が気に入らないので変えるためのソースの場所

Reservation.class.php
800行目くらい

$filename = mb_str_replace('%CH%',$crec_->channel, $filename );

　　↓

$CHstr = $crec_->channel_disc;
if( strpos($crec_->type, 'GR') !== false ){$CHstr = mb_ereg_replace("_[0-9]*", "", mb_ereg_replace("GR", "", $CHstr));}
if( strpos($crec_->type, 'BS') !== false ){$CHstr = mb_ereg_replace("BS_", "", $CHstr);}
if( strpos($crec_->type, 'CS') !== false ){$CHstr = mb_ereg_replace("CS_", "", $CHstr);}
$filename = mb_str_replace('%CH%', $CHstr, $filename );

とかなんとか。

UNAはとても複雑だ。理解できなくて全然いじれない････orz
スパゲティとか言うつもりは無いです。

epgrecの脆弱性を検証する

おっかないすなー。

epgrec UNAに移行して、tsselectも新規にインストールしたら、いきなり動かない。
どうもFloating point exceptionとか何とか言われる。

で、グーグル先生に聞いたら、某ニチャンのスレで答え発見。
進行状況表示で0割してるらしい。

なるほど、
tsselect.cの312行目と503行目の
n = (int)(10000*offset/total);
が0割になる時があるのかな。

てな訳で、
n = total != 0 ? (int)(10000*offset/total) : (int)(10000*offset);
というお粗末な事をしてコンパイルして終了。動くようになった。
標準出力だけのようなので、全体をif( total != 0 )で囲んでもよかったけど、直接ターミナルで動かした時、何の表示もなく数分固まるのもいやなので、むちゃくちゃだけどこうしておいた。

んー今までなかったのになぜだろう。いいのかな？まぁぃいゃ。cなんてぜんぜんわからんし～～。ドロップとエラーのカウントをしてログ吐いてるだけだし。

と、思ったら今度は
failed on open(/file/name) [src]
がでる。

で、どうやら32bitOSにしたせいらしい。こんな弊害が出るとは････

で、tsselect.cの頭に以下を入れてコンパイル、で、OK
#define _LARGEFILE_SOURCE
#define _FILE_OFFSET_BITS 64

参考『プログラミング/C,C++/2GBより大きなファイルの扱い』