【EDCB】EpgDataCap_Bonについて語るスレ 58
■ このスレッドは過去ログ倉庫に格納されています
>>721
716だけどありがとう、ウチも落ちなくなった… >>795
録画8TB×2(RAID1)
NAS8TB×4(RAID5) あんまり録画しないから4TB一台とバックアップにもう一台で済んでる
アニメ1クールに1本みるかどうか
あとWOWOWでゴジラとかウルトラマンやってるときは録画するかな…今度のドラえもんも >>798
Core2世代のPCでU4/PE4をdrop皆無で使うのは厳しげ 常駐の何かがわるさをしてるのでは
録画に必要な負荷なんてン年前から変わってないし
Atomですら2録画できるのにさ
質問1: 1番組録画でも発生するの?
質問2: EDCBを起動せずCap_bonによる録画開始だとドロップしないの?
質問3: B-CASカード抜いた状態での録画でもドロップするの?
ま、質問3の状態でならドロップ無しで録画できるなら
リアルタイム処理は諦めて録画終了後に解除するようにしたらいいと思う 自動的にリネーム&番組ごとでフォルダ分けしてくれないかな >>807
ん?そういう機能デフォであるの?
フォルダ分けするの面倒なんだが >>798
EpgTimerSrvのプロセス優先度の設定はどうなってる? >>798
ノートならシステムと録画のHDDが同じだろうから厳しい
もしもHDD外付けなのにドロップしまくるなら重い常駐ソフトが住み着いてないか疑え
HDD分けているのなら番組表操作ぐらいでドロップするような環境とは思えない >>804
やはりスペック不足なんでかね
所有してて電気代かからないのがこれだけなんです
>>805
1番組録画だとテストで何番組か録画してEDCE操作しなくてもドロップするものが少しあります
Cap_bon単体とB-CAS抜いての録画はした事ないので確認してみます
>>809
プロセスは普通になっていました
>>810
録画ドライブはウルトラベイに増設していてシステムとは違う所に録画しています
通常はEDCB操作するくらいでドロップはしないんですね >>811
一応J3060でPE4つかってる、凡だの何だのの調整もあるけど、プレクスのUSB接続の奴は
とにかく割り込みとCPU負荷の変動に弱いから、なるべくUSBデバイスは繋がないキーボードもマウスも触らない
EDCBの操作はWebUI入れて別なPCからブラウザ経由でやる、それも録画中に重そうな検索とかは掛けない
ぐらいやると、幾分ましにはなるけどドロップ0はかなり難しい
Linuxでテレビスレ覗いてる限りじゃLinuxの方がましっぽいから頑張れるならLinuxでやってみるのも手かも >>812
USBとCPU負荷なんですね
USBはマウスの無線ドングルとW3U4だけですね
深夜に3番組録画で同じ時間にドロップしてる事もありました
何かしらCPUに大きな負荷がかかってるんでしょうね
Webからの予約ではドロップする事は無いようです
w3u4はWindowsでも情報が少ないのでLinuxだと大変そうですね
ただ安定してくれるなら同じ機種になりますがチャレンジしてみたいとは思っています >>814
低スペックでdropなら「デコード処理なし」での録画を試してみるべき > >>809
> プロセスは普通になっていました
そこを確認したなら、なぜ ” リアルタイム " を試さないのか。 >>798
HDDモデルならSSDにしてみるとか? リアルタイムは気軽に使うものじゃないよ
「通常以上」を使うべし
>>814
web経由だとドロップしないってことは
iGPUのドライバが汎用ドライバになってて一部処理をCPUが受け持つことによる負荷が大きいとか? >>819
シングルコア時代はそうだったけど
マルチコアになってリアルタイム使ってもPC固まることなくなったからなあ >>805
Cap_bonを起動してもタスクバーにしか現れず最大化できないので確認ができなかったですがどうやればいいですか?
B-CASカードを抜いた状態だとドロップしない番組も増えたのですが、ドロップするものもあります
>>815
タスクマネージャーはアプリのGUIで起動?しているEpgTimerSrvが10MBで1番、svchostが2番
次にサービスで起動してるEpgTimerSrvが4MBで3番
次に録画で起動してるCap_bonが4MBで4番くらい
他にsvchostが沢山あります
ちなみに番組表を操作してるとEpgTimerSrvが20MB程になります
>>816
デコード処理無しの設定が見当たらないのですがB-CASカード無しと同じですか? >>817
リアルタイムにするとドロップが今まで以上に増えました
>>818
システムドライブは新しいのではないですがSSDでクリーンインストールした後に本体のドライバとWindowsアップデートとEDCEやTVTestに必要なものしか入れていないです
>>819
iGPUのドライバが汎用ドライバになっていて…というのはx200のディスプレイドライバですか?
遅くなりすいません >>821
CPU負荷なのになんでMBなんだよ、、、 今気づいたんだけど、EpgTimerが取得エラーしてるんだけど俺だけ?
リストが真っ白で、再読込ってやっても
エラーが発生しました、って出てしまう…
取得やるとしばらくして終了しました、が出るけど真っ白のままだ…… (((((((( ;゚Д゚)))))))ガクガクブルブル >>822
本体のドライバってなにさ
lenovo(?)のサポートで型番検索して出てきたドライバ全部インストールして
VC2005〜VC2017まで全部のランタイム入れるのを推奨
それでダメなら挿すUSB端子を変えるぐらいしか思いつかない >>822
すでにEDCB関係ないからU3・U4スレ行った方が良い >>824
自分の環境でも
復号にlibaribb25.dllを使うと番組表が取得できない。
b25decorder.dllだと問題なし >>829
BonCtrl.iniのB25Decoder.dllをlibaribb25.dllへ書き換えた? multi2decのB25Decoder久々にコンパイルしてみた、
VS2017でコンパイルできることはできるんだが、スクランブル解除できない。
VS2017の設定でVS2015相当に落とすと正しく機能するようになった。
BonSDKのビルドはVS2017でOK
これ既出? 自分もlibaribb25.dllをリネームして一か月ほど使ってみたんだが(PT2&tkntrec版)
地デジ1局あたりの取得時間が1〜2分→10分ほどに増加
ファイルサイズも1MB未満→6〜7MB程度に増加
番組表の表示自体はおかしくなかったけど、時間が掛かりすぎるんで戻した
上記は定時予約のEPG取得の場合。
BS/CSでもこの問題は一回確認。そのとき地デジ側は不思議と問題なし。
なんとなく一個目に立ち上がったDpgDataCap_Bon.exeで遅くなっている気がした
DpgDataCap_Bon.exeを単体起動して(勝手に)EPG取得させてると、
上記のようにでかいファイルにはならないのがまたよくわからん
長くなって済みません >>832
え、そうなの?
タイマー起動で寝てる時間にepgを取得してたから気が付かなかった。
帰ったら確認してみる。 >>832
俺環だと思ってた。
当方xtne6f版使用 EpgTimer x64版のEPG取得ボタンを押してEPGを取得した時の時間を調べてみた。
libaribb25.dll・・・20分
B25Decoder.dll・・・6分 取得始めるタイミングでだいぶ変わってくる気がする
5分くらいで終わるときもあれば2,30分かかるときもある >>823
CPU負荷は平均30%くらいで見てる限りの瞬間最大50%くらいです
>>827
入ってないランタイム確認して入れてみます
USBも怪しい端子があるんで再度確認してみます
>>828
そうみたいですね
ちなみにスクランブル解除なしの録画が1番安定しているので当分これで行こうかと思いますが
解除しながら録画したものとあとからmulti2decで解除したものは同じものと考えてよろしいでしょうか?
スペック不足で録画漏れのような事が起こる事はないのでしょか?
よろしくお願いします >>841
電気代云々でX200使ってるとか書いてるけど、他のPC使えるならそれ使ってみなよ
昔X200使ってたけど、スタンバイからの復帰の設定とかいろいろあって、スキルなきゃ
録画用で使いこなすのは難しいよ >>842
それがDropなんですね
>>843
前に録画で使っていたPCが常時起動で1300円/月だったので500円/月の電気代で済むx200でなんとかならないかと思ってます Tvtestでカウントされてるものを見ると
録画漏れ≠ドロップ
電波が弱いか何かでパケットがおかしくて正しく記録できないものがドロップ扱い
全然データを吐き出してこないとドロップにならない 割と基本的なことをわかってない人が増えてきたのかな
tsパケットにはPIDごとに連続性を確認するためのカウンターがあってそれが連続してない時(要するに途中のパケットが抜け落ちてる時に)dropになる
0 1 2 3 4 5 6 7 8 ってちゃんと続いてたらdrop=0
0 1 2 4 5 6 7 8 って番号が飛んでたらdrop=1
0 1 2 5 6 7 8 みたいな番号が飛び方をしてる時はアプリによってカウントの仕方が変わるけど、EDCBの場合はdrop=2とカウントしてる
0 1 2 5 7 8 こういう時はEDCBではdrop=3になる
ただしこのカウンターは0〜15までしか番号がないから16パケット一度に抜けた場合はdrop=0になる可能性もあるし17パケット以上一度に飛んだ場合は正しくカウントされない ぶっちゃけdropが出てもtvtestで視聴する限りそれほど問題にはならんよ。
録画したTSをエンコとかする人は、dropの地点から音が急に途切れるみたいな問題に遭遇することはあるがw libaribb25.dllではチャンネルサーチで検出されない局がいくつかあるのと
EPG取得に時間がかかるようになった。
VS2017でB25Decoder.dllをビルドして使っているが
最適化が素の設定だとEpgDataCap_Bonが固まるので変えて使ってる。 >>831
BoneBaseLibをリコンパイルと、BonCoreEngineをLIB化すればVS2017でコンパイルできる。
ただBoneBaseLibはMulti2Decのソースがないとビルド出来ないかな。
平成の龍馬騒動でソース元は逃げるし、まるもさんまでpatch入れてきたからバージョンは失念。
もしビルドできなかったら斧に上げてもいいけど、当時chaosで(IPPまでプロジェクトに入っているw)本心上げたくないから何とかビルドして。 ごめん、もしかするとBonCoreEngineはLIB化しなくともいけたかもしれない、BonCoreEngine.dllが欲しくないからプロジェクトかえたかもしれない。
たしかMulti2Dec_Ver.2.10.zipだったかな和族で手に入る。 EMM も対策したい場合は、OnCatTable() でも同様に CA_system_id を確認してあげてください。沢山の法則から、CA descriptor の選択処理を別メソッドに切り出す。
TRMP 対策 (手抜き版) >>849
和族にあったMulti2Dec Ver.2.10をVS2017でビルドしてB25Decoder.dll(x64)を作成したけど動かない。
入手したソースを全て展開してビルド環境にコピーする。
BonProject(BonProject.sln)をビルドして作成されたBonBaseLib.lib(x64)とBonCoreEngine.lib(x64)をMulti2Dec\BonSDK\Lib\ReleaseにコピーしてMulti2Dec(Multi2Dec.sln)をビルドするとB25Decoder.dll(x64)
が作成される。
B25Decoder.dll(x64)をEDCB動作環境にコピーしてEpgDataCap_Bon.exeを実行すると「EpgDataCap_Bonは動作を停止しました」
ダイアログが出る。
使用したWindows SDKのバージョンは10.0.16299.0
何がいけないのだろう?
EDCB動作環境はWindows 10 64bit それってtvtestのcasproやtvcasでは2017で大丈夫なのか? 俺はtvtestもedcbも全てvs2017でビルドしている。
libaribb25.dllもvs2017でビルドしていたけど、例のケンが発覚したため、
B25Decoder.dllをビルドしようとしてトラブってる。 BonBaseLibとB25DecoderのC/C++/最適化 Ox → O2 で動いてるっぽい O1にしてOi無効で動くけど、本来は元からなんとかせんと駄目かもしれんね。 最適化オプションで動作が変わるってのは闇の深いケースが多いんだよな
クリティカルセクションが漏れてるとかそういう系の >>855-858
ありがとう。
帰宅したら確認する。 >>859
コンパイル時にでるワーニングを対処する必要があるね >>852
831だけど
BonProjectは2017で問題なかった(BonSDKにBonBaseLib.lib と BonCoreEngine.libが作成される)、
B25Decoder.dllのコンパイルにはこのBonSDKのincludeにインクルードパスを設定し、
二つのライブラリをリソースに追加してからビルドするわけだが、
ここでVS2017だとコンパイルできるものの動作しなかった。とにかく、追跡できないほどWarningが出るんで、やっぱダメかって感じ。
でも、VS2015に切り替えれば正常なB25Decoder.dllができあがった。
B1Decoder.dllも同じ感じでコンパイルできるので、ついでにwinscard-B1.dllが読み込まれるように改変した.
逆にwinscard-B25.dllにしてB25Decode.dllの方いじればよかったことに気がついたwwww `>>853
大丈夫
こっちは、新しいコンパイラでメンテが進んでるんで何も問題ない。
しかし、x64のコードって古いSSExオプションはシカトされるようになってるのね。知らんかったわ。
浦島太郎、Q9550使ってるんでwwww 最適化オプションもあるけどC++の規格の方のバージョンも小刻みに上がってきて、
2017がバグはらんでる可能性あるからな。C++1xの対応がどーなってるかっていう。
もう、こっちも、1xなんてキャッチアップできてないし。 >>855
もっかいコンパイルやり直してみた。
BonProject も B25Decoderも 2017 コンパイラ、SDK は10 16299
主な最適化
最適化は速度最大の/O2
インライン展開 /Ob2
組み込み関数 /Oi
実行速度優先/Ot
主なコード生成
並列コード /Qpar
拡張命令セット 設定なし(古いCPUなんで)
で正常動作したわ。2017でNGで2015 でいけたのは最適化にサイズシュリンクの伴う/Oxを設定したたのが関係してたみたい。
今時サイズ小さく最適化することもないし、/O2でいいわ。2017はサイズシュリンクの最適化バグ入りかも。 すまん何度も
訂正
2017で動いてるように見えたけど、ゆっくりスクランブルエラー増えていくわ。
まるで、信号減衰してるときのBERのようなエラーの出方で、たち悪いなコレ
んで、最適化も
インライン展開→既定
に換えてみた。インライン展開の過度な展開はどうもバギーな気がする。
やっぱりBonProjectはこのオプションで2017で、
B25Decorderは2015のコンパイルがいいみたい。
BonProjectのサブプロジェクトはインライン展開フルでもいけるのもあるみたいだけど、
とても全部試せないので、インライン展開は"既定"固定にした。 俺が持ってる、むか〜しダウンロードしたMulti2Dec2.1.0のソースはWin32でしかビルドできないんだけど、どこかに、x64対応のソース落ちてませんかねえ
B25Decorder.dll(x64)のバイナリは持ってて、EDCBで問題なく動作してるんで、必須ではないんだけど >>868
Multi2Decは、32と64で違いなんかないよ。
ビルドできないってのは、何をしようとして、どーだめだったの? >>867
https://msdn.microsoft.com/ja-jp/library/8f8h5cxt.aspx
/O1 (or /Od)
or
(/Ox or /O2) + コマンドライン/追加のオプション /Oi-
でおkかと >>869
ありがとうございます
構成マネージャーでプラットフォームを追加すればいいんですね
そんなことも知らない初心者なもんで…
>>870
https://github.com/logue/BonProject
BonProject をここからダウンロードして、
x64 でビルドして出来上がった BonSDKフォルダーをMulti2Dec のソースの同フォルダーに上書きして、
VS2017、x64 でエラー、警告なくビルドできました
できあがった B25Decorder.dll の動作は未確認です >>871
OKってのは2017でOKってこと?
んー、2017のビルドの影響出るのはB25Decoderだけなんだけど、
実動作のエラータイプが2種類あって、
スクランブルが全くデコードされずエラーカウントされっぱなしの場合と、ほぼデコードされるが、時折エラーになる場合。
んで、2015を使うと、まっとうなバイナリに仕上がるので、2017はなにがしかのバグを持ってると推測。
BonProjectは2017でも問題ないので、B25Decoderのコンパイルだけは2017を使わないのがベターだと思ってる。
ちなみに2015でビルドしたB25Decoderから、2017でビルドしたwinscard呼ぶのも問題なかった。
TVTest, EDCBがらみ、B1とB25系全部コンパイルやりなおしてみたけど、全部2017でビルドできて、
こんなのB25Decoderだけだったわ。 B25Decoderのソースざっと見てみたけど、最適化の余地なんてほとんどないような、
極めて短い関数群(ほかの関数コールして戻り値だけ返してすぐリターンってのが多い)、
これで、オプション設定でころころ動作が変わること自体、コンパイラ側に不信感を持たざるを得ない。
でも、reinterpret_cast が気になるんだけど・・・ 2月9日にVS2017で64bit版をビルドしたやつが残ってたけど、その時は何も特別な事せずにビルドしてそのまま使えたけど、
最近アップデートしたVS2017でやってみたら、オプションを上のように変更しないとエラー落ちするようになってた まぢか。
俺も先週ぐらいに、インスコし直したんだわ。
2015だと動いてる、前の`2017でも動いてて、
latest版は動作不良なら、バグ濃厚 じゃあバグレポ送るしか
2017なってからフットワーク軽くて頻繁にアプデートが降ってくるようになったし あー、コンパイラの不具合濃厚なんか。
変なところでアクセス違反とかおきてたからロジック理解兼ねて整理とか書き直してたら起きなくなったりしてたから妙だとは思ってた。
(不安だったので将来見越してLibISDB使って1から書き直しとかもしてた) 面倒な人は当分VS2015使っておけばいいってことだな
というかVS2010でもコンパイル出来るから、入れ替えてない人はそのままだな >>866
852だけど、俺のところは/O2と/Oiのオプションで動かなかった。
結局、この組み合わせで動いたのでテスト中。
主な最適化
・最適化は速度最大の/O1
・インライン展開 /Ob2
・組み込み関数 いいえ
・実行速度優先/Ot
主なコード生成
・並列コード /Qpar
・拡張命令セット 設定なし(古いCPUなんで)
BonProjectは、オプションを何も変更しないでビルド。
BonProject配下に作成されたBonSDKをMulti2Dec配下のと置き換え。
B25Decoder.dllだけオプションを上記の内容に変更してビルド。 なんかVS2017の不具合ってことにされてるけど
あんなにワーニング出るんだから
そもそもコードが古すぎるんだと思うよ
古いコードには古いIDEってか >>883
ウォーニングはエラーじゃないしな。
C++言語標準オプションようやく見つけた。
どこにあるのかわからんかった。ちょっ試してみるわ 並列コード /Qparの有効かなんて無効でいいのでは
そんな重い処理じゃないし 言語仕様オプションはVS2017モードでしか選択できないな
ちなみにB25Decoderは、
C++14ではビルド可能、動作しない
C++17ではビルド不可
C++stdでもビルド不可
つまり、VS2017で何のオプションもつけないとC++14相当なんかな。
VS2015モードは結局言語仕様がいつのものかはっきりしないな。
こんなオプションgccはずっと前からあったぞ コンパイラ不具合説には懐疑的だったんだけど
例外発生箇所のBonProject/TsPacket.cpp:31行目でCOD吐かせて眺めてみたら考え変わった
>mov edi, 4
>mov al, BYTE PTR [edi]
コンパイラが正常なら、31行目をどう解釈してもアドレス0x00000004を参照はがしする機械語になるわけがない あー俺が年末ごろから悩んでるのが話題になってる
VS2017でも去年の4/30にビルドしたのは正常動作してるよ
そん時のマイナーバージョンはわからない
それと、並列コード生成はpragma入れてやらないと何もしないんじゃないか? いまんとこB25decoderだけが問題表面化してるだけで他のも問題内包してるかもしれないのかな >>888
年末ごるからなら違うだろ
2月9日のVS2017では問題ないという報告がある とりあえずVS2017のバージョンをはっきりさせないとだめだな >>890
よくわからないが2月9日にアップデートしていないとも読み取れるな
2月じゃなければ昨年末以前からの問題とも考えられるな
結論としてはバージョンをはっきりさせないとだめだなで一致 B25Decoderを最新のコンパイラでビルドしたいのは何となく分かるけど
実際にどんな効果がどれほどあるの?
VS2017に昔のMFCとか入れるのはなんとなく嫌なだけなんだけどw 自分の場合は効果よりビルドできる環境を整備しておきたいってのが主目的だわ ttps://www.axfc.net/u/3894393 >>893
まったくない
あえて言うならわざわざ古いVSを入れたくない的な理由な人のほうが多い気がする 2月9日のフォルダに残ってたログには、MSVC\14.12.25827
3月9日にアップデートしてビルドしたログには、MSVC\14.13.26128
となってました
詳しくないので、これがVS2017のバージョンとして分かるものかわかりませんが・・・ 2月9日のはVS2017 ver15.5だろうな細かなバージョンはわからないが
3月9日のはVS2017 ver15.6.1なのだろうかそれとも時差の関係で15.6なのだろうか
よくわからないが
VS2017
version 15.6
March 8, 2018 -- Visual Studio 2017 version 15.6.1
March 5, 2018 -- Visual Studio 2017 version 15.6
version 15.5
January 29, 2018 -- Visual Studio 2017 version 15.5.6
January 25, 2018 -- Visual Studio 2017 version 15.5.5
January 16, 2018 -- Visual Studio 2017 version 15.5.4
January 9, 2018 -- Visual Studio 2017 version 15.5.3
December 14, 2017 -- Visual Studio 2017 version 15.5.2
December 7, 2017 -- Visual Studio 2017 version 15.5.1
December 4, 2017 -- Visual Studio 2017 version 15.5 - ■ このスレッドは過去ログ倉庫に格納されています