番組表と予約一覧にて予約表示をチューナー毎に色分けするように改修した。
ただし番組表からの予約時に既存予約のチューナーが動的に再振り分けされるのを表示に反映していない。当面は、ブラウザーのリロードでしのぐつもりだがコードで対応しないとダメかな・・・
放送波のEPGは、1番組にジャンルが複数指定されている場合があるので頭から3つまで取り込めるようにepgdumpとepgrecを改修した。
また予約一覧と番組検索で表示番組の日時の番組表へジャンプできるようにした。
今後の予定としては、予約個別での隣接禁止指定や自動キーワード予約に開始終了時刻のシフト追加を考えている。
2011年1月29日土曜日
2011年1月26日水曜日
スポーツ延長についてのメモ
昨日のサッカーが延長したので4分毎に1分間録画の予約を入れてモニターしてみた。
・放送波のEPG更新が試合終了後1時間ぐらいされなかった
・放送中番組と次番組の情報を参照しないとダメなようだ
・上記の理由からrecpt1などの録画コマンドかepgdumpの改造が必要
・放送波のEPG更新が試合終了後1時間ぐらいされなかった
・放送中番組と次番組の情報を参照しないとダメなようだ
・上記の理由からrecpt1などの録画コマンドかepgdumpの改造が必要
2011年1月22日土曜日
epgdump ジャンル出力不具合パッチ
epgdumpが出力したxmlファイルを眺めていると「その他」ジャンルのサブジャンルに未定義な値が出力されていた。
そこで epgdumpのソースを見てみるとサブジャンル対応でいじったときに「大丈夫かいな」と思っていたところがやはりバグだった。
epgrecのサブジャンル対応時に特定のジャンルがDBに登録されていないのを不審に思っていたんだよな
パッチは以下に
そこで epgdumpのソースを見てみるとサブジャンル対応でいじったときに「大丈夫かいな」と思っていたところがやはりバグだった。
epgrecのサブジャンル対応時に特定のジャンルがDBに登録されていないのを不審に思っていたんだよな
パッチは以下に
--- ./org/eit.c 2009-11-18 12:23:01.000000000 +0900
+++ eit.c 2011-01-22 15:45:11.388454332 +0900
@@ -531,7 +531,7 @@
if((eith.original_network_id == original_network_id) && (eith.transport_stream_id == transport_stream_id)){
cur = searcheit(eittop, eith.service_id, eitb.event_id);
if(cur != NULL){
- cur->content_type = (unsigned char)(contentDesc.content[0] >> 4);
+ cur->content_type = *((unsigned char *)contentDesc.content) >> 4;
#if 0
fprintf(stdout, "%s:", cur->title);
fprintf(stdout, ",%02x%02x", (unsigned char)contentDesc.content[0], (unsigned char)contentDesc.content[1]);
2011年1月21日金曜日
EPG更新の所要時間短縮 その2
地上波しか受信していないため地上波3チューナー(PT2+FSUSB2)でデバッグを行った。
使用CPUは、atom D525 録画鯖としてはごく平均的な底辺CPU
3受信だけなら何ら問題は無いのだがそれに加えてDB更新を3スレッド並列させるとCPU負荷が80~90%とかなり高くなった。衛星波を入れてPT2の4チューナーでやったら受信がヤバそう。
底辺CPUで運用するにはDB更新の並行数を絞らないと支障をきたす場合がありそうだ。
…といった感じで改善点が見つかったのだが面倒臭くなったのでなげ(ryしばらく保留w
他にこの1週間で録画直前の単チャンネルEPG更新とサブジャンル対応を実装した。
あとは自動キーワードの優先度追加だが上が絡むのでこれも保留 個人的に必要になる可能性がかなり低いのもある。
予約漏れは、どうするって? チューナーを足せばいいさw 少なくともUSBが空いてるでしょ
使用CPUは、atom D525 録画鯖としてはごく平均的な底辺CPU
3受信だけなら何ら問題は無いのだがそれに加えてDB更新を3スレッド並列させるとCPU負荷が80~90%とかなり高くなった。衛星波を入れてPT2の4チューナーでやったら受信がヤバそう。
底辺CPUで運用するにはDB更新の並行数を絞らないと支障をきたす場合がありそうだ。
…といった感じで改善点が見つかったのだが
他にこの1週間で録画直前の単チャンネルEPG更新とサブジャンル対応を実装した。
あとは自動キーワードの優先度追加だが上が絡むのでこれも保留 個人的に必要になる可能性がかなり低いのもある。
予約漏れは、どうするって? チューナーを足せばいいさw 少なくともUSBが空いてるでしょ
2011年1月15日土曜日
EPG更新の所要時間短縮
EPG更新の所要時間のほとんどは、EPG受信時間がしめている。
短縮するには、いかに総EPG受信時間を減らすかにかかっているわけだ。
PT2の様に地上波・衛星波と2種類のチューナーがあるならそれらを平行して受信すれば半分に、またそれぞれが多チューナーなら全チューナーを総動員すれば更に短縮できる。
例にあげたPT2なら20分を5分ぐらいに短縮できるだろう。
現行のepgrecは、地上波と衛星波を合せて1チューナーしか受信に使用していない。
処理を並列化しているのはDB更新だけだ。
低スペックPCを考慮してなんだろうなぁ デーモンのプライオリティー下げてるぐらいだし
でも受信に関しては低スペックPCでも同時4受信とか平気でこなせるので何とかなんじゃねぇ?
と思ったので取り敢えずコードを書いてみた。まだデバッグはしてない。
いや正確に言うと録画直前の単チャンネルEPG更新のコードを書いた勢いとそれに含まれるチューナーの排他処理が絡むのでが正解だ。
このコードには事前に分かっている不具合がある。テンポラリーを大量消費するのだ。
1分あたり130Mバイトとして、PT2なら地デジ2本にBSとCSはそれぞれ2分で最大780Mバイトを必要とする。
HDDをテンポラリーにしてるなら問題無いがSSDなら寿命を縮める事になるしRAMディスクでは容量不足に成る環境があるだろう。
この問題については、録画コマンドがEPGデータだけを吐き出してくれれば解決してくれるのだが難しいかな・・・
これが片付いたら次は、自動キーワードの優先度追加かサブジャンル対応(epgdumpは改修済み)に手をつけよう。
短縮するには、いかに総EPG受信時間を減らすかにかかっているわけだ。
PT2の様に地上波・衛星波と2種類のチューナーがあるならそれらを平行して受信すれば半分に、またそれぞれが多チューナーなら全チューナーを総動員すれば更に短縮できる。
例にあげたPT2なら20分を5分ぐらいに短縮できるだろう。
現行のepgrecは、地上波と衛星波を合せて1チューナーしか受信に使用していない。
処理を並列化しているのはDB更新だけだ。
低スペックPCを考慮してなんだろうなぁ デーモンのプライオリティー下げてるぐらいだし
でも受信に関しては低スペックPCでも同時4受信とか平気でこなせるので何とかなんじゃねぇ?
と思ったので取り敢えずコードを書いてみた。まだデバッグはしてない。
いや正確に言うと録画直前の単チャンネルEPG更新のコードを書いた勢いとそれに含まれるチューナーの排他処理が絡むのでが正解だ。
このコードには事前に分かっている不具合がある。テンポラリーを大量消費するのだ。
1分あたり130Mバイトとして、PT2なら地デジ2本にBSとCSはそれぞれ2分で最大780Mバイトを必要とする。
HDDをテンポラリーにしてるなら問題無いがSSDなら寿命を縮める事になるしRAMディスクでは容量不足に成る環境があるだろう。
この問題については、録画コマンドがEPGデータだけを吐き出してくれれば解決してくれるのだが難しいかな・・・
これが片付いたら次は、自動キーワードの優先度追加かサブジャンル対応(epgdumpは改修済み)に手をつけよう。
2011年1月9日日曜日
epgrec EPG更新(時間追従)不具合パッチ(場当たり版)
(11.02.15 タイトルを「epgrec番組追跡(時間追従)不具合パッチ(場当たり版)」 から現行に変更)
まあ役に立たない事ばかりを書いているだけなのも何なので当たり障りのない部分のパッチを上げておこう。
このパッチでは、 枠移動かタイトルの更新なのか判定できないが実用上問題ない。
完全対策をするには、$program_discのMD5算出時にEIDを加えればいい。この場合、今回のパッチを適用する必要はないがepgdumpの改修とEPGのDBをdropする必要がある。
パッチ当ては、手動でヨロ
storeProgram.inc.php ----------------------------------------------------------------------------
まあ役に立たない事ばかりを書いているだけなのも何なので当たり障りのない部分のパッチを上げておこう。
このパッチでは、 枠移動かタイトルの更新なのか判定できないが実用上問題ない。
完全対策をするには、$program_discのMD5算出時にEIDを加えればいい。この場合、今回のパッチを適用する必要はないがepgdumpの改修とEPGのDBをdropする必要がある。
パッチ当ては、手動でヨロ
storeProgram.inc.php ----------------------------------------------------------------------------
else {
// 番組内容更新
$rec = new DBRecord( PROGRAM_TBL, "program_disc", $program_disc );
//枠移動チェック
if( $rec->title != $title ){
try {
$reserve = new DBRecord( RESERVE_TBL, "program_id", $rec->id );
//自動キーワード予約判定
if( $reserve->autorec && toTimestamp($reserve->starttime)-PADDING_TIME > time() )
Reservation::cancel( $reserve->id );
else
if( $reserve->dirty == 0 && toTimestamp($reserve->starttime)-$settings->former_time > time() ){
// dirtyが立っておらず現在より後の録画予約であるなら
$reserve->title = $title;
$reserve->description = $desc;
reclog( "getepg:: 予約ID".$reserve->id."のEPG情報が更新された" );
}
}
catch( Exception $e ) {
// 無視する
}
$rec->title = $title;
}
$rec->description = $desc;
$rec->category_id = $cat_rec->id;
}
}
catch(Exception $e) {
reclog( "getepg:: プログラムテーブルに問題が生じた模様", EPGREC_ERROR );
reclog( "getepg:: ".$e->getMessage()."" , EPGREC_ERROR);
exit( $e->getMessage() );
}
}
// Programme取得完了
}
?>
2011年1月8日土曜日
epgrecの改造のあれこれ
EIDに関しては、epgdumpの改修は一行加えるだけなので速攻で完了した。
epgrec側は、DB改変も考慮に入れないといけないため放置を含めて思案中
どうせやるならEPGだけでなく予約にも反映して録画延伸にも対応させたい所だがrecpt1などの録画コマンドにまで手を出すことに・・・本家でも懸案止まりの案件に手を出すのはメンド
自動録画キーワードに優先度付加は、優先度処理のロジック面は楽勝なのだがEPG更新並列処理デーモンから自動録画キーワード処理を外す必要がある。いや外さなくても何とかなると思うが予約とキャンセルを繰り返すだろう。
あとEPG更新の並列処理だがEPG受信も並列化しないと恩恵が少ないような・・・
この辺も改修に含めるとデーモンの終了待ちとチューナー管理が必要になるため二の足を踏んでいる。
この件については、単純に優先度処理を入れれば良いだけで考え過ぎなのかもしれない。
他にも録画直前のEPG更新や番組表の予約をチューナー毎に色を変えたいとかサブジャンルを入れたいとかやりたい事は、いくつかあるが実装方法を想定中だったり知識不足やらで進んでいない。能力不足は棚にあげておく。
epgrec側は、DB改変も考慮に入れないといけないため放置を含めて思案中
どうせやるならEPGだけでなく予約にも反映して録画延伸にも対応させたい所だがrecpt1などの録画コマンドにまで手を出すことに・・・本家でも懸案止まりの案件に手を出すのは
自動録画キーワードに優先度付加は、優先度処理のロジック面は楽勝なのだがEPG更新並列処理デーモンから自動録画キーワード処理を外す必要がある。いや外さなくても何とかなると思うが予約とキャンセルを繰り返すだろう。
あとEPG更新の並列処理だがEPG受信も並列化しないと恩恵が少ないような・・・
この辺も改修に含めるとデーモンの終了待ちとチューナー管理が必要になるため二の足を踏んでいる。
この件については、単純に優先度処理を入れれば良いだけで考え過ぎなのかもしれない。
他にも録画直前のEPG更新や番組表の予約をチューナー毎に色を変えたいとかサブジャンルを入れたいとかやりたい事は、いくつかあるが実装方法を想定中だったり知識不足やらで進んでいない。能力不足は棚にあげておく。
2011年1月4日火曜日
epgrecの不具合
かれこれ4ヶ月ほど使用しているのだがいくつか不具合が見受けられる。
まずひとつは、公認不具合の重複予約
現行ではSQLで判断しているがPHPでロジックを組まなければ解決は、不可能だろう。
なお重複チェックだけなら他で言われているようなDBの追加は必要ない。
重複による予約漏れ番組を制御したい場合には自動録画キーワードに優先度を付加すればよいが苦労したくなければEPG更新の並列処理も改修する必要があるだろう。
次に番組編成変更にともなう番組追跡
既存予約にピッタリ重なる形で別番組が移動してくると既存予約がキャンセルされずに残り、目的の番組の移動先が追加で予約される。
この不具合は、問題箇所にタイトル名での番組移動判定を追加すれば現行のコードに少し手を加えるだけで何とかなるが番組表DBと予約の更新処理をイベントID(EID)で判定するように改修すれば確実かつスッキリするだろう。
その場合は、EIDを取得する為にepgdumpの改修も必要になる。
最後に異種チューナーの混在
公式には対応を謳っているがepgrecは、内部で厳密なチューナー管理をしていない。
現行ではEPG更新で不具合が発生するが録画そのものに影響が有るかは検証していない。
だが先に挙げた重複予約チェックを改修すると録画でも顕在化するだろう。
現行のままでも録画に不具合が発生する事を確認した。
この問題点を改修するにはロジックでの対応だけでなくDBの拡張が必要になる。
これらの不具合については、自動録画キーワードの優先度追加とEPGのEID対応を除いて改修したがPHP素人なC使いなので(Javascriptもド素人w) 番組表の表示系で不具合が発生している。
ここに挙げた以外の改修も行っているが環境依存や仕様変更している部分も多いため今のところパッチ公開は差し控えている。 中の人の動向も気になるし・・・
さてどうしようかな・・・
ちなみに当方の環境は
ubuntu 10.04 32bit
epgrec 3/22版
PT2 * 1 KVT-FSUSB2 * 1
PT2は録画優先 FSUSB2はEPG優先にしてある。
まずひとつは、公認不具合の重複予約
現行ではSQLで判断しているがPHPでロジックを組まなければ解決は、不可能だろう。
なお重複チェックだけなら他で言われているようなDBの追加は必要ない。
重複による予約漏れ番組を制御したい場合には自動録画キーワードに優先度を付加すればよいが苦労したくなければEPG更新の並列処理も改修する必要があるだろう。
次に番組編成変更にともなう番組追跡
既存予約にピッタリ重なる形で別番組が移動してくると既存予約がキャンセルされずに残り、目的の番組の移動先が追加で予約される。
この不具合は、問題箇所にタイトル名での番組移動判定を追加すれば現行のコードに少し手を加えるだけで何とかなるが番組表DBと予約の更新処理をイベントID(EID)で判定するように改修すれば確実かつスッキリするだろう。
その場合は、EIDを取得する為にepgdumpの改修も必要になる。
最後に異種チューナーの混在
公式には対応を謳っているがepgrecは、内部で厳密なチューナー管理をしていない。
現行ではEPG更新で不具合が発生するが
だが先に挙げた重複予約チェックを改修すると録画でも顕在化するだろう。
現行のままでも録画に不具合が発生する事を確認した。
この問題点を改修するにはロジックでの対応だけでなくDBの拡張が必要になる。
これらの不具合については、自動録画キーワードの優先度追加とEPGのEID対応を除いて改修したがPHP素人なC使いなので(Javascriptもド素人w) 番組表の表示系で不具合が発生している。
ここに挙げた以外の改修も行っているが環境依存や仕様変更している部分も多いため今のところパッチ公開は差し控えている。 中の人の動向も気になるし・・・
さてどうしようかな・・・
ちなみに当方の環境は
ubuntu 10.04 32bit
epgrec 3/22版
PT2 * 1 KVT-FSUSB2 * 1
PT2は録画優先 FSUSB2はEPG優先にしてある。
登録:
投稿 (Atom)