事象の水平線

個人的ブックマーク代わりなメモ書きブログ。 地球は丸いよ。↓このへん。

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

PageTop
自動予約の連続予約をテストしている際に、なぜかうまく連続予約されないので調べたら秒単位のEPG情報があっていすから転げ落ちた。

mysql>  SELECT starttime,endtime,title FROM Recorder_programTbl WHERE starttime REGEXP '....-..-.. ..:..:0[1-9]' OR endtime REGEXP '....-..-.. ..:..:0[1-9]' ORDER BY starttime;
+---------------------+---------------------+-----------------------------------------------------+
| starttime | endtime | title |
+---------------------+---------------------+-----------------------------------------------------+
| 2013-01-18 18:53:00 | 2013-01-18 19:00:03 | 気象情報 |
| 2013-01-18 19:00:03 | 2013-01-18 19:30:00 | NHKニュース7【二】【字】 |
| 2013-01-19 06:30:00 | 2013-01-19 07:00:03 | NHKニュース おはよう日本 |
| 2013-01-19 07:00:03 | 2013-01-19 07:30:00 | NHKニュース おはよう日本【字】 |
| 2013-01-19 11:54:00 | 2013-01-19 12:00:03 | 気象情報 |
| 2013-01-19 12:00:03 | 2013-01-19 12:17:00 | ニュース【字】 |
| 2013-01-19 18:53:00 | 2013-01-19 19:00:03 | 気象情報 |
| 2013-01-19 19:00:03 | 2013-01-19 19:30:00 | NHKニュース7【二】【字】 |
| 2013-01-20 06:53:00 | 2013-01-20 07:00:03 | 気象情報・ニュース |
| 2013-01-20 07:00:03 | 2013-01-20 07:45:00 | NHKニュース おはよう日本【字】 |
| 2013-01-20 11:54:00 | 2013-01-20 12:00:03 | 気象情報 |
| 2013-01-20 12:00:03 | 2013-01-20 12:17:00 | ニュース【字】 |
| 2013-01-20 18:53:00 | 2013-01-20 19:00:03 | 気象情報 |
| 2013-01-20 19:00:03 | 2013-01-20 19:30:00 | NHKニュース7【二】【字】 |
| 2013-01-21 06:30:00 | 2013-01-21 07:00:03 | NHKニュース おはよう日本 |
| 2013-01-21 07:00:03 | 2013-01-21 07:45:00 | NHKニュース おはよう日本【字】 |
| 2013-01-21 11:54:00 | 2013-01-21 12:00:03 | 気象情報 |
| 2013-01-21 12:00:03 | 2013-01-21 12:20:00 | ニュース【字】 |
| 2013-01-21 18:52:00 | 2013-01-21 19:00:03 | 気象情報 |
| 2013-01-21 19:00:03 | 2013-01-21 19:30:00 | NHKニュース7【二】【字】 |
| 2013-01-22 06:30:00 | 2013-01-22 07:00:03 | NHKニュース おはよう日本 |
| 2013-01-22 07:00:03 | 2013-01-22 07:45:00 | NHKニュース おはよう日本【字】 |
| 2013-01-22 11:54:00 | 2013-01-22 12:00:03 | 気象情報 |
| 2013-01-22 12:00:03 | 2013-01-22 12:20:00 | ニュース【字】 |
| 2013-01-22 18:52:00 | 2013-01-22 19:00:03 | 気象情報 |
| 2013-01-22 19:00:03 | 2013-01-22 19:30:00 | NHKニュース7【二】【字】 |
| 2013-01-23 06:30:00 | 2013-01-23 07:00:03 | NHKニュース おはよう日本 |
| 2013-01-23 07:00:03 | 2013-01-23 07:45:00 | NHKニュース おはよう日本【字】 |
| 2013-01-23 11:54:00 | 2013-01-23 12:00:03 | 気象情報 |
| 2013-01-23 12:00:03 | 2013-01-23 12:20:00 | ニュース【字】 |
| 2013-01-23 18:52:00 | 2013-01-23 19:00:03 | 気象情報 |
| 2013-01-23 19:00:03 | 2013-01-23 19:30:00 | NHKニュース7【二】【字】 |
| 2013-01-24 06:30:00 | 2013-01-24 07:00:03 | NHKニュース おはよう日本 |
| 2013-01-24 07:00:03 | 2013-01-24 07:45:00 | NHKニュース おはよう日本【字】 |
| 2013-01-24 11:54:00 | 2013-01-24 12:00:03 | 気象情報 |
| 2013-01-24 12:00:03 | 2013-01-24 12:20:00 | ニュース【字】 |
| 2013-01-24 18:52:00 | 2013-01-24 19:00:03 | 気象情報 |
| 2013-01-24 19:00:03 | 2013-01-24 19:30:00 | NHKニュース7【二】【字】 |
| 2013-01-25 06:30:00 | 2013-01-25 07:00:03 | NHKニュース おはよう日本 |
| 2013-01-25 07:00:03 | 2013-01-25 07:45:00 | NHKニュース おはよう日本【字】 |
| 2013-01-25 11:54:00 | 2013-01-25 12:00:03 | 気象情報 |
| 2013-01-25 12:00:03 | 2013-01-25 12:20:00 | ニュース【字】 |
| 2013-01-25 18:52:00 | 2013-01-25 19:00:03 | 気象情報 |
| 2013-01-25 19:00:03 | 2013-01-25 19:32:00 | NHKニュース7【二】【字】 |
| 2013-01-26 06:30:00 | 2013-01-26 07:00:03 | NHKニュース おはよう日本 |
| 2013-01-26 07:00:03 | 2013-01-26 07:30:00 | NHKニュース おはよう日本【字】 |
| 2013-01-26 11:54:00 | 2013-01-26 12:00:03 | 気象情報 |
| 2013-01-26 12:00:03 | 2013-01-26 12:15:00 | ニュース【字】 |
| 2013-01-26 18:53:00 | 2013-01-26 19:00:03 | 気象情報 |
| 2013-01-26 19:00:03 | 2013-01-26 19:30:00 | NHKニュース7【二】【字】 |
| 2013-01-27 06:53:00 | 2013-01-27 07:00:03 | 気象情報・ニュース |
| 2013-01-27 07:00:03 | 2013-01-27 07:45:00 | NHKニュース おはよう日本【字】 |
| 2013-01-27 11:54:00 | 2013-01-27 12:00:03 | 気象情報 |
| 2013-01-27 12:00:03 | 2013-01-27 12:15:00 | ニュース【字】 |
| 2013-01-27 18:53:00 | 2013-01-27 19:00:03 | 気象情報 |
| 2013-01-27 19:00:03 | 2013-01-27 19:30:00 | NHKニュース7【二】【字】 |
| 2013-01-28 06:30:00 | 2013-01-28 07:00:03 | NHKニュース おはよう日本 |
| 2013-01-28 07:00:03 | 2013-01-28 07:45:00 | NHKニュース おはよう日本【字】 |
| 2013-01-28 11:54:00 | 2013-01-28 12:00:03 | 気象情報 |
| 2013-01-28 12:00:03 | 2013-01-28 12:20:00 | ニュース【字】 |
| 2013-01-28 18:52:00 | 2013-01-28 19:00:03 | 気象情報 |
| 2013-01-28 19:00:03 | 2013-01-28 19:30:00 | NHKニュース7【二】【字】 |
| 2013-01-29 06:30:00 | 2013-01-29 07:00:03 | NHKニュース おはよう日本 |
| 2013-01-29 07:00:03 | 2013-01-29 07:45:00 | NHKニュース おはよう日本【字】 |
| 2013-01-29 11:54:00 | 2013-01-29 12:00:03 | 気象情報 |
| 2013-01-29 12:00:03 | 2013-01-29 12:20:00 | ニュース【字】 |
| 2013-01-29 18:52:00 | 2013-01-29 19:00:03 | 気象情報 |
| 2013-01-29 19:00:03 | 2013-01-29 19:30:00 | NHKニュース7【二】【字】 |
| 2013-01-30 06:30:00 | 2013-01-30 07:00:03 | NHKニュース おはよう日本 |
| 2013-01-30 07:00:03 | 2013-01-30 07:45:00 | NHKニュース おはよう日本【字】 |
| 2013-01-30 11:54:00 | 2013-01-30 12:00:03 | 気象情報 |
| 2013-01-30 12:00:03 | 2013-01-30 12:20:00 | ニュース【字】 |
| 2013-01-30 18:52:00 | 2013-01-30 19:00:03 | 気象情報 |
| 2013-01-30 19:00:03 | 2013-01-30 19:30:00 | NHKニュース7【二】【字】 |
| 2013-01-31 06:30:00 | 2013-01-31 07:00:03 | NHKニュース おはよう日本 |
| 2013-01-31 07:00:03 | 2013-01-31 07:45:00 | NHKニュース おはよう日本【字】 |
| 2013-01-31 11:54:00 | 2013-01-31 12:00:03 | 気象情報 |
| 2013-01-31 12:00:03 | 2013-01-31 12:20:00 | ニュース【字】 |
| 2013-01-31 18:52:00 | 2013-01-31 19:00:03 | 気象情報 |
| 2013-01-31 19:00:03 | 2013-01-31 19:30:00 | NHKニュース7【二】【字】 |
| 2013-02-01 06:30:00 | 2013-02-01 07:00:03 | NHKニュース おはよう日本 |
| 2013-02-01 07:00:03 | 2013-02-01 07:45:00 | NHKニュース おはよう日本【字】 |
| 2013-02-01 11:53:00 | 2013-02-01 12:00:03 | 気象情報 |
| 2013-02-01 12:00:03 | 2013-02-01 12:20:00 | ニュース【字】 |
| 2013-02-01 18:52:00 | 2013-02-01 19:00:03 | 気象情報 |
| 2013-02-01 19:00:03 | 2013-02-01 19:30:00 | NHKニュース7【二】【字】 |
| 2013-02-02 06:00:00 | 2013-02-02 07:00:03 | NHKニュース おはよう日本 |
| 2013-02-02 07:00:03 | 2013-02-02 07:30:00 | NHKニュース おはよう日本【字】 |
| 2013-02-02 11:54:00 | 2013-02-02 12:00:03 | 気象情報 |
| 2013-02-02 12:00:03 | 2013-02-02 12:15:00 | ニュース【字】 |
| 2013-02-02 18:53:00 | 2013-02-02 19:00:03 | 気象情報 |
| 2013-02-02 19:00:03 | 2013-02-02 19:30:00 | NHKニュース7【二】【字】 |
+---------------------+---------------------+-----------------------------------------------------+
92 rows in set (0.33 sec)


思い込みはよくない!!ということですが、おかげでプログラムを疑って2時間も無駄に失った。

く○ばれんhk

スポンサーサイト

PageTop
EPGrecの番組検索で放送局の絞込みプルダウンにスキップしてある放送局やら、録画しないに設定しているCSやらがダラダラ現れて邪魔なので、ちょこっといじってみた。
まぁ、頻繁には使わないから今までスルーしてたんだけど。

programTable.php公式epgrec_20111001.tar.gz)129行目から

$k_station_name = "";
// 放送局プルダウンの小改造
$option = " WHERE skip='0'";
if ($settings->cs_rec_flg == 0) { $option .= " AND channel NOT LIKE 'CS%'"; }
$option .= " ORDER BY type DESC";

$crecs = DBRecord::createRecords(CHANNEL_TBL , $option);
$stations = array();


ORDER BY 句とかはnameにするなりお好きにどうぞ。自分はこれが一番しっくりきたので。
ちなみに、データベースの構成はこうなってました。

mysql> show columns from Recorder_channelTbl;
+--------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+--------------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| type | varchar(8) | NO | | GR | |
| channel | varchar(10) | NO | | 0 | |
| name | varchar(512) | NO | | none | |
| channel_disc | varchar(128) | NO | | none | |
| sid | varchar(64) | NO | | hd | |
| skip | tinyint(1) | NO | | 0 | |
+--------------+--------------+------+-----+---------+----------------+
7 rows in set (0.00 sec)

PageTop
意味の分からんタイトルですが。
EPGrecで放送中の番組を予約すると、約3分後から録画が始まる。というのは多分EPGrecを使い始めるとすぐにそういう仕様なんだと理解すると思う。が、それをキャンセルしたときのお話。

条件
When:放送開始時間後に
What:その放送の録画予約をし、そこから10秒以内にその録画をキャンセルすると

現象
1:予約は削除される
2:が、3分後に録画が開始されて、しかも予約一覧にも録画一覧にも表示されない
3:HDDには録画されたものが出来上がる

なぜこんなことになるか?
EPGrecは録画予約の実行にatを使っている。
Reservation.class.phpの279行あたりでatによる予約をしている。)
が、atは秒単位の指定は出来ない。
(ので、実際の録画開始はrecorder.phpの200行あたりでwhileとusleepを使って秒単位のpendingを掛けている。)

Reservation.class.phpの61行あたりで既に開始されている番組だと、
$start_time = time() + PADDING_TIME + 10;	// 録画開始時間を3分10秒先に設定する
今の時間から3分(PADDING_TIME)+10秒後に録画が始まるようにしてある。

そして、64行目で
$at_start = $start_time - PADDING_TIME;
atの開始時間を、録画開始の3分前(PADDING_TIME)になるようになっている。
atが秒を理解すれば、これでも予約をしてすぐにatは走らない(10秒間は)が、atは秒を理解しないので、大概の場合放送中の番組を予約すると即座にatが走る。
例えば、01:10:23に既に始まってる放送を録画予約する。
        ↓
録画開始時間を01:13:33とし、atの開始時間を01:13:23としてatに登録する。
        ↓
が、atは秒を理解しないのでatには01:13が自分の開始時間(既に始まっている)と解釈し即スタート

で、atが走るとatがrecorder.phpを動かして、$starttime(Reservation.class.phpの$start_timeとほぼ同じ)待ちになる(約3分後に録画開始)

さらに、ここでこの予約のキャンセルをすると、Reservation.class.php
361行目cancel関数で
if( toTimestamp($rec->starttime) < (time() + PADDING_TIME + $settings->former_time) )

録画開始時間が、現在時刻(time())+3分(PADDING_TIME)+録画開始の余裕時間(秒)($settings->former_time)※
よりも早い(=録画が既に始まっている)ことで場合分けをし、
録画開始後ならrecorder.phpの動作を止め予約をキャンセルしようとする。
録画開始以前ならrecorder.phpは動いていない“はず”なので、単にatを削除し、MySQLのRecorde_reserveTblの予約を削除して終わっている。
(ここには10秒が加算されていない)
(※$rec->starttimeはMySQLの予約テーブル上の開始時間で$settings->former_timeが考慮されている。
$start_timeは番組表テーブル上の開始時間で$settings->former_timeは含まれていない。
本題とは無関係)


で、
atが秒を理解していれば、放送中の番組を予約録画し、10秒以内にキャンセルしてもこれでいいのだけれど、atは秒を理解しないので、これをやると、Reservation.class.phpのcancel関数ではまだ録画が始まっていないと判定されるのに、すでにatは走っていて、recorder.phpも走っている。ので、正常に予約録画はキャンセルされたように見えるのに、3分後には録画が始まってしまう。しかも、atが走ったあとにatが削除され(atが削除されてもrecorder.phpは止まらない)、MySQLのRecorde_reserveTblの予約情報も消えているので、予約一覧からも、録画済一覧からも見れない。


対策?
10秒はおそらく予約の処理のための余裕時間なのだろう。
これをなくせばいいという問題でもないし、他に10秒足せばいいという問題でもない。(通常の予約の時誤判定を起こす)
なので、これは根本対策をするのがベストで、
Reservation.class.phpで、放送開始後と判定されたら、以降は通常の予約と同じ手段をとらずに即座にdo-record.shをたたいて、MySQLには別個に録画予約を登録するのがいいと思う。
そうすれば、3分の待ち時間もなくなるし、この問題もなくなる。
当然後に控えてる予約とバッティングしないかをチェックしなきゃいけないのは現状と同じで、その処理はサブルーチン化されてないから書き起こす(コピペる)必要がある。次の予約までのDurationで撮るとかも当然可能だけど、どの道ちょっとしたtipsレベルではなくちょっとした改造になる。

と、いう所でそれをやるかどうかは・・・・・・
とりあえず、謎動作の原因が分かったので、メモ

EPGrecはLinux + PTxで一番使用者が多いと思うし、公開から数年たってるのでそこそこ枯れてるかと思ったのに、結構穴ぼこが多いなぁ;;
自動録画予約でも録画開始時間と放送時間変更とEPG更新のタイミングしだいでは録画失敗が起こりうるコードになってる。と思われる。
storeProgram.inc.phpの160行目とgetepg.phpの134行目のdoKeywordReservation();のタイミング参照
この間に放送開始だと録画されない。よね?
放送開始時間が頻繁に変更されるんhkで35分あたりから開始する番組で起こりうるのではないだろうか・・・
まだこの事象にはあってないけど。

しかし、ソースを見だしたら色々といじってしまった。メンテナンスが苦労するなぁ。。

PageTop
昨日、epgdumpのsegfault対策をしたのですが、その影響なのかはわかりませんが、EPGrecで開始時間よりも終了時間が遅い番組ができてしまうというおかしなことがおきたのでメモ

epgdump_bug00.png


今日は駅伝だかなんだかよく分かりませんけど、時間変更が頻繁に起きてた様で、んhkが間違った情報を流したのか、epgdumpがバグってこんなことになったのか分かりませんが、とりあえず、EPGrecのstoreProgram.inc.phpの135行目あたりを以下のようにstarttime>endtimeの場合例外を投げるようにしました。赤が追加部分です。
		// プログラム登録

try {
// $starttime > $endtime の例外処理
if( $starttime > $endtime ) {
throw new Exception("xmlデータで、番組開始時間より終了時間の方が早い番組をスルー");
}

//
$num = DBRecord::countRecords(PROGRAM_TBL, "WHERE program_disc = '".$program_disc."'" );

phpって型変換いらないんだったよね・・・
これで大丈夫かな?エラー出てくれないと確かめようがないですけど・・・

PageTop
EPGrec は番組表や録画予約その他もろもろのデータをMySQLで管理しているらしい。

で、たまに動作確認でターミナルから直接MySQLのデータを見ると日本語部分が文字化けしていてよろしくない。
EPGrec自体はちゃんと動いてるし、へんだなぁ~と思ってスルーしてたが、どうやらターミナルからつなぐときにcharsetがlatinでつながってるらしくてそのせいらしい。

mysql> show variables like "char%";
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.01 sec)

で、/etc/my.cnfをいじれば解消するみたいなのでやってみた。

[client]
default-character-set=utf8


[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

default-character-set = utf8
skip-character-set-client-handshake
character-set-server = utf8
collation-server = utf8_general_ci
init-connect = SET NAMES utf8


[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

赤文字部分を追加

で、再起動すると、
mysql> show variables like "char%";
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.01 sec)

これで、ターミナルから見たときも文字化けずにちょっとしたトラブルシューティングの時にデータベースを見るのに役立つ。
MySQL分かってる人には基礎なんでしょうけど;;

参考:『MySQL 文字化けを防ぐ、文字コードの確認と設定

PageTop
epgdumpのsegfaultを調べてる際に同時に見つけたのでメモ。

recpt1に取り込まれたtssplitter_liteでバッファがオーバ-フローするらしい。

『適当な何かの別館』さんの『recpt1のsegmentation fault』を参照

tssplitter_lite.hの68行目 バッファーのサイズを1MBから32MBに増やすらしい。

2ヶ月くらい前からはほとんどtssplitte_liteを通したminTSばっかりにしてたけど、たまーにdrop起きてるファイルが出来てたのはこのせい?それともsegfaultなら途中で切れたりだろうか・・・・そいえばそんなこともあったかな?

PageTop
前回、EPG取得のための録画の際のチャンネル切り替え時間を追加する変更をEPGrecのgetepg.phpに施したが、今度は、数百MBのTSファイルが出来ているのにエラーが出てる。

で、xmlファイルを見てみると途中で切れてタグが閉じられてない。
こりゃepdgumpが原因かと調べてみると、セグメンテーションフォールトがおこるらしい。
EPGrecの公式のダウンロード のところにもチラッと書いてありますね。

epgdumpはどこかにログ吐いてるのかな?とおもったけど、分からず、だめなときのTSファイルを残してたので、ためしに標準出力してみた。

[root@NAS ~]# epgdump -help
Usage : epgdump {/BS|/CS}
Usage : epgdump

ontvcode Channel identifier (ex. ****.ontvjapan.com)
/BS BS mode
This mode reads the data of all BS TV stations
from one TS data.
/CS CS mode
This mode reads the data of two or more CS TV stations
from one TS data.
[root@NAS ~]# epgdump test '/tmp/__temp.ts.gr13' -
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE tv SYSTEM "xmltv.dtd">

<tv generator-info-name="tsEPG2xml" generator-info-url="http://localhost/">
<channel id="test">
<display-name lang="ja_JP">・ョ・ィ・ォ・繝・Ξ・第擲莠ャ</display-name>
</channel>
Segmentation fault
※文字化けは意味ないです。こぴぺする時エンコード指定して開かなかっただけ
てなことになっているので、解決策はないか調べたけれど、古いものやら亜流やら色々なものが散らばっていて一体どれを使えばいいのやらわからない;;
で、『nyantの日記』さんの『epgdump』というのを見つけて、20111001版のepgdumpには取り込まれて無いようなので、これを試してみた。全く理解もしていないまま・・・・
[root@NAS ~]#  cd /usr/local/src/pt3
[root@NAS pt3]# cd epgdumpr2
[root@NAS epgdumpr2]# make clean
rm -f core epgdump *.o
[root@NAS epgdumpr2]# patch < 20110821patch
patching file ts.c
Hunk #1 succeeded at 310 with fuzz 2 (offset -10 lines).
[root@NAS epgdumpr2]# make
gcc -std=c99 -O2 -Wall -g -c epgdump.c
epgdump.c: In function 'xmlspecialchars':
epgdump.c:244: warning: implicit declaration of function 'strrep'
gcc -std=c99 -O2 -Wall -g -c aribstr.c
aribstr.c: In function 'PutKanjiChar':
aribstr.c:321: warning: passing argument 2 of 'iconv' from incompatible pointer type
/usr/include/iconv.h:43: note: expected 'char ** restrict' but argument is of type 'const char **'
aribstr.c: In function 'LockingShiftGL':
aribstr.c:625: warning: array subscript has type 'char'
aribstr.c: In function 'LockingShiftGR':
aribstr.c:631: warning: array subscript has type 'char'
aribstr.c: In function 'SingleShiftGL':
aribstr.c:637: warning: array subscript has type 'char'
aribstr.c: In function 'DesignationGSET':
aribstr.c:644: warning: array subscript has type 'char'
aribstr.c:645: warning: array subscript has type 'char'
aribstr.c:646: warning: array subscript has type 'char'
aribstr.c:647: warning: array subscript has type 'char'
aribstr.c:648: warning: array subscript has type 'char'
aribstr.c:649: warning: array subscript has type 'char'
aribstr.c:650: warning: array subscript has type 'char'
aribstr.c:651: warning: array subscript has type 'char'
aribstr.c:652: warning: array subscript has type 'char'
aribstr.c:653: warning: array subscript has type 'char'
aribstr.c:654: warning: array subscript has type 'char'
aribstr.c:655: warning: array subscript has type 'char'
aribstr.c:656: warning: array subscript has type 'char'
aribstr.c:657: warning: array subscript has type 'char'
aribstr.c:658: warning: array subscript has type 'char'
aribstr.c: In function 'DesignationDRCS':
aribstr.c:667: warning: array subscript has type 'char'
aribstr.c:668: warning: array subscript has type 'char'
aribstr.c:669: warning: array subscript has type 'char'
aribstr.c:670: warning: array subscript has type 'char'
aribstr.c:671: warning: array subscript has type 'char'
aribstr.c:672: warning: array subscript has type 'char'
aribstr.c:673: warning: array subscript has type 'char'
aribstr.c:674: warning: array subscript has type 'char'
aribstr.c:675: warning: array subscript has type 'char'
aribstr.c:676: warning: array subscript has type 'char'
aribstr.c:677: warning: array subscript has type 'char'
aribstr.c:678: warning: array subscript has type 'char'
aribstr.c:679: warning: array subscript has type 'char'
aribstr.c:680: warning: array subscript has type 'char'
aribstr.c:681: warning: array subscript has type 'char'
aribstr.c:682: warning: array subscript has type 'char'
aribstr.c:683: warning: array subscript has type 'char'
gcc -std=c99 -O2 -Wall -g -c eit.c
gcc -std=c99 -O2 -Wall -g -c ts.c
gcc -std=c99 -O2 -Wall -g -c util.c
gcc -std=c99 -O2 -Wall -g -c sdt.c
gcc -std=c99 -O2 -Wall -g epgdump.o aribstr.o eit.o ts.o util.o sdt.o -o epgdump
[root@NAS epgdumpr2]# cp epgdump /usr/local/bin
cp: overwrite `/usr/local/bin/epgdump'? y
[root@NAS epgdumpr2]#

まぁ、もともと1週間で1~2度こけるかどうか位なので気にしないって戦法もあるけど・・・・これでどうなるか・・・

そして、EPGrecのソースを斜め読みしてるうちに結構穴ぼこだらけ(仕様といえばそれまでか)で、ネットで見てるとEPGrec UNAという派生があることが分かった。
いくつか気になっていた部分に手を入れてるらしいので、今度試してみようかな。
今のままでも普通に使う分にはそれほど問題はないのだけどね。

<<追記>>
これが問題で原因発生?

PageTop
getepg:: 正常な/tmp/__temp.xmlGR20が作成されなかった模様(放送時間帯でないなら問題ありません)

ログを見てると週に数回この警告を見かけます。
昼間でも出てるのと、全チャンネルがいっせいにだめなわけではないのでアンテナとかの問題ではない気がする。
たいした問題ではないけれどちょっと気持ち悪い。
で、ソースを見てみると、epgdumpで作られるべきxmlファイルを読み込めないと出るらしい。

読めないときにEPG取得のために作られるTSファイルのコピーを残すようにstoreProgram.inc.phpの50行目あたりをいじって調べてみると、TSファイルは作られるけど0バイトになっている。
EPG取得の開始と終了のタイミングをログに吐き出してみるとチャンネルの切り替えに2秒くらいしか猶予がないみたい。

ということで、getepg.phpの次のチャンネルへ移る前に録画コマンドの切り替え時間(環境設定)の分だけSleepするように
$cmdline = INSTALL_PATH."/storeProgram.php GR ".$temp_data_gr.$value." ".$key;
$gr_procs[] = epgrec_exec( $cmdline );

の後ろに

// チューナーのチャンネル切り替えの為の待ち時間を追加
sleep((int)$settings->rec_switch_time);

を入れてみました。
BSにも同様に入れました。(CS見ないから多分関係ないけど)

まだ1日しかたってないけど今のところ大丈夫。

<<追記>>
epgdumpにも問題があるみたい

PageTop
TVTestのデコーダを色々と試したけれど、まだ何か違う気がする。
で、ビデオカード(GeForce7300LE)が問題か?ということで、
SAPPHIRE RADEON HD6450 1GB DDR3 PCI-E HDMI/DVI-D/VGA  \2,600(送料込み)
を調達した。

ファンレスで安いものを調べると ATI系は RadeonHD5450、6450、nVidia系は GeForce 210、GT 610とか。
動画再生、デジタル2系統、ファンレス、低消費電力、安価、あたりで選んでみた。
メモリが512MBと1GBがあるみたいだけど、いつ買おうかなぁ~と見てたら、1GBのほうが512MBより安くなったので買ってしまった。

ELSA GLADIAC 573 128MB(GeForce7300LE)は当時(2007年)デュアルDVI+ファンレスで選んだもの。
HD6450との比較。HD6450のアナログVGAは取り付けに邪魔なので外してある。(クリックで拡大)
radeon_HD6450.png

取り付けの図
DSCF2336.jpg

ちなみに、ドライバをAMDサポート&ダウンロードから入れてTVにつないだとき、画面いっぱいのドットバイドットでは表示されず、縮小されて黒の額縁状態で表示される。
Catalyst Control Centerの初期設定で、スケーリングのアンダースキャンがかかってるらしい。
接続相手をTVと認識すると、『表示がオーバースキャンされてしまう』と、勝手に思い込むらしい。
(オーバースキャンするのってブラウン管くらいじゃないの?)
なので、これを解決するには
スタート > Catalyst Control Center > Catalyst Control Center

マイデジタルフラットパネル > スケーリングオプション (デジタルフラットパネル) で スケーリングオプション を0%にすればいい。
ccc_scaling0.png



GeForce7300LE vs RADEON HD6450 比較
Windows Experience Index
7300LEと比較しても今さら意味ないだろうけど・・・

ELSA GLADIAC 573 128MB GeForce7300LE 
(ドライバはWindowsがPnpで入れたもの、nvidiaからダウンロードしたドライバは入らなかった)
sd32g2_7300LE.png

SAPPHIRE RADEON HD6450 1GB DDR3 PCI-E HDMI/DVI-D/VGA
sd32g2_HD6450.png

それぞれでデコーダの違いと、CPU使用率、消費電力を比べてみた。
再生はTVTestでレンダラはEVR。
ソースは1920*1080のFullHD 音声はAACの5.1chのMpeg2TS みっしょんいっぽっしぶるゴーストプロトコルだったかな。
CPU:Core2DuoE6300  GeForce7300LERADEON HD6450
Microsoft DTV-DVD Video Decoder消費電力60w台50w~60w台
CPU使用率20%後半~30%台10%~20%台
ATI MPEG Video Decoder消費電力60w台後半60w台前半
CPU使用率30%~40%台20%後半~30%台
MPC - MPEG-2 Video Decoder消費電力70w台前半60w台後半
CPU使用率40%~50%台30%~40%台

まぁ、Microsoft DTV-DVD Video Decoder が一番CPU使用率が少ないっぽい。=GPU再生支援が一番効いてるってことかな。(処理の省略が一番多いのかもしれないけど)
で、肝心の画質なんですが、カクツキやティアリング、インターレース解除の具合等正直よく分からないけど、若干気になることが減った?か?な?
具体的に比較をするのが難しいので何なんですけど・・・・

で、テレビで2画面にしてテレビの内蔵録画との比較はわりと簡単に出来るのでやってみた。
訂正
画像等削除しました。文字のみ残しました。著作権とか問題あれば連絡ください。すぐ消します。


一番感じるのは 発色。
HTPC(HD6450)の方が、色合いが鮮やか
特に、緑と青 赤も鮮やか。コントラストが高いのかな?

緑がより鮮やかで、高コントランストのせいなのか白い部分が飛んでいる。

HD6450だと白が飛んで、黒は沈む。
パッと見だとHD6450の方がビビッドできれい シャッキリと解像感もある ように感じるかな?
コントラストを上げてアンシャープマスクを掛けた感じ
ただ、肌の色は赤みがだいぶ出るので色温度を上げてあげないと赤ら顔に見える。比べなければ不自然てほどではないが・・・

Woooの方が画像が甘い感じ。隠れたデータ量が豊富な感じ。素材な感じ。自然な感じ。

またさらに、場面によってはアイリス(絞り)が1/2段程違うくらい全体で差が出ることも。
雲の陰になっている部分なんかは顕著で、右HD6450の方が1段くらい明るく感じる。でも道路の色は若干濃い。

ATIは色が鮮やかというのをよく見るので、おそらくビデオカードの影響なんだろう。
CCC(Catalyst Control Center)で色を合わせられるかな、と思ったがちょっと難しそう。


今まで、Woooの8倍で録画したものをあんまり画質よくないなーと思って見ていたけど、あからさまに画質が悪いことにいまさらながら気がついた。ほとんど8倍でしか見てなかったので、放送自体の質かと思っていたが、8倍の影響な気がしてきた。さすがに50インチで8倍圧縮はきついか。

GeForceに戻して比べるのは面倒なのでやらない;;

<<追記2013/01/26>> ひとまずの結論
・レンダラに関して
 madVR インストールして試したがほとんどまともに動かない。
 動いてもほぼGPU使用率100%張り付きで処理落ちも発生する。
 色々見ると、相当マシンパワーが必要らしく常用に耐えるものではないと判断。
 HD6450では歯が立たない。Core2Duoなのもダメか?
 試した中では EVRがインタレ解除等一番まとも。ただ、キャプチャが出来ない。
・当然だが、元ソースがよくないのはいくら頑張っても元ソースがいいものにはかなわない。
・60fpsになっても、元がよくないとヌルヌル感はかなり微妙。
 テレシネで23プルダウンされてるソースもそういうものと妥協するほうが作品に集中できるし精神衛生上いい。(エンドロールのカクカク感は諦める。)
 インタレ解除がうまく行って、ティアリングが出てなければヌルヌル感は気にしないほうがいい。(コマ落ちしてなければ)
 それでも、Woooの内蔵レコーダーで録画したものと比べて、遜色ないどころかいいくらいだし、8倍で撮ったものと比べたら歴然。
 日立の8倍は2mくらいで見るとブロックノイズがいっぱい。
 Wooo(XP05)は8倍で撮らないと320GBしかないのですぐいっぱいになる。

・結局、Microsoft DTV-DVD Video Decoder + EVR か ATI MPEG Video Decoder + EVR あたりで落ち着いている。
・グラボを交換したせいか、最近はそれなりに動きの速い映像を見ても気にならなくなった。
・それでもたま~に瞬停(1秒以下@コマ落ちではない)するので、Lanをギガビットにしてみたいところ。
 ADSLモデムについてるルーターがタコなんではないかと・・
・色味の点で一度GeForceに戻して比べてみたいが、今の色(ATI)で不満なわけじゃないし面倒だからやはりいいか・・・
・たまにキャプチャもしたいノートPC(AMD A6-3400M)はffdshow + VMR9 Renderlessがインタレ解除の点で今の所ベター。
 ティアリングは出るけど小さい画面でまともに鑑賞なんてしないから気にしない。(環境依存かも)
 デインタレースはffdshowのyadifでCPU使用率30%前後

PageTop
# find /searching/directory -type f -print0 | xargs -0 grep "keywords"

空白や特殊文字を含むファイルを正しく処理するため、findコマンドには必ず「-print0」オプションを付け「xargs -0」で受け取るようにしましょう。だそうです。
参考:『find/xargsを使った検索に便利なコマンド一覧

# find /searching/directory -print | xargs grep "keywords" /dev/null

他にもいっぱいあるっぽい。

PageTop
ソースをちゃんと追っかけたわけでもなく、単にコードの途中でログを吐かせて実験しただけなのでかなり不確かですが、連続録画のバグを見つけた気がするのでメモをしておきます。
EPGrec公式の『過去のバージョンの設定』の中段あたりの箇所で連続録画は(Experimental)であると書いてあるので、仕方ないとは思いますが、これはおそらく単純な見落としではないかと・・・(まぁ、だからExperimentalなんですけどね・・・)

で、『kn_ishi』さんが『EpgRecの録画予約アルゴリズム"Reservation.class.php"を改善する。』というページで、改良パッチを公開してますが、こちらも同様の問題がある気がします。

で、どういうバグかというと、連続録画で直前の番組を見つけるところでREC_SWITCH_TIME(Reservation.class.php上では$settings->rec_switch_timeとして呼び出されてる)を考慮することを忘れたのではないかと思います。

おそらく、環境設定をしたユーザー目線だと、
連続した番組の予約 を 行う
録画コマンドの切り替え時間 に 適当な秒数たとえば5秒
にすれば、つながった連続の録画が可能になると思う と思います。

具体的には、(分かりやすく1chで考えると)
1:00~2:00 ・・・番組A
2:00~3:00 ・・・番組B
の番組を連続してとろうとした場合、ユーザー(おそらく開発者も)は番組Aのお尻を5秒(先の例)分削って連続録画してくれるんだろうと期待するわけですが、そうならない場合があります。

EPGrecは、連続録画をする設定だと、前番組(A)のケツを削る際の判定に、
前番組(A)が終わる時間+録画時間を長めにする の時間(実際のAの録画終了時)

後番組(B)が始まる時間+録画開始の余裕時間(秒) の時間(実際のBの録画開始時)
の間に隙間がない(重なっている)場合に前番組(A)を削るようにプログラムしてあると思います。

で、仮に、
録画開始の余裕時間(秒) と 録画時間を長めにする の双方を 0秒に設定していると、先の例の番組A,Bの場合は重ならないので、ケツを削る処理をせずに連続録画が失敗します。
もし、開始の余裕時間を60秒にした場合も、1分間あいだの開いた番組を録画する場合に同様の失敗をすると思われます。
秒単位のラテ欄は見たことがないので、双方もしくはどちらかを秒単位で設定している場合このバグに気づかない(問題は起きない)でしょう。


で、解決策
オリジナルのReservation.class.phpの場合
(2013/1/4現在のgit://git.sourceforge.jp/gitroot/epgrec/epgrec.git)
90行目からを
$battings = DBRecord::countRecords( RESERVE_TBL, "WHERE complete = '0' ".
"AND ".$type_str.
"AND starttime < '".toDatetime($end_time + $settings->rec_switch_time) ."' ".
"AND endtime > '".toDatetime($rec_start - $settings->rec_switch_time)."'"
);
にすれば多分大丈夫だと思います。
ただ、オリジナルの場合、上記の変更と関係なく(録画チャンネル2チャンネルで)、
1:00~2:00 ・・・番組A,C,D
2:00~3:00 ・・・番組B
がある場合、録画開始の余裕時間(秒) と 録画時間を長めにする が 0秒の状況下で、
A→B→Cと録画予約した後に、何故かDが録画予約できてしまうというバグが発生する(原因不明かつ調査してない)ようです。

で、
前述の『EpgRecの録画予約アルゴリズム"Reservation.class.php"を改善する。』の場合、
(2013/1/4現在のgit://git.sourceforge.jp/gitroot/epgrec/epgrec.git) 
87行目からを
			// 既存予約数 = TUNER番号
$tuners = ($crec->type == "GR") ? (int)($settings->gr_tuners) : (int)($settings->bs_tuners);
$type_str = ($crec->type == "GR") ? "type = 'GR' " : "(type = 'BS' OR type = 'CS') ";

// 影響する予約情報を集める
//$rec_start を $rec_start - $settings->rec_switch_time に した
//$end_time を $end_time + $settings->rec_switch_time に した

$trecs = DBRecord::createRecords(RESERVE_TBL, "WHERE complete = '0' ".
"AND ".$type_str.
"AND starttime < '".toDatetime($end_time + $settings->rec_switch_time)."' ".
"AND endtime > '".toDatetime($rec_start - $settings->rec_switch_time)."'" );
// 情報を配列に入れる
for( $i = 0; $i < count($trecs) ; $i++ ) {
$dim_start_time[$i] = toTimestamp($trecs[$i]->starttime);
$dim_end_time[$i] = toTimestamp($trecs[$i]->endtime);
}
// 新規予約の値も配列に追加
$dim_start_time[count($trecs)] = $rec_start;
$dim_end_time[count($trecs)] = $end_time;

// 配列を使って重複を調べ、重複解消を検証する
$battings = 0;
$mi = 0;
for( $i = 0; $i <= count($trecs) ; $i++ ) {
$mem_battings = 0;
for( $j = 0; $j <= count($trecs) ; $j++ ) {
//$dim_start_time[$j] を $dim_start_time[$j] - $settings->rec_switch_time にした
if( ( $i <> $j ) && ( $dim_start_time[$j] - $settings->rec_switch_time < $dim_end_time[$i] ) && ( $dim_end_time[$j] >= $dim_end_time[$i] ) ) {
$mem_battings++; // 重複をカウント
}
}
if( $mem_battings > $tuners ) { // 重複が多すぎるので予約不可
throw new Exception( " 重複予約があります" );
}
// チューナー数が足りないとき、連続予約="する"なら重複解消を試みる
if( ( $mem_battings >= $tuners ) && ( $settings->force_cont_rec == 1 ) ) {
for( $j = 0; $j <= count($trecs) ; $j++ ) {
// 連続予約があるか?
if( ( $i <> $j ) && ( $dim_end_time[$i] > $dim_start_time[$j] - $settings->rec_switch_time )
&& ( $dim_end_time[$i] <= $dim_start_time[$j] + $settings->extra_time + $settings->former_time ) ) {
// 録画が始まっていないか?
if( $dim_start_time[$i] > ( time() + PADDING_TIME + $settings->former_time + $settings->rec_switch_time ) + 1 ) {
$mem[$mi] = $i; // 変更すべき予約IDをメモ
$dim_end_time[$i] = $dim_start_time[$j] - $settings->rec_switch_time; // 先行予約の終了時刻を早める
}
else {
$mem[$mi] = $j; // 変更すべき予約IDをメモ
$dim_start_time[$j] = $dim_end_time[$i] + $settings->rec_switch_time; // 後続予約の開始時刻を遅くする
}
$mi++;
$mem_battings--;
break;
}
}
}
if( $mem_battings >= $tuners ) { // 重複解消できない
for( $j = 0; $j < count($trecs) ; $j++ ) {
if( ( $dim_start_time[$j] < $dim_end_time[$i] ) && ( $dim_end_time[$j] >= $dim_end_time[$i] ) ) {
$msg = $msg."\n 「".$trecs[$j]->title."」";
}
}
throw new Exception( " 予約が重複しています".$msg );
}
if( $battings < $mem_battings ) {
$battings = $mem_battings;
}
}

// ここまでくれば予約可能
for( $i = 0; $i < $mi ; $i++ ) { // 重複解消が必要なら実行する
if( $mem[$i] == count($trecs) ) { // 変更すべきは新規予約
$rec_start = $dim_start_time[$mem[$i]];
$end_time = $dim_end_time[$mem[$i]];
$duration = $end_time - $rec_start; // durationを計算しなおす
}
else { // 変更すべきは既存予約
// 予約修正に必要な情報を取り出す
$prev_id = $trecs[$mem[$i]]->id;
$prev_program_id = $trecs[$mem[$i]]->program_id;
$prev_channel_id = $trecs[$mem[$i]]->channel_id;
$prev_title = $trecs[$mem[$i]]->title;
$prev_description = $trecs[$mem[$i]]->description;
$prev_category_id = $trecs[$mem[$i]]->category_id;
$prev_starttime = $trecs[$mem[$i]]->starttime;
$prev_endtime = $trecs[$mem[$i]]->endtime;
$prev_autorec = $trecs[$mem[$i]]->autorec;
$prev_mode = $trecs[$mem[$i]]->mode;
$prev_dirty = $trecs[$mem[$i]]->dirty;
$prev_start_time = toTimestamp($prev_starttime);
// 開始時刻を再設定
$prev_starttime = toDatetime( $dim_start_time[$mem[$i]] + $settings->former_time );
// 終了時刻を再設定
$prev_endtime = toDatetime( $dim_end_time[$mem[$i]] );
// tryのネスト
try {
self::cancel( $prev_id ); // いったん予約取り消し
self::custom( // 再予約
$prev_starttime, // 開始時間Datetime型
$prev_endtime, // 終了時間Datetime型
$prev_channel_id, // チャンネルID
$prev_title, // タイトル
$prev_description, // 概要
$prev_category_id, // カテゴリID
$prev_program_id, // 番組ID
$prev_autorec, // 自動録画
$prev_mode,
$prev_dirty );
}
catch( Exception $e ) {
throw new Exception( " 予約時刻変更(再予約)に失敗しました\n 「".$prev_title."」" );
}
}
}

// チューナー番号
$tuner = $battings;
にすれば多分大丈夫だと思います。
変更したのは赤い部分のみ。
勝手にコード改変して乗っけちゃってますが、問題あれば連絡ください。

ちなみに、前述したとおり全然ちゃんとソースを読んでないので試す際は自己責任でお願いします。

また双方とも、前後の予約を取り消したときには、それによって削られていた他の番組のお尻部分は復活しないようです。(やるならcancelReservation.phpかな。ファイルを開いてすらないけど・・・・)

ちなみにうちの環境で、
録画コマンドの切り替え時間
2秒だとたまに失敗。
5秒だと今のところ失敗なし。です。

PageTop
録画は最後まで実行されるのだけれど、出来上がったファイルのファイルネームが途中で切れていて動作ログでもエラーが出る。

recomplete:: 予約ID636:BS151世界の名画ベストセレクション ルノワール イレーヌ カーン ダンヴェール嬢の録画に失敗した模様

こんな感じ。出来上がったファイルは拡張子もついてないので真っ白アイコンになってしまう。
すごく稀なんだけれど、何度か経験している。
で、mysqlから

# mysql -u username -p
Enter password:
mysql> use PT3;
mysql> SELECT * FROM Recorder_reserveTbl ORDER by starttime ;


して、予約テーブルを見てみると、ファイルネームになるフィールドの“path”にどうも半角スペースが入っている気がする。

で、ソースを眺めてみると、Reservation.class.phpの240行目付近で
保存するファイルネームに対して、mb_ereg_replaceで『 』『.』『/』『*』『:』『<』『>』『?』『\』『|』『(』『)』『'』『"』『&』(全部半角)をすべて『_』に変換している。

// あると面倒くさそうな文字を全部_に
//$filename = preg_replace("/[ \.\/\*:<>\?\\|()\'\"&]/u","_", trim($filename) );

// preg_replaceがUTF-8に対応できない環境があるようなのでmb_ereg_replaceに戻す
$filename = mb_ereg_replace("[ \./\*:<>\?\\|()\'\"&]","_", trim($filename) );

おそらく、コマンドで引数を渡すときに半角スペースが入っていると、そこで分断されて別の引数として渡されるからだろうし、同様にWindowsなどでファイルネームに使えない文字もすべて回避してるのだろう。
で、本来ならこれで半角スペースもすべてアンダーバーになるのだろうけど、何故かならない場合があるみたい。
調べてみると、
mb_regex_encoding ('UTF-8');
を入れるといいらしい。ので、入れたらうまく行ってるみたいです。

で、最終的にはこんな感じ。
mb_regex_encoding ('UTF-8');
$filename = mb_ereg_replace("[\./\*:<>\?\\|()\'\"&]","_", trim($filename) );
$filename = mb_ereg_replace(" "," ", $filename );
$filename = mb_ereg_replace(" +"," ", $filename );

半角スペースだけ全角スペースにして、連続する全角スペースはひとつに。


自分はファイルネーム規則で録画時間を一番最後(番組タイトルの後)に入れていたので、シリーズものの予約録画の際に、ファイルネームがタイトルの途中で切れてしまって(録画時間も入っていないので)、1話目の録画終了後、2話目が全く同じファイルネームで録画開始されて、1話目に上書きしてしまうという致命的な事態に陥った。
(結局10話完結ものが最後の10話目しか取れていないという・・・)

結構シリアスなバグっぽいのにそのままなのは、単に環境依存の問題で、自分の環境だけなのかもしれません・・


ちなみに、環境は
# php -version
PHP 5.3.3 (cli) (built: Jul 3 2012 16:53:21)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

PageTop
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。