BonDriver共有ツール総合 [sc](★0)
-
- 1
- 2013/04/19(金) 11:48:58.95
-
BonDriver共有ツール総合
-
- 914
- 2015/02/08(日) 03:26:52.06
-
BondriverProxyで要望なのですが、
PT3等の複数のチューナーがある場合、PT3のBondriverを
チューナーの数だけコピーしないといけない仕様になっていますが、
本来BonDriver_PT3-T.dllは1つで複数のチューナーを扱えるようになっているので
BondriverProxyの方でも、BonDriver_PT3-T.dllからエラーが返ってくるまで
別のチューナーを制御するようにするか、もしくはiniで
00=PT-T;BonDriver_PT3-T.dll,2
のように、チューナー数を設定して、BonDriver_PT3-T.dllを
複数コピーしなくてもいいような仕様にしていただけるとありがたいです。
長文失礼致しました。
-
- 915
- 911
- 2015/02/08(日) 03:27:50.41
-
>914
BondriverProxyというよりBondriverProxyExへの要望でした。
-
- 917
- 2015/02/08(日) 14:10:42.28
-
>>916
ドロップしてたら音声再エンコしなけりゃ大概はいけるが。うちクソ環境なんでw
-
- 918
- 2015/02/08(日) 15:56:04.69
-
何かある人は、gdgd言わずに、普通にパッチ書けばいいんじゃないのかな？
-
- 919
- 2015/02/08(日) 15:59:32.68
-
>>918
せやな
-
- 920
- 2015/02/08(日) 23:08:05.53
-
>>914
えーと、例えばBonDriver_PT/PT3が単一dllで複数のチューナを扱えるのは複数のプロセスから読み込まれた場合のみで、
単一のプロセスからは複数のチューナを制御できるようにはなっていないのです
なので、その機能を素直に実装しようとすると、bdpexサーバ側だけで無くBonDriver_PT/PT3側の改造が必要になります
例えばEDCBなんかは1プロセスからは1チューナのみ扱うようになっているのでこの仕様は問題にはならないのですが、
bdpexサーバを同じ様な形に変更しようとすると多分大改造になると思うのでちょっと厳しいですね…
またbdpexサーバをその形で実装した場合、BonDriver操作用のワーカープロセスとbdpexサーバ間でプロセス間通信
する事になるので、その分の処理負荷及びメモリ使用量が確実に上乗せされてしまいます
それで得られるのはBonDriverをコピーしないで済んだ分のHDD容量節約くらいですから、正直メリットより
デメリットの方が多いかなと…
-
- 921
- 2015/02/09(月) 17:50:37.82
-
なるほど。
思ったほど簡単にはいかないんですね。
回答ありがとうございました。
-
- 922
- 2015/02/18(水) 16:19:04.26
-
BonDriverProxyExですが、チャンネルの共有がうまく動作しないことが時々あるようです。
いろいろやって試してみた結果、以下の手順で再現するみたいでした。
【BonDriverProxyEx側の設定】
地デジチューナー2つを共有
00=ISDB-T;BonDriver_XX_T0.dll;BonDriver_XX_T1.dll
【使用するアプリ】
EpgDataCap_Bonを２つ（CHANNEL_LOCK=1）
TVTest（CHANNEL_LOCK=0）
【再現手順】
１．1つ目のEpgDataCap_Bonを起動、CHを7にする
２．2つ目のEpgDataCap_Bonを起動、CHを1にする
３．TVTestを起動、CHを1にする
→TVTestのCHは1になる
４．TVTestのCHを7にする
→TVTestのCHは7になる
５．1つ目のEpgDataCap_BonのCHを3にする
→TVTestのCHも3になる
６．TVTestのCHを4にする
→TVTestのCHは1になる
７．TVTestのCHを3にする
→TVTestのCHは3にならず1になる
-
- 923
- 2015/02/18(水) 22:30:15.88
-
>>922
再現手順の調査、ありがとうございます
ロック権を持っていないクライアントがチャンネル変更を要求した場合に、目的チャンネルを選局している
チューナは無く、空きチューナも無く、かつロックされていないチューナも見つからなかった場合に、
目的チャンネルには変更できないけどとりあえず適当にチューナを選択していたのですが、その際に、
自身の保持チャンネルを、その選択したチューナが選局しているチャンネルに更新していないのが原因でした
調べて頂いた再現手順で言うと、ステップ5.でTVTestのクライアントインスタンスの保持チャンネルもch3に
変更されますが、ステップ6.ではch1にはならず(もちろんch4にもならず)ch3のままとなってしまっており、
この為、ステップ7.で既にch3を選局していると判断してしまっていました
対応してみたので、ご確認ください
-
- 924
- 2015/02/18(水) 23:11:58.81
-
酷いソフトですね
って言うか
各人の捉え方の様々な解釈で作ってしまう、検証してしまうのは
金を取って販売する企業としては、随分問題でしょう
何ですか、意地悪テストってのは
各人がその時の主観で突っ込み入れるのが
上場企業の研究所wがする仕事の仕方なんですか ?
過去に泥塗るのやめて、蓄音機と犬のマーク外しましょうよ
-
- 925
- 2015/02/18(水) 23:35:13.11
-
>>924
ひどい誤爆ですね
-
- 926
- 2015/02/19(木) 01:08:32.60
-
たれか我をすくってたべ
この言葉の意味を知ろうとして web で検索しようが
容易に答えにたどり着けない。
誰か私を救ってくれ…賜べは、ほとんど命令
お前らの言い方なら
黙って見てねぇで誰でもいいから俺様を助けろや
-
- 927
- 2015/02/19(木) 19:43:17.01
-
>>926
大丈夫、見守ってるよ。
寒い中、今も外で。
-
- 928
- 2015/02/19(木) 22:28:49.92
-
なんだこのキモいレス
-
- 929
- 919
- 2015/02/20(金) 17:58:23.73
-
>>923
対応ありがとうございます
問題が発生しなくなっているようです
ところで別件ですが、BonDriver_Proxy.dllのGetSignalLevelで、アプリ側が意図した値が取得できない問題があるようです
例えばTVTestの場合、チャンネルスキャン時のSetChannnelのほぼ直後にGetSignalLevelを行いますが、
１．SetChannnel直後のSignal値が反映されず誤ってチャンネルをスキップしてしまう
２．連続した空きチャンネルで最後に受信できていたチャンネルのSignal値が返ってくるためスキャン時間が大幅に長くなる
等の問題が発生してしまうようです
さほど重要な問題ではないですが、検討いただけるとありがたいです
-
- 930
- 2015/02/21(土) 19:15:53.79
-
>>929
ナルホド、確かに発生しそうだなと思ったのでひとまず対応してみました
とりあえず変更入れたのはクライアント側のみですが、実は完全な対応の為にはサーバ側にも
変更が必要なのはわかっているので、その内そっちもやるかもしれません
-
- 931
- 2015/02/23(月) 13:59:47.39
-
サーバー側で1秒に1回しかGetSignalLevel()やってないから
正しい値が返ってこないのはあまり変わらないような
-
- 932
- 2015/02/23(月) 23:20:03.96
-
>>930
それが
> 実は完全な対応の為にはサーバ側にも変更が必要なのはわかっているので
の件ですねヽ(;´ー`)ノ
なので対応してみました
＃b25パッチを作成してる方は若干変更が必要ですが、面倒は減ったんじゃないかと思います
ちなみに、クライアント側だけでの対応でも>>929さんの2.の問題は間違いなく回避できる筈ですし、
1.の問題も、問題が発生するパターンは変更前チャンネルのCNRが低い値で、それを間違って読んでしまって
発生すると言う事と、普通チャンネルスキャン時はチャンネル変更してから数秒はデータ取得して待つので、
＃TVTestの場合は(チャンネル変更後の待ち時間をそれ以下にしていない限り)最低2秒は待つようになっている様です
現実的には大体問題無くなるんじゃないかなと
-
- 934
- 2015/02/26(木) 04:18:21.49
-
BonDriverProxyが起動しない
Windows8.1 64bitもWindows Home server 2011も駄目だった
-
- 935
- 2015/02/26(木) 05:03:27.91
-
タスクマネージャー見てみたか？
-
- 936
- 2015/02/26(木) 05:20:48.43
-
見たけどそれらしいのは無かった
exeファイルを削除できたから間違いなく起動してない
ランタイムは一通り入ってる
-
- 937
- 2015/02/26(木) 05:29:57.08
-
VMware上のWindows7 32bitでも駄目だった
-
- 938
- 2015/02/26(木) 05:46:23.78
-
類似ケースの原因で >>738 が有るけど、どうですか？
-
- 939
- 2015/02/26(木) 06:09:53.33
-
>>938
正常に起動しました
ありがとうございました
-
- 940
- 2015/02/26(木) 10:12:56.17
-
いいってことよ
-
- 941
- 2015/02/26(木) 19:43:21.24
-
BonDriverProxy系はdescrゴニョゴニョ機能無いん？
-
- 942
- 2015/02/26(木) 21:50:09.93
-
>>941
パッチがある。
-
- 943
- 2015/02/26(木) 22:39:01.55
-
上の方で語ってるbなんたらの事か
ビルドは出来てもソース読めないとキツそうだなあ
-
- 944
- 2015/03/02(月) 12:47:49.58
-
BonDriverProxyってスカパープレミアムで使える？
-
- 945
- 2015/03/03(火) 00:25:57.83
-
このスレに少し関係あるかも
TVTest.tuner.ini で各チューナーの仕様を定義してBonDriver設定の初期値などに利用するようにした
https://github.com/DBCTRADO/TVTest/commit/f3e90c79d911937c47ca24d2eedcabef69cb8414
-
- 946
- 2015/03/03(火) 23:09:54.29
-
>>944
このスレの上の方で使ってる人いたよ
-
- 947
- 2015/04/02(木) 00:05:21.99
-
proxyex、出来自体はspinelよりいいんだけどサーバーがスリープから復帰後にクライアントから見失うのが残念。
サービス化しても変わらんかった。sexeかまさないと、scコマンドで登録だとサービス開始できないし。@win8.1
-
- 948
- 2015/04/02(木) 00:12:05.60
-
それサーバっつかクライアント側の問題じゃないの？
一度切断しちゃうと再接続してくれないって事だよね、多分
-
- 949
- 2015/04/02(木) 00:25:04.59
-
いや電気代の節約で録画サーバーをスリープさせてるんだけど、復帰後はproxyexが動いてないのよ
-
- 950
- 2015/04/02(木) 00:30:19.91
-
spinelはスリープから復帰後も何事もなく動くんだけどねえ。
-
- 951
- 2015/04/02(木) 00:43:51.72
-
あ、使用機器はW3U3です。ID変わっちゃっててゴメン
-
- 952
- 2015/04/02(木) 01:27:13.38
-
proxyexじゃなくUSBの問題じゃねーか
-
- 953
- 2015/04/02(木) 06:37:51.95
-
いやそうじゃないと思う。正確には
・サーバー（proxyex）とクライアント（proxy）間でのtvtest動作ok
・クライアント（proxy）をスリープ→復帰 これも動作ok
・サーバー（proxyex）をスリープ→復帰 クライアントでtvtest起動すると見失ってNULLを返してくる クライアントを再起動すると動作ok
以上はspinelだと何ともないんだけどね。調子悪くて何度かルーター再起動してるのでゴメン。
-
- 954
- 2015/04/02(木) 10:56:26.50
-
>>953
中身見てないからアレだけど、動作から推測すると、
Spinel：切断後の再接続に特別な処理は必要ない
proxyex：切断後の再接続に初期処理が必要
ってだけのような・・・
大体、クライアントは起動したまま、サーバがスリープってどういう状況よ。
-
- 955
- 2015/04/02(木) 19:21:03.60
-
>>953
うーん、何でしょう
当方も録画機はスリープ運用なので録画してる時以外はスリープさせていますが、
特にそう言う問題には遭遇していませんね…
当方の環境では、録画機はptTimerによって録画 -> スリープ -> 復帰 -> 録画 -> スリープ...のような
感じで動いており、たまにリアルタイム視聴する時に、クライアント側から録画機をWOLで起こして、
BonDriverProxy経由でBonDriver_ptmr.dllを利用しています
>>953さんの環境では、このような運用ができないと言う事ですよね？
もしそれであっているのなら、確実に再現する手順はわかるでしょうか？
ただ、
> クライアントを再起動すると動作ok
これが、サーバPCがスリープから復帰してもクライアントPCからBonDriver_Proxy.dllでの接続ができないが、
その状態でクライアントPCを再起動すればまた接続できるようになると言う意味ならば、BonDriverProxyの
レイヤの問題ではないような気がします
もしそのパターンであれば、ネットワークの何かの問題なのかなとは思いますが…
例えば、ネットワーク上にサーバPCとIPアドレスがカブッてるマシンがいたりしないでしょうか？
-
- 957
- 2015/04/02(木) 19:38:26.76
-
>>954
BonDriverProxyのセッションは接続から切断までで完結しており、途中で切れた場合は
単にそのセッションが終了したものとして扱う…としてるつもりですヽ(;´ー`)ノ
-
- 958
- 2015/04/02(木) 20:16:48.32
-
>>956
なるほど、名前解決の辺りに何かありそうですね
例えばサーバPCのDHCPでの割り当てIPアドレスがスリープ前後で変化した場合、クライアントPC側の
NBTキャッシュが実際のサーバのIPアドレスと異なってしまう可能性なんかがありそうです
例えば、サーバPCがスリープから復帰した後、クライアントPCから繋がらない状態になった時に、
コマンドプロンプトからnbtstat -Rして、再度接続してみたら繋がったりしないでしょうか？
-
- 959
- 2015/04/02(木) 20:37:41.44
-
>>958
あとでやってみます
-
- 960
- 2015/04/03(金) 15:00:46.58
-
>>958
昨夜、何度か設定や環境を見直したのですが、nbtstat -Rでリモートキャッシュテーブルを削除してみましたが変わりませんでした。
で試行錯誤を繰り返すうちに、ローカルのIPアドレスの問題ではなく、クライアントからtvtestの起動と同時にサーバーをWOLで起こすときに
サーバー側が非力なもので処理が遅れてNULLを返してくる→クライアントを再起動しないとそれ以降は何をやっても動作しなくなる、ことに気づきました。
（再現性アリ）
手動でサーバー機をスリープから復帰させて、それから落ち着いてからクライアント側でtvtestを起動すると全く問題ないです。
以上の現象はspinelでは全くなかったので気づきませんでした。
おそらくどこかでWOL時のdelayを設定してやればいいと思うのですが、まだそこからは時間が無くてやってません。
-
- 961
- 2015/04/03(金) 15:06:33.09
-
ちなみにWOLでサーバーを起こしてNULLが返ってきたクライアント1ではそれ以降は全部同じ反応で動きませんが
別のクライアント2では何事もなくtvtestが起動できました。
-
- 962
- 2015/04/03(金) 19:53:23.02
-
>>960-961
そう言う事なら、クライアント側のiniファイル内のCONNECT_TIMEOUTの値を、サーバPCがスリープから復帰して
反応が返せる様になる程度の時間以上に設定してみて下さい
デフォルトでは5秒に設定してありますが、BonDriver_ProxyからのWOLで起こす場合、(かなり速いマシン以外は)それでは
短すぎるでしょうね
Spinelでは接続タイムアウトのデフォルト値が20秒らしいので、Spinelで同じ問題に遭遇しなかったのは恐らくそれが
理由ではないかと思います
> クライアントを再起動しないと
のクライアントと言うのは、TVTest等のクライアントアプリの事でしょうか？それともクライアントPC自体の事でしょうか？
前者の場合なら、クライアントアプリ側がCreateBonDriver()に失敗した場合に、どのタイミングで再チャレンジが
行われるかと言う問題ですね
＃この場合、アプリ側から再度CreateBonDriver()を呼び出されない限り、BonDriver側では何もできないので
TVTestなら、BonDriverを選択し直せば大丈夫だと思います
後者の場合はちょっと理由の見当が付きませんね…
> ちなみにWOLでサーバーを起こしてNULLが返ってきたクライアント1ではそれ以降は全部同じ反応で動きませんが
> 別のクライアント2では何事もなくtvtestが起動できました。
との事なので、やはり前者なのでしょうかヽ(;´ー`)ノ
-
- 963
- 2015/04/03(金) 20:23:30.03
-
>>962
ありがとうございます。
遅くなるのであとでやってみますがWOLの問題は解決すると思います。
>のクライアントと言うのは、TVTest等のクライアントアプリの事でしょうか？それともクライアントPC自体の事でしょうか？
これは後者になります。
一度NULLを返されてしまうと、チューナーの選択を変えても、tvtestを再起動しても、ずっとNULLが返ってきます
クライアントPCを再起動しないと直りません、ログオフでも無理でした
（謎）
なお上でも書きましたがその時に他PCからのtvtestは普通に動くのでサーバーの方は生きていると思います
-
- 964
- 2015/04/03(金) 20:24:10.27
-
tvtestは0.9.0devの最新版です
-
- 965
- 2015/04/03(金) 21:42:08.20
-
>>963
> これは後者になります。
ありゃ、そっちでしたか…となるとやはり謎ですね
アプリケーション的にはそうなる理由なんて無いはずなのですが…
今うちの環境でも同じ事を試してみましたが、やはり再現しませんでした
＃CONNECT_TIMEOUTは5のままWOL有効にしてTVTestから読み込む -> スリープ中だったサーバPCは起きる ->
＃タイムアウトでCreateBonDriver()は失敗する -> 数秒後TVTestで再度BonDriver_Proxy選択 -> 繋がる
そうなった時にそのクライアントPCからサーバPCに、他のネットワーク通信は可能なのでしょうか？
例えばファイル共有は機能するかとか、ping打ってみたらどうなるかとか…
もしそれらも機能しないなら、単に(と言うのも変な話ですが)NICのレベルで良くわからない事になってる感じなので、
できそうな事は当該ネットワークインタフェースの無効化->再有効化やってみるくらいでしょうか
逆にそれらは機能するのにBonDriver_Proxyは動かないとなると、WireSharkあたりの出番かもしれませんね(;´Д`)
このページを共有する
おすすめワード