BonDriver共有ツール総合 その2

1 ：名無しさん＠編集中：2015/04/07(火) 20:25:07.03 ID:n6IDd8Gi.net

BonDriver共有ツール総合

※前スレ
http://peace.2ch.net/test/read.cgi/avi/1366339738/

258 ：名無しさん＠編集中：2015/09/11(金) 10:08:15.92 ID:pyQsqCFg.net

ビルドは無関係でした

障害が発生しているアプリケーション名: BonDriverProxyEx.exe、バージョン: 1.1.6.1、タイム スタンプ: 0x55f22516
例外コード: 0xc0000005
障害オフセット: 0x00012744
障害が発生しているプロセス ID: 0xe3c

259 ：名無しさん＠編集中：2015/09/11(金) 12:59:44.62 ID:UVBZn+Y7.net

>>256
10分くらい似たような感じでチャンネル変え続けたけど起きない
なんかもう少し、手順が絞れれば・・・

260 ：名無しさん＠編集中：2015/09/11(金) 15:02:36.81 ID:8d+klU/R.net

Splitter経由でUHFからBSのチャンネルに切り替えたらBonproxyEXが落ちた
環境の問題かも知れないが

261 ：名無しさん＠編集中：2015/09/11(金) 19:15:04.07 ID:Ktq8gNoc.net

>>260
>>256と同じ人だと思うけど、せめて使用環境と設定内容を書くくらいはしなよ
俺のとこでは起きないし、他に報告が無いと言う事は多分他の人にも起きてないんだろうから、
なんか設定が間違ってる可能性が高いんじゃないかと思うけど、なんも書かれてないから
原因の推測すらできない

262 ：名無しさん＠編集中：2015/09/11(金) 21:00:04.54 ID:8phWfh86.net

馬鹿には無理

263 ：名無しさん＠編集中：2015/09/12(土) 04:12:07.18 ID:1hlEtHdd.net

開発者はエスパーじゃないからねえ。

私も、○○したら落ちたとか、起動しないとか言われることあるけど
チューナー切替のような誰でもする当たり前の動作で
ただ単に落ちたとだけ言われても、何も特定できないよどうしろっていうんだよって思うよ

264 ：名無しさん＠編集中：2015/09/12(土) 07:59:47.99 ID:FreM+lvw.net

環境は鯖がwin8.1でクライアントはwin7、win10など４台です。
チャンネル切り替え時にBonProxyEXが落ちるのですが発生条件が特定できないので、鯖のBonproxyEXとService splitterを６月のバージョンに戻して様子見中。
以前はなかった現象なので。

265 ：名無しさん＠編集中：2015/09/12(土) 08:02:44.68 ID:AXuWCNzY.net

バカにはやっぱ何言っても無駄だった

266 ：名無しさん＠編集中：2015/09/12(土) 08:04:09.07 ID:FreM+lvw.net

朝まで待ち構えて勝利宣言のレスをつけてるかと思うと笑えるわ

267 ：名無しさん＠編集中：2015/09/12(土) 08:04:30.94 ID:1hlEtHdd.net

>>264
その落ちたときの接続状況とかを完璧に書いてみたらありがたいんじゃないですかね。
各クライアントの設定と一緒に。

268 ：名無しさん＠編集中：2015/09/12(土) 08:05:33.31 ID:AXuWCNzY.net

自意識過剰でわらた

269 ：名無しさん＠編集中：2015/09/12(土) 08:06:20.80 ID:FreM+lvw.net

もう真面目に報告する気が無くなったｗ
馬鹿にはつきあえんわ

270 ：名無しさん＠編集中：2015/09/12(土) 08:08:15.86 ID:AXuWCNzY.net

バカって言われたのが相当悔しいらしいｗ

271 ：名無しさん＠編集中：2015/09/12(土) 08:23:35.00 ID:1hlEtHdd.net

結局、どういう環境なのかよくわからなかったね。
・チューナは何か(PT3なのかPT2なのか、そのほかなのか)
・チューナーは何枚あるのか
・BonDriverは何を使用しているのか
報告内容からすると、この辺の把握が最低限必要だと思うんだけども

272 ：名無しさん＠編集中：2015/09/12(土) 14:58:06.86 ID:54xOvvXZ.net

大雑把に書いてもわかる文章はあるけど考え先行すぎて意味が読み解けない
文章ってあるよね。おちついてきちんとまとめてから報告しよう。

273 ：名無しさん＠編集中：2015/09/12(土) 16:41:33.53 ID:jRNX7Trl.net

221,226（構成記述)の者ですが、うちでもおちますよー。

Win10になってSpinelから乗り換えて、226のレス書くまでロック権限の改造が入る前の
srcをビルドして使って約1か月程使って、一部おかしかった以外（後述）は落ちることはありませんでした。

9月6に変更が入ったソースをVS2015でビルド後
EDCB側のBonDriver_ProxyT.ini,BonDriver_ProxyS.iniにCHANNEL_LOCK=255,
TVTest側のBonDriver_ProxyT.ini,BonDriver_ProxyS.iniにCHANNEL_LOCK=0を入れて運用しています。
チャンネルを変えるとたまにTVTestが固まって、サービスを見てみるとBondriverExが停止しています。
その時はサービスを起動しなおしています。

最近作者さんが、こまめに変更を入れているようなので、変更が落ち着くまではと、
そのまま使っています。
再現性が１００％ではなくたま〜になので、どうすれば落ちると答えようがないのですが・・。
ロック権限の改造後、時々落ちるのは間違いないです。

以前一部おかしかった件ですがロック権限の改造前の時、録画予定のものと違う
チャンネルの番組が録画されていたのでチャンネル設定が間違っているのかと
EpgDataCap_Bon.exeのUDP-Viewを使ってサービスを切り替えていって試してみたところ
そのチャンネルに問題ありませんでした。

続けて全チャンネルの確認をしていくとチャンネルが切り替わらないところが
あり、ch2の設定を確認しましたが問題なく、EpgDataCap_Bon.exeを立ち上げなおして
やってみると今度はうまくチャンネルが切り替わり、更に何度か続けていると
切り替わらないことが発生しました。

Win１０後、BonDriver_Spliter〜EDCBまで新しいビルドの物を使っているので
どこのexe,dll,iniがおかしいのか特定できないのと、こちらも再現性が
１００％ではなくたま〜になので、前レスで書きませんでしたが一応ご報告を。

続きへ

274 ：名無しさん＠編集中：2015/09/12(土) 16:42:14.04 ID:jRNX7Trl.net

続き
作者さんへですが、

BonDriverProxyEx.cpp の1819行の情報ウィンドウでipアドレス表示の所

#ifdef _WIN64
inet_ntop(AF_INET, &(p4->sin_addr), addr, sizeof(addr));
#else
lstrcpyA(addr, inet_ntoa(p4->sin_addr));
#endif

のinet_ntoa ですがVS2015ではwarnning ではなく
error扱いになっているため32bitなおかつサービスでないコンパイルの場合ひっかかります。
コンパイラが inet_ntop()に変更するかdefine _WINSOCK_DEPRECATED_NO_WARNINGS　
でもいいよと言ってきます。

inet_ntoaが同じアドレスに文字列を作ってしまうのを
lstrcpyAで文字列をコピーして対応しておられるうようですが、
inet_ntoaが使用禁止の方向になってきてるようなので前述のように
errorになってしまいます。

ひょっとしてXPの場合inet_ntoaが必要なのかもしれませんが、
64bit側と同じ処理でもいいのではと思い、うちでは
inet_ntop(AF_INET, &(p4->sin_addr), addr, sizeof(addr));
だけ残して後は消してコンパイルしてます。

できればこの辺りご再考をよろしくお願いします。

275 ：名無しさん＠編集中：2015/09/12(土) 17:02:56.84 ID:t1lAERej.net

273で書き忘れました。

後述の以前一部おかしかった件ですが、ロック権限の改造後は
この現象は見ていません。

276 ：名無しさん＠編集中：2015/09/12(土) 20:08:13.07 ID:dFPYR6xi.net

>>255
本家developブランチの最新ソースに対するパッチなので、本家には組み込まれてないですよ

CSの場合だけTSストリームから視聴中のサービスIDが消えた時に映像/音声を止めるのは、
フジテレビnextは契約してるけどフジテレビoneは契約していないような場合にPAT先頭サービスを選んだら、
未契約の映像/音声を再生しようとする事になるので、恐らくそうならないように想定しての仕様なのかなと思います

もっとも、現在のTVTest本体はCAS機能を持っておらず、その辺りは気にする必要は無くなってる筈なので、
リクエストしたら取り込まれる可能性もあるかもしれませんね

277 ：名無しさん＠編集中：2015/09/12(土) 20:10:38.32 ID:dFPYR6xi.net

>>260
えーと皆さん仰ってるように、使用しているBonDriverの種類やBonDriverProxyEx.exeのiniの内容辺りを
教えていただけるでしょうか？
ただ、最近の変更でチューナの共有部分に関する大きな変更は行っていない筈なので、何が原因やら(;´Д`)
確かに設定かなとも思うのですが、設定の問題だと言うには以前のでは起こらなかったという点が謎ではありますね…

278 ：名無しさん＠編集中：2015/09/12(土) 20:25:08.93 ID:dFPYR6xi.net

>>273-275
報告ありがとうございます
>>277にも書いた通りの感じなので、少しやっかいかもしれません(;´Д`)
手元で再現できないのがツライ…

もし可能であればデバッグビルドしてサービスでない方でデバッグ実行してみて、落ちた場所を
調べていただけるのが一番なのですが、とりあえず当方の配布バイナリで実行してみて、
落ちた時の「障害オフセット」を教えてもらえるとそれだけでも助かります
＃自己ビルドではなく当方からの配布バイナリでないと、こちらに当該バイナリが無いので
＃「障害オフセット」は参考にできません…

inet_ntoa()の件は、XPにはinet_ntop()が無いので、コンパイルはできても実行できなくなるんです(;´Д`)
当方の配布バイナリはVS2015でビルドしているのですが、ツールセットはv140_xpにしてます
＃これならエラーにはなりません
v140でビルドすると確かにエラーになりますね
その場合は既に試されてるように、64bit側と同じ方を使うようにすれば大丈夫ですよ

279 ：名無しさん＠編集中：2015/09/12(土) 20:36:58.24 ID:KWvmWs16.net

BonDriverProxyの作者さんはトリップ付けてもらえませんか？
後で過去ログ参照する時とか一目で判別できるので
よろしくお願いします

280 ：名無しさん＠編集中：2015/09/12(土) 21:57:13.19 ID:t1lAERej.net

273-275 です。

すみません、GitHubのソースの場所ならわかるのですが配布バイナリはどこでしょうか？

281 ：名無しさん＠編集中：2015/09/12(土) 22:15:22.15 ID:i385/JP8.net

>>280
>>3に書いてあるよ

282 ：名無しさん＠編集中：2015/09/13(日) 00:32:41.43 ID:RyBKPFF7.net

273-275 です。

落ちた時のエラー　ログ2種類取れたので載せておきます。

障害が発生しているアプリケーション名: BonDriverProxyEx.exe、バージョン: 1.1.6.1、タイム スタンプ: 0x55ef5d8a
障害が発生しているモジュール名: ntdll.dll、バージョン: 10.0.10240.16430、タイム スタンプ: 0x55c599e1
例外コード: 0xc0000005
障害オフセット: 0x0003ee01
障害が発生しているプロセス ID: 0xcf4
障害が発生しているアプリケーションの開始時刻: 0x01d0ed6c32a86fa1
障害が発生しているアプリケーション パス: C:\PX-W3U3\BonDriverProxyEx\BonDriverProxyEx.exe
障害が発生しているモジュール パス: C:\Windows\SYSTEM32\ntdll.dll
レポート ID: 42758187-d1cf-4990-98fa-3afe29a0e5f0



障害が発生しているアプリケーション名: BonDriverProxyEx.exe、バージョン: 1.1.6.1、タイム スタンプ: 0x55ef5d8a
障害が発生しているモジュール名: BonDriver_PX_W3U3_S0.dll、バージョン: 0.0.0.0、タイム スタンプ: 0x4d8b6111
例外コード: 0xc0000005
障害オフセット: 0x00012c94
障害が発生しているプロセス ID: 0x184c
障害が発生しているアプリケーションの開始時刻: 0x01d0ed6dd73031fb
障害が発生しているアプリケーション パス: C:\PX-W3U3\BonDriverProxyEx\BonDriverProxyEx.exe
障害が発生しているモジュール パス: C:\PX-W3U3\BonDriverProxyEx\BonDriver_PX_W3U3_S0.dll
レポート ID: 8aeddf15-b3ff-42d2-ae04-17f442e20860

283 ： ◆SALrG1ld3mTc ：2015/09/13(日) 11:53:41.34 ID:/ZxTJa6Q.net

>>279
どうせ大した事は書いてないのですが、検索用ですか…ﾅﾙﾎﾄﾞ
と言う訳で入れてみました
＃当方イイカゲンなのでそのうちトリップキー忘れそうですが(;´Д`)

284 ： ◆SALrG1ld3mTc ：2015/09/13(日) 11:55:38.07 ID:/ZxTJa6Q.net

>>282
ntdll.dllとBonDriver_PX_W3U3_S0.dllですか
特にBonDriver_PX_W3U3_S0.dllはGetTsStream()の中で死んでますね
これらを見る限りどうもメモリ破壊っぽいのですが…

もしかしたらBonDriver_PX_W3U3_S0.dll内部での排他ロックがちゃんと行われていなくて、
PurgeTsStream()とGetTsStream()を非同期で呼ぶとメモリ破壊が起きるのかも、と思ったので、
それらとついでにSetChannel()の呼び出しをBonDriver_Splitter側で排他にしてみました
＃もしこれで直るようならBonDriver_PX_W3U3内部での排他処理が甘いと言う事でしょう…

また、それとは直接は関係ないのですが、SetChannel()前のサーバ側でのTS破棄は実質ほぼ不要なので、
他のクライアントとインスタンスが共有されていない場合のみ行うようにしました
特にEx版では、自分よりロックの優先度が低い他のクライアントに対して、影響なしに
チャンネル変更できる場合でもTSを破棄してしまう状態が発生するのを無くせたはずです

とりあえずこれで様子見てもらえるでしょうかヽ(;´ー`)ノ

285 ：名無しさん＠編集中：2015/09/13(日) 12:12:42.18 ID:/0SFmSyX.net

結構流通してると思われるのにPLEX系のボンドラはソースも公開されてないしダメダメですな

286 ：名無しさん＠編集中：2015/09/14(月) 22:32:49.33 ID:tIlzQPGU.net

273-275 です。

SALrG1ld3mTcさん、変更ご苦労様でーす！

現状落ちる気配まったくありません。夕べと今日、
かなりガチャガチャとチャンネルを変えてみたのですが平気なようです。

が・・・・

EDCBで違うチャンネルが録画される病が再発してしまいましたｗ。

落ちないのを確認終了後、普通に予約録画を入れ録画しているときに、
録画の様子を少し見ようとEpgDataCap_Bonの「View」を見たところ予約指定の番組とは
違うチャンネルの番組になっていました。
この時録画をキャンセルし、EpgDataCap_Bon.exeを1度終了し、
EpgDataCap_Bon.exeをもう1度起動し「View」を見てみる先ほどの番組と同じ物でした。
これはEpgDataCap_Bon.exeの「サービス」のチャンネルとは異なるチャンネルの番組です。

この状態でEpgDataCap_Bon.exeの「サービス」のチャンネルを1度変更すると
指定の正常な番組に切り替わりました。

更にチャンネルを先ほどおかしかったチャンネルに戻すと指定通りの正常な番組が表示されました。
その後何度かチャンネルを変えたり、EpgDataCap_Bon.exeを起動しなおしてみましたが、
正常に動作し異常な状態を再現できませんでした。

この異常はBonDriver〜EDCBのどこで起きているのかまだ把握できていないのと、
意図的な再現方法がわからないのと、
最近TVtest回りいろいろいじっていっているので、我が家の固有の異常である可能性もあるので、
このまま使用を続け、この異常の件何かわかったらまた報告いれます。

287 ：名無しさん＠編集中：2015/09/14(月) 23:08:16.25 ID:4n9Y6JJu.net

>189
TVTestでは、OpenTuner/CloseTunerを別スレッドで行うこともあり、CoInitialize/CoUnInitialize
をBonDriverで行わない方が良いというのは理解できました。
ところがそれだと、EDCBではCoInitializeを行っていないので、BonDriverでCOMライブラリを使うことが出来ません。
そこで例えば、OpenTunerの段階でCOMライブラリを使う必要があるBonDriverを作成する際には、
OpenTuner()の最初で

HRESULT hr;
hr = ::CoInitializeEx(NULL, COINIT_MULTITHREADED);
if (hr == S_OK)
m_bCoInit = TRUE; //m_bCoInitはGlobal変数
else if (hr == S_FALSE)
::CoUninitialize();
else if (hr != RPC_E_CHANGED_MODE)
return hr;

とした後、CloseTuner()で

if (m_bCoInit)
::CoUninitialize();

あたりが、妥当な実装かと思うのですが、いかがでしょうか。
ご助言を頂けましたら幸いです。

288 ：名無しさん＠編集中：2015/09/15(火) 01:07:52.82 ID:PR/PgOiy.net

うちのBonDriver_PXがHDUSのsrcを改造したらしいけど、
HDUSのプログラムがOpenTunerでCoUninitialize呼んで
CloseTunerでCoUnInitialize呼んで、
>>287みたいになってますねぇ。

HDUSのソースにうちのチューナー名、キャプチャー名入れて、
少々変更して動かしてみると、フィルターグラフの構築は
BonDriver_PXと同じにできてるのに、フィルターグラフに
runかからない〜♪

BonDriver_BDA改のソースも同じようにうちのチューナー名、キャプチャー
捕まえるようにしてみたけどフィルターグラフに
runかからない〜♪

graphstudionextでMicrosoft DVBT Network Provider〜レンダラまで
繋がるやつで繋いでみたけど
runさえかからない〜♪

ネットワークプロバイダ登録直後のチューニング要求に何か設定いるのかなぁ。

ここで行き詰ってるぅぅ。

誰か動かし方わかる人いたら、この初心者に優しくおしえて！

289 ：名無しさん＠編集中：2015/09/15(火) 04:18:00.88 ID:b63Dshpf.net

うっざ

290 ： ◆SALrG1ld3mTc ：2015/09/15(火) 06:26:33.57 ID:Vobrm9Ay.net

>>286
ひとまず落ちないようにはなったとの事で良かったです
実は>>284の下の方で書いた変更の為、BDPEXも今の物に入れ替えると、当方が落ちる原因になっているのではないかと
推測している状況に殆ど遭遇しないようになっているはずなので、もし可能であればBDPEXは前のバージョンに戻して、
BonDriver_Splitterのみを今の物で試してみてもらえないでしょうか？
それでも落ちないようになっていて初めて、>>284の推測は当たりだったのかなと思えるのでヽ(;´ー`)ノ

別チャンネルになってしまう件は、ちと謎ですね(;´Д`)
その辺の変更は今回何も行っていないはずなのですが…
何だか、チャンネルロックされているチューナに対してチャンネル変更を試みた場合の挙動のようにも思えます
この場合アプリにはチャンネル変更成功に見えるようにしているので、もしそうなった場合、EDCBは録画対象
チャンネルに変更成功したつもりで、別チャンネルを録画してしまうと言うのが起こりそうではあります
例えば、EDCBの設定に対して実チューナ数が不足していたりするとそうなるかもしれませんね

ともあれ、BDPEXとBonDriver_Splitterをデバッグビルドしてみて、Dbgview辺りでログを眺めてみると
何かヒントがあるかもしれません…

291 ： ◆SALrG1ld3mTc ：2015/09/15(火) 06:41:48.30 ID:Vobrm9Ay.net

>>287
> あたりが、妥当な実装かと思うのですが、いかがでしょうか。

COMの初期化/終了処理はスレッド単位で行う必要があるものなので、単一のグローバル変数でフラグを持つのは
あんまり良くないのではないかとヽ(;´ー`)ノ
例えば、
ttp://www1.axfc.net/uploader/so/3513652
等は、恐らくその点を考慮してスレッドIDを確認するようにしているのだと推測しますが、いずれにせよ、
OpenTuner()/CloseTuner()が別スレッドで行われる場合の解決にはなっていませんね

また、OpenTuner()/CloseTuner()だけでなく、SetChannel()やGetSignalLevel()等の他のAPIも、
OpenTuner()と呼び出し元スレッドが同一だとは限りません
＃事実、例えばTVTestでは異なっています

その様な感じなので、個人的にはEDCB側にCOMの初期化/終了処理を追加する方が正解なんじゃないかな、と思います
やはりスレッドの最初と最後でやるのが確実なので、スレッドをつくった人が行うのがベストではないでしょうか…

292 ： ◆SALrG1ld3mTc ：2015/09/15(火) 07:06:22.10 ID:Vobrm9Ay.net

>>288
PLEXのチューナは何やら初期化処理がいるようなので、それをやってないからじゃないでしょうか？
linuxのドライバを使用するには、
https://github.com/u-n-k-n-o-w-n/BonDriverProxy_Linux/blob/a4dd4dc535eed979d1752b0ad3a30e2636ba878c/plex.cpp
な感じの処理が必要(らしい)ですが、これとほぼ同じ処理がBonDriver_PX_W3PE_S0.dllの中にも、
OpenTuner()でフィルタグラフをつくってる辺りにあるようですね

293 ：名無しさん＠編集中：2015/09/15(火) 14:02:47.23 ID:1p/tEp51.net

クライアントIP、使用チューナーなども含めて、
チャンネル変更や変更失敗のログとか取れるとわかりやすそうですねえ

294 ：名無しさん＠編集中：2015/09/15(火) 16:35:44.95 ID:1p/tEp51.net

>>292
たぶん分かってる気もするんですが報告

優先度255のクライアントA
優先度255のクライアントB
優先度100のクライアントC

クライアントAをBS朝日にします。
クライアントBをBS朝日にします。
クライアントCをBS日テレにします。

たとえば上記の状態で
(ケース1)
クライアントBを「BS11」に変更すると、
クライアントBとCが「BS11」になります。これはOKです。

上記操作はなかったことにして、
(ケース2)
クライアントAをBSフジに変えたとします。
そうすると、クライアントBもBSフジになってしまい、
クライアントCはBS日テレのままになります。

本来、AとBは排他権限で、優先度もCより上なので、
クライアントAはBS朝日→BSフジに
クライアントBは変わらずBS朝日のままに
クライアントCはAに奪われ、BS日テレ→BSフジに
なるのが良いと思うのですが、どうでしょう。

お忙しい中、面倒だとは思いますがよろしくお願いいたします・・・。

295 ： ◆SALrG1ld3mTc ：2015/09/15(火) 23:38:13.64 ID:Vobrm9Ay.net

>>293-294
> なるのが良いと思うのですが、どうでしょう。

ありがとうございます、確かにその挙動の方が良いですね
もともと優先権有りと無しの二択のみで、かつ有りのクライアントがチャンネル変更出来ない状態と言うのは
考えなくてよかったところから、ご指摘のような挙動になってましたヽ(;´ー`)ノ
対応してみたので確認してみて下さい

ログに関しては以前もリクエストいただいたのですが、あんまり優先度は高くないかなーと思って
後回しにしてしまっております(;´Д`)

296 ：名無しさん＠編集中：2015/09/16(水) 01:15:59.10 ID:NtH+9SSP.net

>>292

初期化処理の件ありがとうございます。

確かにBonDriverProxy_Linux/plex.cppの40ByteLookupTable1と1024ByteのLookupTable2が
BonDriver_PX内に連続して埋まってるのを確認できました。W3PE用のInterface_W3PE.dllの方にも同じデータテーブルが確認できました。

ただ、BonDriver_PXとInterface_W3PE.dllに２つのデータテーブルの前に1024Byteの似たようなデータが埋まっているのですよ..（汗）。
正直plex.cppの内容については全く理解する知識がないので、ほぼこのままHDUS用ドライバの方に利用させて頂きました。
::open(g_Device, O_RDONLY)を Windows用に::CreateFileに変更し、地上波ドライバのパスを"\\\\.\\usb#vid_0b06&pid_0005#6&26c27801&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed"と固定値で入れ
::ioctlを::DeviceIoControlに変更したらビルドは出来ました。

COMがドライバを開き、こちらでも同じ物を開けるのかと疑問があり、更に処理の意味を理解しないままですが、とりあえず思いつくままチューニング空間作成の直前に入れて動かしてみることにしました。
ドライバのオープンで戻り値はtrue、0x8d81コマンドで戻り値が0xcccccccc、0x8d82コマンドで戻り値は0xccの連続データとなり、0x8d, 0x83とデータの書き込み後フィルタグラフのrunには至りませんでした。

BonDriver_PXをツールを使って見た時、インポート関数にはCreateFile,DeviceIoControlが見当たらないのでおそらく直接ドライバを叩かずにDirctShowの仕組みでチューナー設定を行っていると推測しているのですが、
その処理の方法について情報が全く掴めないため、今後この直接ドライバを叩く方法で初期化処理を探ってみます。

スレ違いな件でしたが、情報大変ありがとうございました。

297 ：名無しさん＠編集中：2015/09/16(水) 03:12:19.96 ID:kPve2Fte.net

意味不明の自家発電書き込みにﾜﾛﾀw

298 ：名無しさん＠編集中：2015/09/16(水) 07:23:50.90 ID:sYR8CujZ.net

>>295
確認してみました。
意図した動作になっていると思います。

ありがとうございました。

299 ：名無しさん＠編集中：2015/09/16(水) 07:30:55.97 ID:d1QHFDlx.net

>>296
大変参考になります。
何か進展があれば是非おしえてください。他のPlex製品にも応用できると思いますので。

300 ：名無しさん＠編集中：2015/09/16(水) 07:55:18.64 ID:d1QHFDlx.net

>>291
詳細な説明ありがとうございます。
当面はスレッドIDをする暫定的な対応しかないですね。

ところで、リンクのソースだとS_FALSEの時の処理が抜けてますね…

301 ：名無しさん＠編集中：2015/09/16(水) 09:19:05.96 ID:BfRuKofg.net

>>300
そのソースをうｐした者です。
S_FALSEだったらすでにCoInitializeされてるはずであり、2重にCoInitializeは行われていないということなのでそのままにしておくという考えです。
ですから、S_FALSEだった時にはCoUnInitializeも行わないようになっています。
スレッドIDを記憶している理由は、CloseTunerがOpenTunerと別スレッドで呼ばれた場合に
自分以外が行ったCoInitializeを間違ってCoUnInitializeしてしまわないようにしているだけです。
どちらにせよCoUnInitializeする術がないので。

私は、BonDriver側の責任でCoInitializeを行うべきだと思っています。
BonDriverでCOMを使用するかどうかはBonDriver側の都合なので。
今考えているところで一番良いやり方は、BonDriver側でAppとは独立した別スレッドを作成し、
そのスレッドでCoInitialize/CoUnInitializeを含めたすべてのCOM処理を行うのが最善ではないかなと思っています。
近いうちにリンク先にあったBonDriverでそれをやってみたいと思います。

302 ：300：2015/09/16(水) 16:35:23.46 ID:d1QHFDlx.net

>>301
そう思いがちなのですが違うのです。
https://msdn.microsoft.com/ja-jp/library/windows/desktop/ms695279(v=vs.85).aspx

each successful call to CoInitialize or CoInitializeEx, including any call that returns S_FALSE, must be balanced by a corresponding call to CoUninitialize.

実は、S_FALSEのSはsuccessもしくはsucceedのSで、S_FALSEでもCoInitializeされてしまうのです。従って、CoUnInitializeが必要になります。

なので、実装として正しいのはS_FALSEの場合はすぐに CoUnInitializeしてやることだと思ってます。

もちろん呼び出しによらず別スレッドで完結できればそれに越したことはないと思います。

303 ：300：2015/09/16(水) 18:08:43.78 ID:JWzbiEwR.net

>301
可能でしたらCoInitializeExのスレッドモデル教えて頂きたいことがあります。
殆どのBonDriverと同様COINIT_APARTMENTTHREADEDを指定しているようですが、
COINIT_MULTITHREADEDにしない何か理由等ありますでしょうか。

というのも、BonDriver自体は当然ウインドウに絡む処理はありませんし、
TVTestの様に仮に呼び出し元のアプリケーションでウインドウに絡む処理があって、
かつ、同一のスレッドでCOMを使う場合でもアプリケーション側で初期化を行うはずなので
COINIT_MULTITHREADEDで新たに初期化しようとしてもRPC_E_CHANGED_MODEが
返ってくるだけです。

EDCBのようにBonDriver絡みでそもそもCOMを使わない場合はそれこそスレッドモデルは
なんでもいいはず。

さらに、アプリケーション側で、BonDriver側のメモリにアクセスすのはGetTsStream、PurgeTsStreamで、
これらの処理は当然CriticalSectionにしているはずなので、スレッドセーフといえる。

というわけでCOINIT_MULTITHREADEDで問題ないと思っています。
何か見当違いをしているかもしれませんが、その際はご指摘いただけたらありがたいです。

304 ：名無しさん＠編集中：2015/09/16(水) 18:11:52.70 ID:JWzbiEwR.net

もっともCOINIT_MULTITHREADEDにしたい理由は
「若干のパフォーマンスアップがある、かも」くらいなので、
予期せぬ破綻が起きないために、とりあえずCOINIT_APARTMENTTHREADEDにする、
というのもアリだと思います。

305 ： ◆SALrG1ld3mTc ：2015/09/16(水) 20:06:22.11 ID:53Si47U2.net

>>296
BonDriver_PX_W3PE_S0.dllがBonDriver_HDUSの改造でつくられていると言うのは多分その通りで、
ttp://www2.wazoku.net/2sen/hdusup/source/up0233.zip
のソースで言うと、DShowMain.cppの748行目に相当する部分で例の初期化処理を呼んでるようですね

C++なので仮想関数呼び出しになってて、ioctl()に相当するコードが具体的にどうなっているのか
テキトーにバイナリを眺めてるだけでは特定がめんどくさいのですが、PX-W3PEの実機を持ってる方なら
BonDriver_PX_W3PE_S0.dllをロード -> CreateBonDriver() -> OpenTuner()とやって、OpenTuner()の
内部をデバッガで追って行けば、結構簡単に特定できるんじゃないかなと思います

dllのロードアドレス+1040c辺りからが問題の処理なので、ここにブレークポイント置いて
動かしてみるのが手っ取り早いかと…

306 ： ◆SALrG1ld3mTc ：2015/09/16(水) 20:11:58.58 ID:53Si47U2.net

>>301
> S_FALSE

>>302さんの書かれてる通りですが、MSのAPIにはたまーにこの手の罠がありますね…

> 私は、BonDriver側の責任でCoInitializeを行うべきだと思っています。
> BonDriverでCOMを使用するかどうかはBonDriver側の都合なので。

まあ行うにせよ行わないにせよ、ライブラリの使用方法に制限をかける形になるのは同じで、
単にライブラリが、
---
a. 使用するには呼び出し側での初期化が必要ですが、それを守る限りは自由なAPI呼び出しが可能です
b. 対になるAPIを異なるスレッドから呼び出す事はサポートしませんが、特に前準備無しでも使用可能です
---
のどちらの立場をとるのかと言う話なので、ライブラリ作者の好みの問題ではありますね
＃個人的にはa.の方が好きですがヽ(;´ー`)ノ

ただ、そのライブラリのドキュメントやソースが無い場合には、a.のパターンでは最初から動かず、b.のパターンでは
アプリのつくりによって動いたり動かなかったり、と言う感じになるので、どちらがマシかと言う話になります
この場合は、ライブラリユーザ(アプリ作者)としてはa.の形であった方が助かるんじゃないかなーと思ってます…

307 ： ◆SALrG1ld3mTc ：2015/09/16(水) 20:15:17.65 ID:53Si47U2.net

> 今考えているところで一番良いやり方は、BonDriver側でAppとは独立した別スレッドを作成し、
> そのスレッドでCoInitialize/CoUnInitializeを含めたすべてのCOM処理を行うのが最善ではないかなと思っています。

ですね、非常に有効だと思いますヽ(´ー`)ノ
若干トリッキーではありますが、外部に公開しているAPIの内COMが絡むものは、呼び出されたらイベントをトリガして
実際の処理はそれを受けたワーカースレッドでやり、処理が終わればそれをイベントのトリガ元に通知すると言う形に
すれば、ライブラリ内でCOMの初期化/終了処理を完結できるので、APIの呼び出し方に制限はかからずアプリ側での
初期化/終了処理も不要にできますね
＃ちなみに、今のBonDriver_Proxyも(COMを使う目的ではありませんが)似たような実装になっています

308 ：名無しさん＠編集中：2015/09/17(木) 01:38:04.41 ID:UxTbU+TO.net

>>303-304
COINIT_MULTITHREADEDにするって事はCOM呼びだしのスレッド同期処理は全部自前でやるって事だけど
>>301で書いてるみたいに自前でスレッド起こして無い以上、どっちみちスレッド同期処理とか不可能だよね。

GetTsStream()やPurgeTsStream()がCriticalSectionでガードされてた所で
COMを呼び出すスレッドが同一スレッドである保証なんてどこにもないよ。
ガードされてても別スレッドからの呼出なら、どこかでCoInitialize()しなきゃいけない。

どっちみち>>301の方法以外では別スレッドからの呼びだしなんて解消出来ない。

COMのスレッド周りに関する話は
ttp://www.kekyo.net/2012/06/16/80
ttp://www.kekyo.net/2013/07/22/382
この辺が参考になるよ
COMのアパートメント(1)〜(6)は全部読んだ方がいい。

309 ：301：2015/09/17(木) 10:01:23.53 ID:HpsXGkNf.net

>>302
うわ、完全に勘違いしてました。
確かにそう書いてありますね。
S_FALSEの場合はすぐに CoUnInitializeしてやるのが正解なんですね。
ちなみにRPC_E_CHANGED_MODEが返ってきた場合はどう対処するのが正解なんでしょうか？
（例のソースではこれが返ってきたときのことは想定していません）

COINIT_MULTITHREADEDについては、難しすぎてよく理解できてないんですが、
>>308のとおりBonDriverという立場では使用できないと思ってます。

310 ：名無しさん＠編集中：2015/09/18(金) 00:33:12.57 ID:9PcEUns2.net

>>305 ioctl()に相当するコードについての解析記録です。

BonDriver_PX_W3U3_T0.dllの中を解析していくために、BonDriverExの直下にBonDriver_PX_W3U3_T0.dllを組み込む設定にし、BonDriverExを起動。WinDBGをアタッチ。TVTestを起動した。
BonDriverExのm_pIBon->OpenTuner()で一時停止。そこからトントントンと数ステップでdllの中にin。そこからステップ実行で進んでみるがシンボルがある所以外は、何の処理なのか、
今どこにいるのかもわからない。そもそもこれを追っていける解析能力が自分にはない。そこで自分にも出来る別のアプローチをとることにした。

まずはDeviceIoControlがシステム上のどこにあるのか突き止めるため、デバイスドライバをオープンして閉じるだけの短いプログラムを作成。
追って行くとKERNELBASE.dll+オフセットAA680に DeviceIoControlが見つかる。
2ステップ程進んだ　call KERNELBASE!GetAdjustObjectAttributesForPrivateNamespaceRoutine+0x18でスタック上に値を入れて戻ってきた。
更に2ステップ程進んだところで、C++上のDeviceIoControl(）で64bit設定したマイナーファンクションコードが16bitになってcxレジスタ上に0x8d81が入っていた。これがデバイスドライバに送られる模様。
この時点での呼び出し順は　プロセス→kernel32.dllのDeviceIoControl→KERNELBASE.dllのDeviceIoControlであった。

次にBonDriver_PX_W3U3_T0.dllからどうDeviceIoControlが呼ばれるのか調べる為にKERNELBASE.dll.DeviceIoControlに網を張ることにする。
WinDBGに　bp KERNELBASE!DeviceIoControl+0xF "j cx==0x8d81'';'g'"　とcxレジスタが0x8d81の時停止するように入れてみた。
んー停止せずTVTestが映ってしまった。　ということは�@DeviceIoControlが利用されており引数のマイナーファンクションコードがLinuxのドライバと違う、
�A別プロセスからドライバに読書されたか、�BWindows上の他のシステム関数から読書されたことになりそうだ。

311 ：名無しさん＠編集中：2015/09/18(金) 00:34:44.21 ID:9PcEUns2.net

310　続き

DeviceIoControl以外にデバイスドライバの読書をする関数を知らないので、�BのWindows上の他のシステム関数からだと厄介だ...。

�@のDeviceIoControlの引数が違う点については、別の側面から疑っている。それは
>>296にも書いたが、pestudio.exeというツールでBonDriver_PX_W3U3_T0.dllを見た時にImported symbolsの中にDeviceIoControlが見当たらない。
kumaさんドライバにも同様にDeviceIoControlが見当たらない。対して上記のデバイスドライバをオープンして閉じるだけの短いプログラムにはkernel32.dllのDeviceIoControlを利用していることが表示される。
ということで、このプロセスからはデバイスドライバに対して直接アクセスしてないのではないかと考えている。

ということで>>296にも書いたが、デバイスドライバに対してDirctShowの仕組み、恐らく別プロセスのCOMサーバー上からデバイスドライバにに設定値を送り込んでいるのではないかと考えている。
フィルタグラフを構築する時に、チューニングスペースオブジェクトかMicrosoft DVBT Network Providerフィルタに設定値を送り込む機能があるのではないか、もしくはチューナーフィルタか
キャプチャフィルタにその機能があるのではないかとも考えている。

この推測に基づいてまずは、DirectShowのCOMサーバーの実体プロセスがあるものと考え、それがどれなのかを調べていくとことにする。

---------
別談だが、pestudio.exeでHDTV_PX_W3U3_BDA.sysを調べた時に嫌なImported symbolを見つけた。
srand(乱数)だ。1024byteのデータ、keyという変数が登場する何かの処理、ここから得られたデータをデバイスドライバに対して上記の方法でデバイスドライバに送るので、
これはもしかしたらこれがこちらから送ったkeyを元にどこかで乱数を加え、 MULTI2暗号化されているデータを更にPlex独自の暗号化をHDTV_PX_W3U3_BDA.sysで施し、
キャプチャフィルタから送出されるのではないかと考えている。
そうなると>>296でも書いた２つのデータテーブルの前の謎の1024Byteのデータテーブルが暗号解読に必要なキーではないかと合点がいく。あくまで推測なので定かではない。

312 ：300：2015/09/18(金) 17:08:37.10 ID:molxTCMc.net

>309
RPC_E_CHANGED_MODEのEはErrorの意味なので、この場合はCoUnInitializeはいらないようです。

スレッドモデルについてですが、もちろん>308に記載の通りにCoInitialize自体を適切なタイミングで行うと仮定して、
まさにwww.kekyo.net/2013/07/22/382を読んでCOINIT_MULTITHREADEDでいいのではないかなと判断しました。
「スレッドで行われる操作が、ウインドウやウインドウメッセージに及ぶ可能性がある場合は、STAとして設定する。」
と書かれているので、単純に、BonDriverにはウインドウは関係ないからMTAでいいかな、と。

313 ：300：2015/09/18(金) 17:29:01.95 ID:molxTCMc.net

ただ、それだと乱暴なのでもう少し考えてみると、BonDriverを呼び出すアプリケーションは
以下の2種類に大別されると思います。

1.アプリケーション側でCOMを使うのでBonDriverを呼び出すスレッドですでに初期化している。(TVTest)
2.そもそもCOMを使わないので初期化もしない。(EDCB)

1.の場合は、仮にBonDriver側でCOINIT_MULTITHREADEDで初期化しようとしても、RPC_E_CHANGED_MODEが
返ってくるだけで、なんの処理も行われないので影響はない。
2.の場合はそもそもアプリケーション側でCOMを呼び出すことがないのでBonDriver側でどのスレッドモデルで
初期化しようが関係ない。

また、アプリケーション側は、BonDriver側がリアルタイムにメモリに溜め込んだTSデータを、アプリケーションの
都合のいい時にGetTsで読み出し、PurgeTsで消去処理を呼び出しているだけなので、特別な同期処理も必要ない
（GetTs, PurgeTsはCriticalsectionに入れているとして）。

というわけでCOINIT_MULTITHREADEDで問題ない様な気がしてます。

ただ、BonDriverProxyもCOINIT_APARTMENTTHREADEDなので、できたらこちらの作者のお話もお聞きしてみたいです。

314 ：名無しさん＠編集中：2015/09/18(金) 19:44:58.02 ID:bi0g4EkT.net

呼び出し元のスレッドをアパートメントが設定されてるスレッドに固定できるかどうか、って話なのでは？
呼ばれる側からは内部でCOM専用スレッドとか作らない限り固定出来ないでしょ。

COINIT_APARTMENTTHREADEDにしてるってのは呼び出し元は単一スレッドであることを前提に
メインスレッドから呼んでも大丈夫なようにしてるだけなのでは。

現状でCOM呼び出しがパフォーマンスのネックになってるかどうかも不明なのに
汎用のDLLをわざわざ危険側に倒す思想がよくわからない。

315 ：名無しさん＠編集中：2015/09/19(土) 13:14:21.14 ID:fMUe+7h+.net

>>292 でおしえて頂いた初期化処理についてですが、どうやらIKsPropertySet インターフェイスを
使っているようです。
>>311で考えた”DirectShowのCOMサーバーの実体プロセス”とやり取りをすると考えたのですが、
これは誤りで同一プロセス内のKsproxy.axフィルタを通してやり取りが行われるようです。
以下その解析記録です。

DirectShowのCOMについてこの項目を読んでいると「あっ」と思うキーワードを見つけた。
https://msdn.microsoft.com/ja-jp/library/cc354739.aspx
「Ksproxy」というキーワードである。
これは実はWinDBGで　KERNELBASE!DeviceIoControlの辺りで一時停止させた時に何度も見たもので、
KERNELBASE!DeviceIoControlの呼び出し元となっていた。
説明に「TV チューナー、TV オーディオ、アナログ ビデオ クロスバー、および KsProxy の各フィルタは、
IKsPropertySet インターフェイスによってカスタム ドライバのプロパティをサポートする。」とある。
この時はcxレジスタに0x8d81という値は1度も来なかったので、てっきりKsproxyは他の何等かの他のデバイスドライバ
に対して読書しているのだろうと勝手に思い込んでしまった。
しかしこれは間違いで実はBonDriver_PX_W3U3_T0.dllは同一プロセス内に読み込まれているKsproxy経由で
デバイスドライバに対して初期設定を行っているという思いが強くなってきた。

では何故pestudio.exeでBonDriver_PX_W3U3_T0.dllを調べた時にImported symbolの中にDeviceIoControlが
見つからなかったのか。
pestudio.exeではBonDriver_PX_W3U3_T0.dllが直接アクセスする関数しか表示されない。
その証拠に”デバイスドライバをオープンして（”1度アセクスして”が前回の記述で抜けていた）閉じるだけの
短いプログラム”を作成した時に、直接呼び出しているkernel32.dllのDeviceIoControlの表示しかなかった。
kernel32.dllが更に読みだしているKERNELBASE.dll.DeviceIoControlの表示がなかったのである。
ということでKsproxy経由のDeviceIoControlは表示されることがなかったとなる。

316 ：名無しさん＠編集中：2015/09/19(土) 13:16:03.33 ID:fMUe+7h+.net

315　続き

もう一つ疑問がある。
WinDBGに　bp KERNELBASE!DeviceIoControl+0xF "j cx==0x8d81'';'g'"　とcxレジスタが0x8d81の時停止するように
入れた時になぜ停止することがなかったのか。Ksproxy経由でも停止するはずである。
きっとマイナーファンクションコード（IOCTLコード）0x8d81がLinux用のものと違うはずだ。

そもそもマイナーファンクションコードは、デバイスドライバのプログラムソースがC言語で書かれていると仮定して
ユーザー モードアプリケーションにはWinMainとLRESULT CALLBACKがあるように、デバイスドライバには
DriverEntryとディスパッチルーチンがある。
システムやアプリケーションからデバイスドライバが呼び出されるとDriverEntryで登録されたディスパッチルーチンが
呼び出される。
アプリケーションからDeviceIoControlを実行するとディスパッチルーチンが呼び出され、引数から
メジャーファンクションコードを取り出す処理が行われる。
DeviceIoControlを実行の場合のメジャーファンクションコードはIRP_MJ_DEVICE_CONTROLであり、これを元に
switch case で分岐処理が行われ_IoCtlHandlerを呼び出す。
呼び出された_IoCtlHandlerの引数の中にスタックロケーションの構造体の
xxxx->Parameters.DeviceIoControl.IoControlCodeがある。
この値がマイナーファンクションコード（IOCTLコード）であり
これはswitch case で分岐処理に利用される。
switch caseに設定される定数はプログラマーの設定した値でありなんでもありだ。
この分岐処理の定数に0x8d81が存在すると仮定して解析をやってきたが、今では違う値だと考えている。

KERNELBASE!DeviceIoControlの所の調査からやり直すことにした。
Ksproxy経由でKERNELBASE!DeviceIoControlに来た時のcxレジスタの値を調べてみた。
0x0003 0x0008 0x0007 0x0003 0x000f.........
これらのコマンドとデータを送り込めればチューナーが何か反応するのかも。

317 ：名無しさん＠編集中：2015/09/19(土) 13:17:09.02 ID:fMUe+7h+.net

316　続き

これらの解析からIKsPropertySetを使って何等かの初期設定を行ってチューナーに起動をかけていると考えていこう。
上記のMSDNに「アプリケーション ベンダーは、IKsPropertySet インターフェイスのメソッドを使って、
ドライバやフィルタが特定のプロパティ セットをサポートしているかどうかを調べ、それらの
プロパティを取得または設定できる。」とある。

PLEXの提供するCLSIDが必要らしい。
そんな資料ない...。先は随分長そうだ。

318 ： ◆SALrG1ld3mTc ：2015/09/19(土) 19:19:11.78 ID:92YkKb/m.net

>>313
BonDriverProxyの場合は単純に、読み込んだBonDriverがCOMを使っていた場合に、STA/MTAのどっちを想定しているのか
わからないので、安全側に倒すと言う意味でSTAにしています

また、現代のPCの性能ではMTAを使って目に見えてパフォーマンスを上げられるとすれば、まず使用するCOMオブジェクトの
ThreadingModelがFreeかBothであり、かつそのCOMオブジェクトのメソッドをフルスピードで回るループの中から
呼び出しているようなパターンくらいじゃないでしょうか？
BonDriverのAPIのような、昨今のCPUの速度を基準にみるとごく低頻度で呼び出されるだけと言える用途では、
それによる性能改善はほぼ無さそうな気がしますヽ(;´ー`)ノ

319 ： ◆SALrG1ld3mTc ：2015/09/19(土) 19:23:49.63 ID:92YkKb/m.net

そう言えば、COMを使うBonDriverの実装の形として、大体は取得したCOMオブジェクトのインタフェースをメンバ変数に
保持していて、API内部ではそのメンバ変数経由でCOMオブジェクトのメソッドを呼んでいます
この場合、例えばAPI1とAPI2で上記メンバ変数を使用していたとして、アプリがそれらを別スレッドから呼び出した場合、
特に目的のCOMオブジェクトのThreadingModelがSTAに属するものであった場合は、本来のCOMの仕組みから外れた
危ない使い方をしている事になってしまいます
ですが、正しい使い方(律儀に元のインタフェースをマーシャリング/アンマーシャリングして、別スレッドからの
呼び出しであった場合には取得したプロキシ経由でメソッドを呼び出す)をした場合に本来発生する筈の、
WindowメッセージによるCOMのマーシャリングをバイパスして直接メソッド呼び出しになるので、その分の
オーバヘッドは発生しなくなっています

つまり、本来重い(かもしれない)はずのアパートメントをまたいだCOMオブジェクトのメソッド呼び出しですが、
少なくともソースが存在しているBonDriverでの実情としては、上記の通りほぼ単なるメソッド呼び出しとなっているので、
そう言う意味でもSTA/MTAの違いは恐らく有って無いような物ではないでしょうか

またこのようなつくりになっている関係上、その手のBonDriverを利用する際には、OpenTuner()/CloseTuner()/
SetChannel()/GetSignalLevel()辺りの呼び出しはそれぞれ排他にしておいた方が無難なのでしょう
本来はxtne6fさんが行われたこの↓使い方が一番安全なんでしょうけどもヽ(;´ー`)ノ
http://peace.2ch.net/test/read.cgi/avi/1438432913/792n

320 ： ◆SALrG1ld3mTc ：2015/09/19(土) 19:38:24.01 ID:92YkKb/m.net

>>310-311,315-317
当方もさっきまたBonDriver_PX_W3PE_S0.dllを眺めてたんですが、確かにBonDriver_HDUSで言う所の、
CDShowMain::CreateAddTunerDevFilter()成功の後、m_pTunerDeviceにIKsPropertySetをQueryInterface()して、
それ経由でデータの取得や設定を行っているように見えますね
対象のguidPropSetは{9E1781E1-9CB1-4407-BBCE-5426C8D00A4B}、dwPropID==0x0cがlinuxドライバでの0x8d81相当、
0x0dが0x8d82相当、0x09(それが失敗したら0x14)が0x8d83相当かと思います

dwPropID==0x0dで得た16バイトの乱数とシードである
{0x61,0xd8,0x56,0x3d,0xc1,0x15,0x46,0x68,0xb2,0xec,0x6f,0xa9,0xed,0x45,0x33,0x81}
からGetKey()相当の処理を行って鍵を取得し、dwPropID==0x09でドライバにセットと言う流れのようですね
＃なお、上記シードはdwPropID==0x09用で、0x14用はまた違う値です
この一連の処理は、>>305にも書いた通りBonDriver_PX_W3PE_S0.dllのロードアドレス+1040c辺りから始まっていますので、
デバッガで動き見るならその辺からで大丈夫だと思います

一応、このIKsPropertySetは他のdwPropIDでSetChannel()やらGetTsStream()の中からも使われているようですが、
その処理が実際に呼ばれるのかどうかはわかりません、と言うか、これ以上は実機での動作が見られないとﾂﾗｲ(;´Д`)

とりあえず上記初期化処理だけやってRun()してみる感じでどうでしょう？

321 ：名無しさん＠編集中：2015/09/19(土) 23:12:57.82 ID:W5x7rP0N.net

>>318,319
詳細な解説ありがとうございます。
パフォーマンスの実情を踏まえて安全側にふるのはまさにその通りだと思います。

仰る通り、xtne6f氏がEDCBを改良してくれたのでBondriverのCOM問題は実質解決ですね。

322 ：名無しさん＠編集中：2015/09/20(日) 14:13:51.94 ID:klFkVMgH.net

>>319
解析おつかれさまです。
詳細な報告、非常に参考になります。

323 ：名無しさん＠編集中：2015/09/21(月) 20:06:23.79 ID:GRggE4EQ.net

>>320

GIUDとコマンドの件ありがとうございます。
dllからそれを引き出すとは、BonDriverProxyの作者さん、スゴイ解析力ですね！。
とても関心します。

この様に初期化部分を作って　　　http://www1.axfc.net/u/3537512
動かしてみてます。
結果ですが、確かに[0x0c 読出] [0x0d 読出] [0x14 書込]　コマンドとして
全てS_OKで返って来るところまで来たのですが、今の所グラフの動作には至っておりません。
pIKsPropertySetの引数についていまいち理解できないので、おおよその検討で引数を入れています。


後、guidPropSet値なんですが、これをHDUS用のソースに入っているものと比較した時に
同じ9E1781E1なので不思議に思って調べていくと、ドライバのinfを見るとコメントの
記述の仕方が同じ。ドライバーsysの中を調べてみるとASICENとの記述が両方ともに。
ASICENとHDUSとPLEXでネットで検索すると、HDUSもPXシリーズも台湾のASICEN社の
製品だと理解しました。　
それでHDUSとPLEXのリモコンが完全互換なんだと、納得です。

324 ： ◆SALrG1ld3mTc ：2015/09/22(火) 06:55:06.68 ID:knSVcOol.net

>>323
ｽﾐﾏｾﾝ、良く見たらdwPropID==0x14はデスクランブルさせる場合のオプション用っぽかったので、
本筋には関係無さそうでした
＃M2_DECオプションを有効にする場合は0x14でそれ用の初期化を行う、みたいな感じっぽいです
その辺もまとめると、多分こんな感じになるのかなと思いますヽ(;´ー`)ノ
ttp://pastebin.com/KLvqDwir

325 ：名無しさん＠編集中：2015/09/23(水) 01:01:15.12 ID:FbNy3djd.net

>>324　結果から言いますと、

ついにフィルタグラフにrunが掛かりました。
チューナーに対する初期設定がうまくいったようです。

現状の改変ソースを参考資料としてアップしてみます。
http://www1.axfc.net/u/3538282
一部constがビルドで引っ掛かるとこがありましたので、
constを抜いて、仮にg_M2_Dec = 0を入れて起動させています。

BonDriverProxyの作者さん。モノスゴイ解析力ですねぇ。
コマンドの解釈や、GetKey2の処理をよく新たに見つけ出したものだと驚きます。

一点質問なのですが、M2_DECオプションを有効にした場合
ハード上もしくはドライバ上でデスクランブルすると解釈して
いいのでしょうか？

326 ： ◆SALrG1ld3mTc ：2015/09/24(木) 07:28:51.80 ID:gsOg05yg.net

>>325
> 一点質問なのですが、M2_DECオプションを有効にした場合
> ハード上もしくはドライバ上でデスクランブルすると解釈して
> いいのでしょうか？

全然調べていませんが、恐らくドライバで行われるんだと思います
linux版のドライバにはまるもさん作の「ARIB STD-B25 仕様確認テストプログラム」が
ほぼそのまま組み込まれているようなので、多分windows版でも同じなんでしょう
＃もちろん、内蔵カードリーダにカードを刺しておく事が前提でしょう

327 ： ◆SALrG1ld3mTc ：2015/09/24(木) 07:33:48.18 ID:gsOg05yg.net

あともうちょっと調べたら、>>320で書いた
> 一応、このIKsPropertySetは他のdwPropIDでSetChannel()やらGetTsStream()の中からも使われているようですが、
はやっぱり使われてるみたいですね
特にGetTsStream()から呼ばれる方はコンテンツの復号(MULTI2ではなく独自のスクランブルの)を行うために必須のようです
適当にですがコードに起こしてみました
ttp://pastebin.com/2cxf0Sb5

SetChannel()の方では、m_pcDShow->SetChFreq( iFreq );の後に、
---
m_pcDShow->SetChannel(BSならtrue CSならfalse, TSID, SID);
---
と言う感じで呼びます
TSIDはそのTSストリームのTSID、SIDは(恐らく)そのTSストリームのサービスの適当なSIDか0で、
これらは(SetChFreq()に渡す周波数とともに)iniファイルから読み出して設定します
なお、この処理はS側のみでT側では必要ありません

GetTsStream()の方では、m_LastBuffにデータを取得した後、
---
m_pcDShow->Decode(m_LastBuff->pbBuff, m_LastBuff->dwSize);
---
と言う感じです
手元にはテストできる環境が無いので、ちゃんと動く可能性はだいぶ低そうですが(;´Д`)

328 ：名無しさん＠編集中：2015/09/24(木) 19:44:37.76 ID:YSiFFSy0.net

なにこの難解なスレｗ

329 ：名無しさん＠編集中：2015/09/24(木) 23:27:54.23 ID:cIFUPuu/.net

>>327 結果からですが。

動きましたーー！。
まだ地上波のみですがTvTestで表示できましたー！

衛星側はまだ作りこまないと何もできませんが、とりあえず地上波側の表示はできました。

>>327 の新しいコードと入れ替えて動かしてみるとTSデータの取得が始まって最初の数秒はパケット数が少ないのですが、
途中からパケットが多くなってそこでエラー停止していたので一時バッファだと思われるバッファをを倍にしてみたところ
動作するようになりました。
このバッファを倍にして他に影響ないのかよく理解していないのですが、とりあえずこれで動きます。

この停止が起きた時に１００％ではないのですが、デバイスドライバが離脱することがあることがわかりました。
その辺りの耐久性がないようです。ネットで時々書き込みを見るPLEXチューナーを見失う現象は、
このことではないかと考えています。
このバッファオーバーによるものと思われる対処としては、バッファが溜まり過ぎた時の処理を見直すか、
バッファを増やしてにして他に悪影響ないようであればiniでバッファ量を指定できるようにしようと考えています。

今後はゆっくりですが先に衛星側の作りこみ、チューナーとキャプチャ（現在固定）の選択の仕方変更、
iniでバッファ量を指定、その後TSバッファがらみでメモリコピーを多用しているところがあり、ポインタ処理に
置き換えれば若干パフォーマンスアップを狙えそうな所があるので、その辺りに手を付けるつもりです。

開発資料として現状のソース公開しておきます。

http://www1.axfc.net/u/3539440

BonDriverProxyの作者さん、またまた大感謝です。
これだけのコードを解析から引っ張りだしてくるとは・・・・
今では、何かの実を食べた「能力者」なのではないかと思っていますyo。

330 ： ◆SALrG1ld3mTc ：2015/09/25(金) 07:28:16.61 ID:rOivCOgP.net

>>329
あ、動きましたか
Decode()の処理相当の部分を追いかけてる時に、なんか凄く冗長だったので、無駄だと思われる部分をかなり削って、
でも実はやっぱり必要だったりして…とか少し思ってたんですがヽ(;´ー`)ノともあれ動いたようで何よりです

これらのロジックがちゃんと動くなら、後は普通のBDA系のBonDriverと同じなので、PLEX機器用のBonDriverが
バイナリしかないと言う状況は近々終わりそうですね
どうせならBonDriver_HDUSベースよりも、近年の改良・整理されたBonDriver_BDAをベースにした方が
良いかもしれません
ぜひ良いものをつくって公開して下さいヽ(´ー`)ノ

リンク先のソースでの使用方法をパッと見た感じでは、CBonTuner::RecvProc()でDecode()を呼んでいますが、
呼ぶなら現在の位置ではなく、
---
memcpy(pItem->pbBuff, pSys->m_bRecvBuff, pItem->dwSize);
---
の行の直後に、
---
m_pcDShow->Decode(pItem->pbBuff, pItem->dwSize);
---
とした方が良いんじゃないでしょうか
細かい単位で頻繁にシステムコールを呼び出すよりも、ある程度まとめてから呼んだ方が良いと思うので

また、多分勘違いだと思うのですがCBonTuner::SetChannel()からも呼んでいますが、Decode()は188*nの
単位での呼び出ししか想定していないので、この呼び出しでメモリ破壊が起きてるかも…

あと、もしPLEX_FUNC_0x0CやPLEX_FUNC_0x0Dの呼び出しで得られる結果が毎回同じなら、
鍵(dwKey)は最初に一度つくればDecode()呼び出すたびに毎回つくらなくても良くなりますね

とりあえずそんな感じですよ

331 ： ◆SALrG1ld3mTc ：2015/09/25(金) 07:30:50.13 ID:rOivCOgP.net

>>328
ｽﾐﾏｾﾝ、確かにだいぶスレ違いですね…
過去ソースの無いBonDriverでトラブるパターンが結構多かったもので、
ちゃんとソース付きのが出てきたら良いなと…(;´Д`)

332 ：名無しさん＠編集中：2015/09/25(金) 08:17:51.05 ID:OyXy4mfw.net

まあPLEX系でソースありになればうれしい

333 ：名無しさん＠編集中：2015/09/25(金) 08:28:42.66 ID:AbX8MWdv.net

PLEXのbondriver専用スレ立ててやるのがいいかもね
ベースが同じだから旧製品からこれから発売される新製品まで全対応出来るし

334 ：名無しさん＠編集中：2015/09/25(金) 09:58:37.86 ID:d0hb4BNi.net

世の中すごい人達がいるもんだ
Proxy系にはいつもお世話になってます。あざーっす

335 ：名無しさん＠編集中：2015/09/25(金) 14:49:59.66 ID:Az6h2rPs.net

>>331
参考になって楽しいですよ。

336 ：名無しさん＠編集中：2015/09/25(金) 17:21:27.62 ID:O0Vq2wbo.net

難解発言した人も悪気は無いと思うよ
俺は何も理解できなけれど、何かが発展して言ってるというのは、飛ばし読みしてても面白い
嫌いなのは出し惜しみだから

337 ：名無しさん＠編集中：2015/09/25(金) 18:02:27.13 ID:L2vPzgGJ.net

>>333
ASICENじゃないのはまた別に解析が必要そう(GUIDも違う)

338 ：名無しさん＠編集中：2015/09/25(金) 19:09:07.25 ID:eCL+WuMi.net

【PLEX】PX-S1UD/BCUD Part4 【ドングル】©2ch.net
http://peace.2ch.net/test/read.cgi/avi/1441037359/

こっちのBCUDの方も頼むわ
必要ならBCUD送るよ

339 ：名無しさん＠編集中：2015/09/25(金) 23:12:53.33 ID:ydjL2w8B.net

BondriverProxyを使用して1つのチューナーを2つのTVTestから視聴しようと試みています（もちろん同じ番組）
Bondriver_Proxy.dll
Bondriver_Proxy_splitter.dll（splitterを間にかませたもの）
から同時に視聴しようとするとBondrvier_Proxy.exeがクラッシュします（splitterの有無を統一すれば動作）
こういう使い方は無理でしょうか

340 ：339：2015/09/26(土) 00:53:58.53 ID:ULbc/8bD.net

考え直してsplitter有りで統一して運用方法を工夫することにしました
１つのチューナーを別のBondriverでって無茶な使い方ですよね。スレ汚しすみませんでした

341 ：名無しさん＠編集中：2015/09/26(土) 11:12:22.35 ID:GuD/O58I.net

新ドライバーでPT2のバグ直ったのかな？

342 ：名無しさん＠編集中：2015/09/26(土) 18:45:35.57 ID:kGGMlB+o.net

バグとは？

343 ：名無しさん＠編集中：2015/09/26(土) 19:20:36.45 ID:SBq10ySz.net

買ったら新しいPCを生やしてしまうバグ

344 ：名無しさん＠編集中：2015/09/26(土) 23:24:33.74 ID:Vrno3hSp.net

>>342
32bit Windowsでメモリが4GB以上だと0Mbps病が発症する問題かな？

345 ：名無しさん＠編集中：2015/09/27(日) 00:00:03.52 ID:Z/H6YHq8.net

バグっちゃバグなんだろうけど、どうせ物理アドレス考えれば原理的に使えないんだろうし･･

346 ：名無しさん＠編集中：2015/09/27(日) 18:54:00.64 ID:w2qquhAH.net

>>339-340
---
TVTest1 - BonDriver_Proxy.dll --------------------------|- BonDriverProxy - 対象BonDriver
TVTest2 - BonDriver_Splitter.dll - BonDriver_Proxy.dll -|
---
なら可能ですが、
---
TVTest1 - BonDriver_Proxy.dll -|- BonDriverProxy -|- 対象BonDriver(A)
TVTest2 - BonDriver_Proxy.dll -|　　　　　　　　　|- BonDriver_Splitter.dll - (A)と同じ対象BonDriver
---
はできないです
下の形では、BonDriverProxyと言う一つのプロセスが同じBonDriverを複数回読み込む事になりますが、
大抵のBonDriverは一つのプロセスから複数回読み込まれる事を想定しておらず、その様な使い方をした場合は、
BonDriver内部で管理変数の上書き破壊等が発生する事になります
＃https://github.com/u-n-k-n-o-w-n/BonDriverProxy/blob/61460a3caf1eaf6adaa785e58a80e8a9e676050a/ReadMe.txt#L65-L67
＃で書いてるのはその様な場合の話です

その状態で処理を続けた場合にどうなるのかはそれぞれのBonDriver次第で、またホストプロセスの構造にもよるとは
思いますが、例えばBonDriverProxyがBonDriver_PTやBonDriver_PT3をこのように使用した場合を考えると、
恐らくBonDriver側で管理されているメモリへのアクセスに関してスレッド間での競合が発生し、落ちる事になるでしょう
＃これは、ポインタを返す方のGetTsStream()等は非同期で呼び出される事を(恐らくBonDriverのAPIの仕様として)
＃想定していない為、スレッド1に返したメモリ領域をまだスレッド1が使用しているのに、スレッド2が解放してしまう、
＃と言う事が起こるからです

ダラダラと書きましたが、要はその形での使用はBonDriverProxy側だけで何とかできる範囲ではないので、できないです、
と言う事になります(;´Д`)

347 ： ◆SALrG1ld3mTc ：2015/09/27(日) 18:56:17.02 ID:w2qquhAH.net

ｽﾞﾚた(;´Д`)>>346は当方です

348 ： ◆SALrG1ld3mTc ：2015/09/27(日) 19:04:05.28 ID:w2qquhAH.net

>>338
少し見てみましたが、BonDriverで復号的な事はやっておらず、変わった事やってるのは
SetChannel()とGetSignalLevel()の中くらいにみえますね
その変わった事の内容は
ttp://pastebin.com/qTDSa8pw
な感じです

ttp://www1.axfc.net/u/3506839
のBonDriver_BDASのソースなら、
CBonTuner::LockChannel()の中の
---
pIRequest->put_Locator(pILocator);
---
の後で、
---
CustomSetChannnel((WORD)lTSID);
---
みたいに呼んで使います

CustomGetSignalLevel()の方は、CBonTuner::GetSignalLevel()の頭で呼んで、多分RSSIが2バイト値で
返って来るので、これで得た値を元にfloatのCNRとして計算したのを返してるようです
こちらはBonDriver_BDASが行ってるように、BDA標準の方法でとれるなら使う必要は無いかもしれませんね

どっちにしろ、インタフェースの型が良くわからなかったので関数ポインタ経由で無理やり呼び出しており、
まともに機能するかどうかはわかりませんが(;´Д`)

349 ：339：2015/09/27(日) 19:27:17.62 ID:AF71QNeR.net

>>346
レスありがとうございます
今は
TVTest1 - BonDriver_Proxy.dll -|--------||------- BonDriverProxy - BonDriver_Splitter.dll - 対象BonDriver(A)
TVTest2 - BonDriver_Proxy.dll -|
のようにしています。これで録画しながら軽くしたTSを視聴したいという目的は達成できました
運用開始直後に一度だけBonDriverProxyがクラッシュしたのですが（慌ててレポート取り逃した）それ以降は何度試しても正常動作しています
たぶん大丈夫でしょう。お手数をお掛けいたしました。素晴らしいソフトに感謝です

350 ：338：2015/09/27(日) 23:17:28.55 ID:TgOHQ+jD.net

>>348
レスありがとうございます
BDASに上げてもらったコード組み込んで試してみます

351 ：名無しさん＠編集中：2015/09/28(月) 00:02:56.68 ID:P8iLFU2e.net

>>348
教えてもらったコードでTSID指定でBSのチャンネル取れるようになりました
それと動作させるのになんらかの初期化コードが要るようなんですが、わからないですかね？
バイナリで公開されているBondriverでスイッチを入れてからでないと動かないんです

352 ：名無しさん＠編集中：2015/09/28(月) 00:50:07.72 ID:R5uGdt/w.net

>>351
>>288このあたり以降が関係していないかな？

353 ：名無しさん＠編集中：2015/09/28(月) 02:24:33.40 ID:P8iLFU2e.net

BonDriver_BDAS Ver.0.03
http://www1.axfc.net/u/3541290

[更新履歴]
Ver. 0.03
・カスタムコード追加によりTSID指定でBSのチャンネルが取れるようになった


これにPLEXチューナーの初期化処理を入れなきゃなんないってことかな？
>>327のやつを組み込めばいいのかな？別のBondriver用みたいだけどね

354 ： ◆SALrG1ld3mTc ：2015/09/28(月) 20:51:07.19 ID:cGa3TeDv.net

>>350-353
うーん、とりあえずOpenTuner()終わりまでにはW3PEやW3U3でやってるような特殊な処理は
入ってないように見えますね
基本的に普通のBDA系BonDriverと同じで、BonDriver_BDASで言うところの
CBonTuner::LoadAndConnectTunerDevice()内の、
---
string::size_type n = 0;
wstring semName = displayName;
while ((n = semName.find('\\', n)) != string::npos) {
semName.replace(n, 1, 1, '/');
}
---
が、
---
string::size_type n = 0;
wstring semName = displayName;
bool find = false;
if (semName.find(L"vid_3275", n, 8) != string::npos)
find = true;
if (semName.find(L"pid_0085", n, 8) != string::npos)
find = true;
if (!find)
continue;
while ((n = semName.find('\\', n)) != string::npos) {
semName.replace(n, 1, 1, '/');
}
---
みたいな感じになってるくらいです
あと、m_pTunerDeviceとm_pCaptureDeviceをAddFilter()する時は、friendlyName.c_str()使わずに、
それぞれL"DVB-S Tuner"とL"DVB-S Capture"で固定ですね

355 ： ◆SALrG1ld3mTc ：2015/09/28(月) 20:53:12.62 ID:cGa3TeDv.net

BonDriver_BSCSをどのタイミングまで使えばBonDriver_BDASが使えるようになるのかわかるでしょうか？
DLLをロードするだけ、CreateBonDriver()まで、OpenTuner()まで、最初のSetChannel()まで、と少しづつ
機能を使っていって、どの段階でBonDriver_BDASが使えるようになるのかがわかれば、どこに鍵になる処理が
あるのかのヒントになりそうです

…CustomSetChannnel()のChannelをtypoしてるのにさっき気付きました(;´Д`)失礼しました

356 ：名無しさん＠編集中：2015/09/28(月) 22:07:14.15 ID:P8iLFU2e.net

>>355
わかりました
特殊なチューナー初期化コードは必要ないということなんですね

>BonDriver_BSCSをどのタイミングまで使えばBonDriver_BDASが使えるようになるのかわかるでしょうか？
>DLLをロードするだけ、CreateBonDriver()まで、OpenTuner()まで、最初のSetChannel()まで、と少しづつ

うーん…それはVSのデバッガ使って追わないといけないんですよね
今度時間あるときにやってみますね

357 ：名無しさん＠編集中：2015/09/28(月) 22:10:26.52 ID:P8iLFU2e.net

>>355
必要ならBCUD送ってもいいですけどね

358 ：名無しさん＠編集中：2015/09/28(月) 23:43:04.50 ID:P8iLFU2e.net

BonDriver_BDAS Ver.0.04
http://www1.axfc.net/u/3541846

Ver. 0.04
・BonDriver_BDAT Ver.1.05 までの更新内容をだいたい取り込んでおいた
・あとはチューナーのスイッチが入るようになれば完成