VirtualPT
2012年08月31日
【'12/9/5追記】
'12/9/5付でバイナリの公開を終了しました。10月以降は問い合わせについてもお答えいたしませんのでご了承ください。
※'12/9/1 「ソースコードの公開終了」から「ソースコードの一般公開終了」に訂正
'12/8/31付で寄付の受付、及び、ソースコードの一般公開を終了いたしました。バイナリの公開も9月中に終了いたします。公開停止後は「既にダウンロード済みのバイナリは使わないで欲しい。」といったスタンスになりますので、VirtualPTに関する問い合わせについても基本的にお答えいたしません。
バイナリ公開停止までの期間に新しい機能を追加することはありませんが、対応可能なバグ修正は行いますので、もしバグを発見された方は早めにお知らせください。
公開停止以外の対応も含めて検討しましたが、VirtualPT開発に関することを総合的に判断した上で公開停止を決定いたしました。寄付いただいた方々には、今後の期待もこめられていたと思うので心苦しいのですが、ご了承お願いいたします。
トラックバックURL
コメント一覧
お気遣いありがとうございます。とりあえずこのままで状況を見て判断したいと思います。
余計な火種が飛ばないよう9月中旬頃にコメント欄やlivedoorのメールを封鎖した方が良いのではないかと思われますが如何でしょう？
ご苦労様でした。
readmeだけ修正したものを欲しいと思われる方がいらっしゃるとは考えられないのですが、気付いたら終了していたという方が現れないか心配しております。しかし、いつ終了しても起こりえることなので、基本的に公開停止したら、そこまでと考えております。
ここでの流れで「察してほしい」の意味は何となくわかりました。
このソフトのおかげで助かったこともありましたので、
（職場がワンセグすら入らないので、ネットワーク経由で伝送しての視聴など）もったいない気がしますが、仕方ないですね。
GPLライセンスの問題ですが、元のBonDriverコードがLGPLならば No.26 の見解が正しいと思います。
（書込前の記事でGPLと書かれたのでNo.10のようなことを書きましたが）
議論を大きくしちゃったみたいですいませんでした。
このサイトからだけでいいのでreadme等を訂正したバイナリを公開継続してはどうですか。
例のあれのために、特にソースの公開はやめておきたい気持ち、よくわかるよ。
ソース公開の義務もないようでよかったね。
VirtualPTには本当にお世話になりました。公開停止は残念だけど仕方ないよね。
今までありがとうー
やはりそうですか。それを聞いてとても安心しました。誠にありがとうございます。
ソースについては申し訳ありませんがご了承下さい。これまで、ソースを希望される方がそれほど多くなかったことから、今回の反応には大変驚いているのですが、ソースを欲しいと言って頂ける様なソフトを開発できたことを大変うれしく感じております。
BonDriverの場合は完全にインタフェースの規定なので全く問題ないです。
ですので、VirtualPT自体LGPLに従う義務はありません。
Readmeなどを見直してみてみても、ソースの公開を義務付けられる根拠はないと考えられます。
そのうえで、
ソースほしいなぁ。とつぶやいてみる。
当方のような裕福でない開発者にとって、開発費の負担だけでも厳しいということが、ユーザーの方には分かっていただけないのかもしれませんね。将来については全く未定ですが、総合的に判断したいと思います。
testtest様
バイナリを取得した方へのソースコードの公開義務があるという点では、皆さん共通しているようですね。「最低限著作権者に開示すればよい」とどこかで見たと思うのですが勘違いだったのかもしれません。
LGPLについては、解釈が難しいようですが、当方はこのように解釈したと宣言して、「ソースコードの公開義務は無い」と改めたいと思います。readmeについてはもう訂正の手段がありませんが、サイト上だけでも訂正したいと思います。
そうなるとバイナリを即座に公開停止する理由も無くなるのですが、ソースとバイナリの停止時期が違うのはおかしいと考えている方もいらっしゃるようなので、Vectorで停止申請が処理された時点で公開終了にしたいと思います。
ソース見ないと判断できない部分かもしれません。
ココはreadmeの「BonDriverインターフェースがLGPLとなっていますので、少なくともBonDriver_VTPT.dll部分のソースコードをBonDriverインターフェースの設計者である「拡張ツール中の人」さんへの公開義務があると考えます」
という文章から判断するしかありません
ですがこの文章は間違っていて、バイナリを利用する利用者へ公開する必要があるかと思います。
また、バイナリの公開をやめればソースを公開しなくていいと勘違いされている方もいますが、それも間違っていて、少なくともバイナリを持ってる人はソースコードを見れなくてはいけません。
なので公開しない唯一の方法は、そもそもこれはヘッダのみの利用なのでLGPLによって公開する義務を持たないと言うしかないです。
ライセンスには詳しくないですが難しいことじゃないと思います
寄付を求めることが気に入らないという理由で反発する人が多いみたいですが、僕はVirtualPT気に入ってました。将来、社会情勢が変わってVirtualPTの開発を再開できる日が来るといいですね。
現在はメールで要求されても公開致しません。今後の当方の状況をお察しいただけますと幸いです。もしそれでもということであれば、しかるべき対応を取られても当方としては甘んじて受けざるを得ません。
また、ライセンスに詳しい方にお聞きしたいのですが、LGPLライセンスを要求されたソフトウェア内にあるインターフェース定義のヘッダーを使用したとしても、静的リンクや動的リンクしているわけではないので、ライセンスの対象外では無いのか？と考えるのですが、どうなのでしょうか？
当方の認識不足から、ご迷惑をお掛けしております。只今Vectorに公開停止申請をしておりますので、数日で停止されるものと思います。
GPLが何よりも優先するGPLキチガイ怖い怖いうざいうざい
ソースコードの公開について、今後の扱われ方の危険性を考えると、これ以上、当方としてはどうしても公開することが出来ません。それに異論はあるでしょうが、しかるべき処置を取っていただいて構いません。
GPLのソースコードの開示に関して、
・要求に応じて開示すればよい
・最低限著作権者に開示すればよい
と認識しておりましたが、ちょっと調べてみたのですが「最低限著作権者に開示すればよい」との条件を見つけることが出来ませんでした。ななし様のご指摘が正しいのかもしれません。そのように認識したのには理由があると思うのですが「頒布の差止やGPL違反是正を求める権利があるのはプログラムの著作権者だけである」との条件を勘違いしていたのかもしれません。
ただ、BonDriverインタフェースはLGPLを要求されたアプリケーション内に存在するのですが、BonDriverインタフェースを静的リンクも動的リンクもしているわけではないのでどう解釈して良いものか悩ましいのですが、これ以上調査するには長期間掛かる可能性があるので、速やかに公開停止する処置を取りたいと思います。また、BonDriver_VTPT.dllを非公開にすると、VirtualPT.exeだけでは存在意義がなくなるので、全てのバイナリの公開を停止いたします。
当方の理解不足のため、大変ご迷惑をお掛けいたしました。誠に申し訳ありませんでした。
確かにそうですね。配布してしまったものについて、バイナリの配布をやめようが、すでに入手してしまった人はソースコードを入手する権利をもつ、仰るとおりです。なので、domaさん、この先バイナリを配布しないのは貴方の自由ですが、ソースを配布しない権利はありません。速やかにソースを一般公開しましょう。わかっていると思いますが、配布したバイナリを作成した環境でビルドできるソースコードをそのまま提供しなければいけません。常識的にGPL部分とそれ以外は独立してビルドできるようにするものですが、もし配布した段階でのビルド環境が貴方がGPLではないと思っている部分にも依存性があるようならば、そのとき依存していたすべてを公開する義務がありますよ。あとから小細工してBondriver部分だけ分離するとか、ライセンス違反のなきように。
バイナリ配布をやめたからって、ソース配布をやめていいわけじゃないから。
バイナリを無条件にばらまいてしまったら、バイナリを手に入れた人が全員ソースを手に入れる権利を持つ。
都合によりバイナリの公開やめたとか個人の事情に関係なく、
過去に配布したものについてもライセンスはいつまでも有効。永遠に失効しない。
誤解する余地がないライセンスだと思うけど？
何をどう誤解したわけよ。
しかるべき方、公開義務のある方＝配布先
こんなの常識中の常識でしょ。
どこだと思ってたの？
これ以上、解説したくないのですが、「「既にダウンロード済みのバイナリは使わないで欲しい。」といったスタンス」のスタンスということで察していただけないでしょうか？
また、GPLライセンスについて当方の理解と違うのですが、もしななし様の言うことが正しいのであれば、速やかにバイナリの公開を停止いたします。どちらが正しいのでしょうか？
これを求めるのであれば、それなりの理由をご説明いただきたいところです。
理由は言えないでは少々納得がいきません。
事情はあるかもしれませんが、もう少し踏み込んでお話いただけませんか。
ソースの公開は、GPLライセンス上、「しかるべき方」にバイナリの利用者も含まれます。
なのでバイナリ公開期間中は今まで通りの対応お願いします。
厳しいことを言うかもしれませんが検討下さい。
当方の説明では、意味がわからないのも最もだと思います。「既にダウンロード済みのバイナリは使わないで欲しい。」というのは、詳しく説明できませんが察していただきたいと思います。また、9月中のバグ修正は、今すぐ終了するよりも喜んでいただけるとの考えからですのでご了承ください。
10月からバイナリは使わないでくれ、って言っていて
でも今月はバイナリの配布と修正は続ける、と言う。
ソースはでも一般公開しないと。
何がしたいん？
法改正に向けてやめるならバイナリもソースも配布をやめればいいし、
ぎりぎりまで続けたいなら10月になるまでソースもバイナリも公開し続ければいいだけのことでは？
当方の説明が不十分で誤解を与えてしまったようです。大変申し訳ありません。あくまで一般公開を停止するということで、公開義務がある方にまで公開しないという考えではありません。「ソースコードの公開終了」から「ソースコードの一般公開終了」に改めさせていただきます。
ソースコードに関しては、あくまで有効活用していただける方のみに公開していたもので、愛用者様やあ様の反応には当方としては戸惑いを感じております。BonDriverインターフェースがGPLライセンスであるので、該当箇所をしかるべき方への公開義務はあると考えていますが、以外の公開義務はそもそも無いものと考えております。
今回このように対応したことについて、今後の当方の取らざるを得ないスタンスを考えると多くを語ることは出来ませんので、その旨お察しいただけますようお願いいたします。「なぜ？」と疑問に思われている方が多くいらっしゃるのかもしれませんが、悪意はありませんのでご了承下さい。
また、あ様はバイナリを停止、ソースを公開が普通とのお考えのようですが、そういう方法もあるのかもしれませんが、バイナリの方を必要としている方が圧倒的に多いと考えておりますので、その考えには賛成しかねます。
バイナリの配布は止めないのに
ソースの配布を止めるのはおかしいですね。
普通は逆だと思います。
いままで重宝させていただいておりました。ありがとうございました。
できればソース公開停止は9月末までまってほしかったです。
残念です。
コメントする
2012年06月19日
※'12/6/24追記あり
※'12/7/12追記あり
※'12/7/14追記あり
バージョン1.11からアースソフト PT3でもご利用いただけるようになりました。もし、不具合等ありましたら、このページや要望・バグ報告のページでお知らせ下さい。
当方の環境では、アースソフトのサイトで公開されている「FPGA回路更新ツール」を適用しないとデバイスを認識できませんでした。もし、デバイスを認識できない場合は「FPGA回路更新ツール」の適用が必要な可能性があります。
'12/6/18時点では32ビットOS、もしくは、64ビットOS上の32ビット版VirtualPTでのみご利用いただけます。64ビットOS上で64ビット版VirtualPTを稼動するには、64ビット対応PT3 SDKがまだアースソフトから公開されていないため、まだご利用になれません。近い将来には公開されるものと思います。
【'12/6/24追記】
本日('12/6/24)、アースソフトから公開されたドライバーバージョン0.92、及び、SDKバージョン0.92で64ビットOS上の64ビット版VirtualPTでも動作することを確認しました。尚、このドライバーではWindows64bit署名問題対策ドライバが必要無いことも確認しました。
【'12/7/12追記】
アースソフトPT3 SDKバージョン0.96で追加された関数(デバイスとCPUのメモリアクセス関連を改善するための関数)に対応したVirtualPT ver1.15β1を公開しました。このバージョンは他の修正が無いため、Vectorでは公開せず仮ダウンロードサイトでのみ公開します。
【'12/7/12追記】
VirtualPT ver1.15β1で、TVTestが初回受信時に15秒程度操作不可になる現象が（選択されているデコーダ・レンダラ次第で）起きる場合がありましたが、改善したver1.15β2を公開しました（仮ダウンロードサイトのみ）。また、アースソフトPT3 SDKバージョン0.96で追加されたSyncBufferCpu関数を使用した場合と使用しない場合の違いを確認出来ない為、使用しないようにしました。（※使用しない場合、負荷は軽減される）
【'12/7/14追記】
アースソフトPT3 SDKバージョン0.96で追加された関数に正式対応したVirtualPT ver1.15を公開しました。
トラックバックURL
コメント一覧
ベクターは申請から公開までに数日掛かりますのでご了承下さい。尚、今回ベクターで公開されるまでの間、特別に仮ダウンロードサイトからもダウンロードできますので、お急ぎでしたらそちらをご利用下さい。詳しくは「VirtualPT ダウンロード・寄付」のページをご覧下さい。
コメントする
2012年05月16日
VirtualPTはこれまでアースソフトPT1・PT2でのみご利用頂けましたが、バージョン1.09からPlex PX-W3PEでもご利用いただけるようになりました。また、金銭的都合によりPX-W3PE一台での動作確認しかできていませんが、他のPlex PXシリーズ（PX-S3U、PX-S3U2、PX-W3U2、PX-W3U3）でも動作することを目標に作成しておりますので、それらの機種をお持ちの方はぜひ正常に使用できるかどうかをこのページのコメントでお知らせいただけると助かります。また、同じ種類のハードウェア複数台の同時使用が正常に稼動するかも、コメントいただけると助かります。
※各機種の内蔵ICカードリーダでのスクランブル解除には対応しておりません。他の外付けICカードリーダ（NTTComm SCR3310推奨）をご利用ください。
【動作確認状況】| デバイス名 | 1台使用時 | 複数台使用時 |
|---|---|---|
| PX-W3PE | ○ 実機で確認 ドライババージョン：BDA1.0.6 |
|
| PX-S3U | ○ 動作報告有り ドライババージョン：BDA1.0.2 |
|
| PX-S3U2 | ||
| PX-W3U2 | ○ 動作報告有り ドライババージョン：BDA1.0.1 |
|
| PX-W3U3 | ○ 動作報告有り ドライババージョン：BDA1.0.0 ACアダプタ有りで4チューナー、無しで2チューナーとして認識 |
○ 動作報告有り ドライババージョン：BDA1.0.0 |
PLEX PXシリーズの動作確認は継続して受付中です。PLEX PXシリーズをお使いの方は、ぜひ稼働状況をお知らせください。お知らせいただく際のテンプレートも掲載しますので、必要であればコピペしてお使いください。
■VirtualPTのバージョン：1.10(x86)
■PLEX PXのデバイス名：PX-W3PE×2台
■PLEX PXのドライババージョン：1.0.6(BDA driver)
■稼働状況：問題あり
■備考：1台では問題無いが、2台同時使用では○○○が出来ない
この度、Plex PXシリーズに対応するにあたり、技術資料やプログラムソース等が公開されていないため、PX-W3PE用BonDriver(公式版と呼ばれるもの)内のInterface_W3PE.dll、及び、BonDriver_PX_series内の各BonDriverの内部解析を行いました。いづれも作者不明のため無断で解析しましたが、クレーム等があった場合、この機能の公開を停止するかもしれないことをご了承ください。作者の方はもし問題ありましたらご連絡をお願いします。
今回調査用にPlex PX-W3PEを入手した直後にアースソフトPT3の発売予定がアナウンスされました。ロープロファイル＆PCI-ExpressということでPlex PX-W3PEと同等な仕様と思われます。こちらはSDK等の公開が見込まれるため開発の敷居がかなり低いのに対して、Plex PX-W3PEはかなり大変な作業になることが予想されました。Plex PXシリーズの対応はあきらめようかとも思いましたが、なけなしのお金でせっかく購入したのだし、Plex PXシリーズに対応することでUSB接続のデバイスからも利用可能になることから、そのまま作業を続け、無事に対応することが出来ましたが、はたして、今後の主流はどうなっていくのでしょうか？
トラックバックURL
コメント一覧
USB接続は幅広い機種に対応出ることが魅力だと思うのですが、そう言った点では注意が必要なのかもしれませんね。ちなみにVirtualPTでは、サービスプログラム形式を採用していることもあり、デバイスの状況をリアルタイムに監視しております。例えば、USB機器が接続されれば直後から利用対象になりますし、逆にUSB機器が切断されればその機器の使用を止め別の機器で代替しようとします。（PCIやPCI-Eではあまり関係ないかもしれませんが、DevCon等で接続・切断すればUSBと同様に動作します。）なのでUSB機器が切断されたと判断されその機器の使用を行わなくなったものと思われます。
もし、現象発生時にイベントログが出力されているようであれば、そのイベントに対応したリカバリータスクをタスクスケジュラーに登録することで、被害は最低限で済むかもしれません。（リカバリータスクにはDevConで対象デバイスのリセットを行うバッチ。もしかしたら回復出来るかもしれません）
どうやらいつの間にかOSからW3U2,W3U3が見えなくなうようです（特にスリープなどの設定はしていません）。その際にチューナーを使用しようとすると凡ドラではブルスクになるようです。VPTのドライバでは見失ったままにはなりますがOSごと落ちることはないようです（見失ったままなので録画はできませんが）。ブルスクが発生するとEDCBの設定が駄目になることが多かったので、それだけでも助かっています。
情報提供頂き誠にありがとうございます。今のところ問題無いとのこと、当方としてもうれしいです。
【ドライバ】公式BDAドライバVer.1.0.0 ＆ 公式BDAドライバVer.1.0.1
【カードリーダ】Gemalto
【OS】Windows 7 Home 64bit SP1
【VGA】Apsire Revo onboard
【使用ソフト】EDCB 9.46
【TV受信環境】CATV・地デジパススルー・4分配
【VirtualPTのバージョン】：1.15(x64)
稼働状況：問題なし(今のところ）
以前はチューナーの優先順位を W3U2-T0,W3U2-T1, W3U3-T0,W3U3-T1,W3U3-T2,W3U3-T3 で使用してました。最初は問題無かったのですが、そのうちブルスクが発生するようになりました。チューナー使用２つまでのはOKなのですが、３つめになるとW3U3のドライバエラーでブルスク発生。USBの抜き差しで一旦は収まるが１日くらいで再発。再起動の嵐となります。繋ぐUSBポートを本体やセルフパワーハブのいろいろなポートで試すが状況は変わらず、困っていました。試しにこのVirtualPTを使って設定してみたら、いまのところは安定動作しているようです（チューナーの使用順位はわかりませんが）。 しばらく様子見してみます。ブルスクに困っているひとは試してみてください。vectorにてdoateしました。
PLEX関係の動作状況が希薄なので、お知らせいただけると大変ありがたいです。大変感謝しております。
■PLEX PXのデバイス名：PX-W3U3
■PLEX PXのドライババージョン：1.0.0(BDA driver)
■稼働状況：問題なし
■備考：
PT3x2枚+PX-W3U3x1台で運用中。
PX-W3U3の地デジ/BS/CSチューナセットの１セットをVirtualPT+EpgTimer(v10.66 x64)で、もう１セットはPX-W3U3専用BonDriver+TVTestで使用中。
前者は録画用。後者は視聴用です。
今のところは特に問題は見当たりません。
どうでもいい話ですが、ACアダプタつながないと(USBバスパワーだけで動かすと)、地デジ/BS/CSチューナセットが１つしか見えませんで、最初は壊れたのかと焦りました・・・。
備考の件ですが、PX-S3Uは他のデバイスのように地デジと衛星のそれぞれ別に受信できるわけでなく、地デジと衛星の中から１つしか同時に受信できないと認識しております。ですので、それで当方の想定どおりの動作なのですが、実機で確認したわけではないので、もし当方の誤解などありましたら指摘していただけると助かります。
■PLEX PXのデバイス名：PX-S3U 1台
■PLEX PXのドライババージョン：1.0.2(BDA driver)
■ＴＶＴＥＳＴのバージョン：0723
■稼働状況：問題無
■備考：チューナーが１台のため、
ネットワークで共有すると、
最初に起動したＴＶＴＥＳＴしか、
チャンネル切り替えが有効に
ならない。
（同一チャンネルしか見れない）
コメントする
2012年02月10日
このページのベータ版の検証結果を元に改善したバージョン1.08を公開しました。こちらのページのベータ版の公開は終了いたします。ご確認いただいた方には、この場をお借りしてお礼申し上げます。大変ありがとうございました。
これまで送信側と受信側とで同期を取りながら通信していましたが、バージョン1.08では同期を取らずに通信する機能も実装しました。これにより問題無く動作していた環境ではこれまでどおり通信し、問題が発生していた環境では状況に応じて同期を取らない通信も織り交ぜて通信することで、改善するものと考えております。
もし、「新しいバージョンでも改善しない」、「これまで問題なかったのに新しいバージョンではうまく動かなくなった」等ありましたら、このページや要望・バグ報告のページでお知らせ下さい。また、これまで問題があった方で新しいバージョンで改善された場合も、お知らせいただけると大変助かります。
β3とβ4も追加しましたので、こちらも確認後、動作したかコメントでお知らせください。
数名の方からご指摘いただいているネットワーク通信の不具合の件ですが、いまだ当方では現象を再現できていないのですが、もしかしたら直るかもしれない修正をしたバージョンを作成しましたので、もしネットワーク通信で不具合が出ている方は、ぜひ試してみて下さい。2バージョン作成しましたので、それぞれ確認後、動作したかどうかこのページにコメントでお知らせ下さい。
※あくまで確認用のバージョンですので本番稼動では使用しないで下さい。
VirtualPTのベータバージョンを下記からダウンロードして下さい。
VirtualPT 1.08β1
VirtualPT 1.08β2
VirtualPT 1.08β3
VirtualPT 1.08β4
上記のファイルをダウンロード＆解凍し、既にインストール済みのVirtualPTのサービスを停止後、VirtualPT.exeを入れ替えし、サービスを起動してください。
VirtualPT_VTPT.dllも全て入れ替えてください。
トラックバックURL
コメント一覧
また何かありましたら、ご遠慮無くお問合せ下さい。
VirtualPTの設定もエラー時の状態に設定しましたが
エラーが出ませんでした
お騒がせしてすいません
VirtualPTの問題ではなく
メインPCのハード的欠陥（メインメモリー不良）による不具合の可能性が大きいです。
VirtualPTとネット接続によるTV視聴のエラーと成功との間にメインメモリの交換を行っていた事を失念していました。
お騒がせしました。
当方で確認したところ、リモート接続の場合、TVTestのチャンネルスキャン(地デジ)が成功しづらくなっていることを確認しました(チャンネル切り替え後の待ち時間に1秒を指定すると失敗、2秒を指定すると成功)。ただ、きんた様の現象とはおそらく違うと思います。他にはRecvPrivateの設定によってTV視聴が出来ない現象は確認できませんでした。
もう少し詳しく教えていただきたいのですが、RecvPrivate=0ならTV視聴が出来たとのことですが、BonDriver_VRPT-T.ini内のRecvPrivateを=1に変更してTVTestを再起動していただき、再度現象がでるかご確認いただけないでしょうか？その際、全ての地デジチャンネルが視聴できないのかどうか、視聴できないチャンネルは全く駄目なのか、途中から駄目になるのか、及び、使用中のTVTestのバージョンも教えてください。
お手数をお掛けしますがよろしくお願いいたします。
BonDriver_VRPT-T.dll (1.8.149.15) 注.ファイ命は適当、VRPT関係DLLはこれのみ名前を変えても変化も問題もなし
BonDriver_VRPT-T.ini 内容
-------------------------------------------
[SETTING]
HostName="192.168.0.100:12300"
Priority=0
UHFValid=1
CATVValid=0
VHFValid=0
BSValid=0
CSValid=0
ChannelMode=1
Descramble=1
RecvNULL=
RecvDuplicate=
RecvError=
RecvUnknown=
RecvDigitalTV=1
RecvOneSeg=
RecvOtherService=
RecvPrivate=
RecvLow=
RecvOtherStream=
-------------------------------------------
PT2専用録画PC WIN7 HOME 32bit PT1x1,PT2x1 (地上波のみ)
メインPC WIN7 Pro 64bit
ルーター経由の有線LAN接続(1Gbps)
VirtualPT 1.8.537.15
設定
----------------------------------------------------
[GENERAL]
UHFValid=1
CATVValid=1
VHFValid=1
BSValid=1
CSValid=1
AutoChannelScan=1
SharememValid=1
SocketValid=1
SocketPort=12300
CATVFrequency=0
WaitPowerResume=2
[CAS]
ReaderSearch=2
ReaderList=
ECM=1
EMM=0
EMMMessage=0
[EARTHPT]
LnbPower=0
DMASize=2
GrayOff=0
UseOldSDK=0
S1Valid=0
S1Priority=0
T1Valid=1
T1Priority=0
S2Valid=0
S2Priority=0
T2Valid=1
T2Priority=0
[EARTHPT_DEVICE2/0/1]
Setting=0
LnbPower=0
DMASize=2
GrayOff=0
UseOldSDK=0
S1Valid=1
S1Priority=0
T1Valid=1
T1Priority=0
S2Valid=1
S2Priority=0
T2Valid=1
T2Priority=0
[EARTHPT_DEVICE2/2/2]
Setting=0
LnbPower=0
DMASize=2
GrayOff=0
S1Valid=1
S1Priority=0
T1Valid=1
T1Priority=0
S2Valid=1
S2Priority=0
T2Valid=1
T2Priority=0
[BONDRIVER]
Priority=0
UHFValid=1
CATVValid=0
VHFValid=0
BSValid=0
CSValid=0
ChannelMode=1
Descramble=1
RecvNULL=0
RecvDuplicate=0
RecvError=0
RecvUnknown=0
RecvDigitalTV=1
RecvOneSeg=0
RecvOtherService=0
RecvPrivate=0
RecvLow=0
RecvOtherStream=0
----------------------------------------------------
こちらでも念のため確認したい為、以下の内容を教えてもらえないでしょうか？
1.VirtualPTのバージョン
VirtualPT.exeを右クリック→プロパティ→詳細タブで確認できます。
2.VirtualPTの設定
VirtualPT.exeのあるフォルダのVirtualPT.iniの内容
3.BonDriver_VTPTのバージョン
BonDriver_VTPT_T.dllを右クリック→プロパティ→詳細タブで確認できます。
4.BonDriver_VTPTの設定内容
BonDriver_VTPT_T.dllのあるフォルダのBonDriver_VTPT_T.iniの内容
※改善前と改善後の両方をお知らせ下さい。
後、TV視聴の場合、1つのBonDriverで地デジと衛星の両方受信した方が便利かと思うのですが、地デジと衛星とを別のBonDriver(BonDriver_VTPT_T.dllとBonDriver_VTPT_S.dll)に分けて設定されていますか？
BonDriver_VRPT-T.iniの内容は
HostName="192.168.0.100:12300"
この部分の指定が間違っていると思っていました。
VirtualPT設定のBonDriver既定値を一部変更後無事ネット経由でのTV放送視聴が出来ました。
RecvPrivate=1 -> 0
：プライベートデータストリーム。字幕データ等
理由はわかりませんがTV映像と音声のみをBonDriver_VRPTで受け取るのがよろしい様でした。
素晴らしいものを作っていただいてありがとうございます。
わずかですが支払い手続きをしてきます。
この度はTCPの件、詳しく解説頂き誠にありがとうございました。今回の修正とは直接関係有りませんでしたが、当方で現象を再現できない難しい状況の中でモチベーションを保てたという点では、通りすがりのSE様のおかげと感じております。この場を借りてお礼申し上げます。
サイトについては、現時点で修正の予定はありませんが、今後の課題として参考にさせていただきます。
お役に立てたのでしたら光栄です。
# 何度もしつこく書いて申し訳ありませんでした・・・(^^;
対策版をリリースとのことですが、もしかしてみんな気づいていないのでは
ないでしょうか？
私も左側の「最新記事」と「最新コメント」ばかり確認していたので、
この記事の追加部分に数日気がつきませんでした。
こんなのは私だけかもしれませんが、新しい記事とかコメントとかも
書いていただけると、RSS登録していない人にもわかりやすくてうれしいです。
私も慌ててRSS登録しましたw
ところで、コメントのRSSって無くなってしまったのでしょうか？・・・ライブドアブログ・・・
TCPの件、大変勉強になります。私の考えが多分に古い知識であることが思い知らされました。特にリトライし続けることは、これまでの考えでは対処しきれない現象につながることに気が付きました。大変親切にご教授頂き誠にありがとうございます。
基本的にTCP自体としては、データの欠損は発生しません。
（欠損しない事がプロトコル上保証されています）
その代わり到着時間が保証されていません。
届くまでずっとリトライします。
これ以外の結末はセッションの終了（受け側や送信側のアプリが
無通信時間を計測し自発的にcloseするか、もしくはNW機器や
プロトコルスタックが処理を続行できなくなってRSTによる異常終了）
しかありません。
つまり、そのフレームを送るかセッションを切るかしかありません。
これにより、途中のデータが欠損したり、追い越しが発生しないように
なっています。
データの化けはCRCによって検知され単純にそのフレームが破棄されます。
（フレーム欠損と同じ扱いになります）
混同されがちなのですが、プロトコルスタックにデータを渡す（受け取る）際の
やり方が正しくない事が原因の不具合が多いです。
これはTCP以前の問題でAPIの呼び出し方の問題です。
ネットワーク通信は生もので、相手や回線の状態も刻一刻と変わります。
そのため約束事が多く、またOSやアプリの高度化に伴いOverlapped I/Oの
ようなちょっと複雑なやり方が増えてきたのが要因かと思います。
> ちなみに、VirtualPTでは共有メモリを通した通信にも、再送機能を実装しています。
> さすがに、こちらの機能が働くことは無いと考えていますが！
そうですね。
NW用と同じ共通ロジックを使っているとか、ロジックの不具合でデータが
破壊された事を検知できるようにチェックをしている方もいらっしゃいますよね。
メモリ自体についても、0か1かで言えば、メモリのビット化けはあり得ますが、
ECCが付いていないPCでは検知すらできませんし、メモリ上にある命令群が
正しい保証もないですし、難しいところではありますが・・・。
デバッグログの件ですが、当方が自分用に使用しているものはデバッグログ機能を有しているのですが、一般公開しているものは、それをOFFにしたものを公開しております。もし次のバージョンでも改善しない場合は、デバッグログ機能がONのバージョンの公開も検討したいと思います。
TCPパケットの欠落の件ですが、私もこの場合に欠落するというような確実な事例を認識しているわけではないのですが、これまでの経験則で、通信処理を行う場合、送信したデータが必ず受信側に届くわけではないという前提の下に開発を行ってきました。TCPでもリカバリー機能を持っていたとしても全ての事例をカバーできるわけではないといった考えです。そのへんどうなのでしょうか？TCPではそこまで考慮する必要は無いのでしょうか？
ちなみに、VirtualPTでは共有メモリを通した通信にも、再送機能を実装しています。さすがに、こちらの機能が働くことは無いと考えていますが！
失礼しました。
確かにOverlapped I/OのWSAsendは全サイズ渡した後に処理完了です。
ここまで来るとロジックとかも絡んでくるので、デバッグ用にログを出力してしまうのが
早いかもしれませんね。
・APIのエラー（API名，エラーコード，データ）
・受信判定のNG（判定NG理由，受信データ，組み立てバッファの内容等々）
・応答返信データのタイムアウト（直前に送ったデータ等々）
・再送の実施（送り直したデータ等々）
動きが見えれば解析しやすいと思いますし・・・
正常ルート時には何も出力しないようにすればパフォーマンス等への影響も少ないでしょう。
事象が発生しているユーザーさんの中にwireshark使える人がいれば、
通信内容をキャプチャーしてもらうとより良いと思います。
> TCPプロトコル自体に再送機能があることは認識しているのですが、パケットの欠落は
> 発生しえると認識しております。
との事ですが、確かに物理層とかでフレームが欠損する事がありますが、TCPレイヤで
シーケンス番号により検知＆再送されますので、アプリレベルで対応というのはあまり
体験した事も聞いた事がないのですが・・・
どのような場合に発生するのでしょうか？
後学のために教えてください。
似たような話で、データ化けしたときにCRCチェックをすり抜ける可能性がごく僅かでも
あるので、アプリ側でもCRCやハッシュでチェックすべきだという話は聞いた事があります。
なお、先日公開したベータバージョンの検証から、VirtualPTではストリームデータ(放送データ)を送信した場合、1ブロック毎にデータ受信状況を知らせる返信を待つのですが(ストリームデータの欠落、応答返信データの欠落も考えられますので単純に待っている訳では有りませんが)、この応答が当方の想定時間(最も負荷が高いであろうBSハイビジョン放送の場合で13ms)以内に来ないと、データを掃けきれなくなります。恐らく環境によって返信応答が当方の想定以上に掛かっていることが問題点ではないかと考えております。
先日検証頂いた方の返信に、今までの方法・改善した方法を選択できるような修正をするようなコメントをしたのですが、現在、返信応答が想定以上に掛かっているか自動で判別し改善した手段に自動で切り替わるようなバージョンを作成中です。このバージョンで、これまで問題なかった方はこれまでどおり、問題が起きていた方のみに修正したコードが働き(再送機能は働かないが)、不具合が改善されるのではないかと考えております。まもなく公開できると思います。
setsockoptの件、もしそこに問題があるのであれば現象が直ぐに発生すると思います。数十秒は問題ないことから今回の不具合とは関係ないのではと思います。もし新しいバージョンでも改善しない場合、その辺の調査ベータを作成してみようと思います。
>それと、ネットワーク越しの録画、私はやるかも・・・・(^^;
大変貴重なご意見ありがとうございます。参考にさせていただきます。
- 1/2ページ -
TCPプロトコル自体に再送機能があることは認識しているのですが、パケットの欠落は発生しえると認識しております。なのでVirtualPTでの再送機能は全く不必要な物とは言えないと思います。
今回送信側の修正点としてご指摘頂いた、送信時に一部だけが受付けられる場合の対処法ですが、当方の処理ではオーバーラップ化ソケットを使用しておりましたので、「全てのデータを受付けた」、「全てのデータの受付が即座に完了しなかったので、完了したらイベントをセットして知らせる」、「その他のエラー」といった状態しか発生せず、一部だけが受付けられたといった状態は発生しない事が分かりました。その辺のことを直ぐに明確に回答できれば良かったのですが、1年以上前に書いたコードで記憶があいまいになっていたこともあり、何度もご心配をお掛けしてしまい申し訳ありませんでした。大変感謝しております。
受信側の修正点としてご指摘頂いた点は、既にそのようになっております。
くどいようで申し訳ありませんが、もう一度書き込みさせてください。
TCPの場合、再送処理自体は下位レイヤーが行いますので、アプリ側で
再送する必要はありません。
ですので、送信バッファに送れたものは（下位レイヤーが再送含めて
処理してくれるので）相手側にも届くと考え、
「続きから送信する」のが基本的な処理の仕方になります。
また、受信側は続きが後から来るかもしれないので、所定のサイズを
受け取るまで待つ必要があります。
以前書き込みしていただいたプロトコル＆処理なのであれば、下記2ヶ所を
修正していただければ改善されるものと思います。
送信側：送信バッファに全部を受け取ってもらえなかったときに、
：丸ごと再送するのではなく、受け取ってもらえなかった残りだけを
：再度送るようにします。
：またWSASendの一回の呼び出しで送る最大データサイズが判っているなら
：setsockoptでソケット送信バッファ（一番アプリよりの送信バッファ）
：のサイズをこの最大サイズ＋1Byte以上に設定すると効率がよくなります。
：大きすぎるサイズを指定するとエラーになりますが・・・。
受信側：データ終端の区切り文字が受信されるまで待つ（受信し続ける）
ネットワーク上での再送は下位レイヤーに任せ、シンプルに窓口である
送信バッファにきちんと重複や欠損なく渡す事だけを考えれば、問題なく
送信できると思います。
それと、ネットワーク越しの録画、私はやるかも・・・・(^^;
β2で最も改善したとのことですが、そのバージョンは、通信エラー時の再送機能を無効にする代わりに、回線をもっと効率よく使用するように改善したものです。
コメント頂いた方々は皆、有線LANであったことから、当方の無線LAN(実効帯域24Mbps)環境でも問題なく使用できていたので、有線では帯域不足はまず無いだろうと考えておりましたが、検証頂いた結果から推察すると、VirtualPTのやり方では帯域を効率的に使用できずに帯域不足状態となる場合があるように思われます。
TCP-IP経由で使う場合、おそらく視聴のみで録画で使用することはまず無いであろとすると、多少のドロップはある程度許容できるものと考えられます。なので、β2の機能もオプションで選択出来るようにしたバージョンをリリースしたいと思います。
ただ、β2はあくまで簡易に修正したものですので、もしかしたら正式リリースの前に再度ベータを公開する可能性がありますのでご了承下さい。
VirtualPT 1.08β1 →×：ビットレート低下変わらず
VirtualPT 1.08β2 →△：他より大きく改善。しかしたまにコマ落ちする。
VirtualPT 1.08β3 →×：ビットレート低下変わらず
VirtualPT 1.08β4 →×：ビットレート低下するが1,3よりはマシ
以下、環境
Server側
OS:Windows2008R2 Enterpirse
VirtualPT x64 + TvRock 32bit + BonDriver 32bit + TvTest 32bit
Client側視聴環境
OS:Windows7 Enterprise (64bit)
TvTest 32bit + BonDriver 32bit
ということでβ2が一番実用に耐えました。
他よりビットレートの低下が発生する確率が大分減りましたが、
やはりコマ落ちが発生します。
正式版、他のβ版と比べてコマ落ちがずっと続くというわけではないので、
なんとか視聴できる状態でした。
録画は問題無いので、現在は正式公開版に戻しました。
不具合の参考になれば幸いです。
コメントする
2011年06月07日
VirtualPT ver1.05まではチャンネル拡張モードがTvRockで正しく動作しませんでしたが、ver1.06でTvRock DTVターゲットに対応したチャンネル拡張モードBを追加しました。
それぞれのチャンネルモードでトランスポートストリームの構成がどのようになるのか簡単に図示すると以下のようになります。
| 例）チャンネル互換モード | |||||
|---|---|---|---|---|---|
|
WOWOW1 WOWOW2 WOWOW3 ※共通のチャンネル |
|
||||
| 例）チャンネル拡張モード | |||||
| WOWOW1 |
|
||||
| WOWOW2 |
|
||||
| WOWOW3 |
|
||||
| 例）チャンネル拡張モードB(TvRock DTVターゲット用) | |||||
| WOWOW1 |
|
||||
| WOWOW2 |
|
||||
| WOWOW3 |
|
||||
チャンネル互換モード(他のBonDriverと同じ動作)では1つのトランスポートストリーム内に複数のチャンネル（サービス）が存在します。この状態では、視聴・録画ソフトで必要としているチャンネル（サービス）がVirtualPT側ではWOWOW1なのかWOWOW2なのかWOWOW3なのか分からないので、スクランブル解除をVirtualPT側で行う場合、全てをスクランブル解除することしか出来ません。それを改善するチャンネル拡張モードでは、指定されたチャンネル(BonDriverチャンネルインデックス)で必要とするチャンネルがWOWOW1なのかWOWOW2なのかWOWOW3なのかが分かるので、複数のチャンネル（サービス）が含まれるトランスポートストリームを再編成し１つのチャンネル（サービス）だけが含まれるトランスポートストリームに仮想化します。
この時、トランスポートストリームを識別するＩＤも再割当て(上図ではトランスポートストリーム2をそれぞれTS2-1、TS2-2、TS2-3に変換)します。これによりネットワーク全体で見てもトランスポートストリーム群の矛盾が発生しないので、視聴・録画ソフト側の(プログラム的な)変更無しに動作することが期待できます。
しかし、TvRock関連のソフトではチャンネル拡張モードで正しく動作しないことが分かりました。おそらくトランスポートストリームを識別するＩＤを変更している為ではないかと思われます。そこで、TvRock関連のソフトに対応する為に、トランスポートストリームの基本構成は変更せずに不必要なチャンネル（サービス）の映像・音声だけを破棄する、新しい拡張モード(チャンネル拡張モードB)を追加することにしました。ネットワーク全体で見ると同じトランスポートストリームが複数箇所に存在(上図ではトランスポートストリーム2が3個存在)し矛盾が発生しますが、データ自体は互換モードと近いものとなっています。
TvRockと連係する視聴・録画プログラムとして、TvRock DTVターゲットモードで動作するTVTestやRecTestを利用できますが、残念ながらRecTest(ver0.3.1時点では)はBonDriver内部チャンネル番号(BonDriverチャンネルインデックス)をプログラム固定で定義している為、拡張モードでは正しく動作しません。録画プログラムにはTVTestを/nodshowオプション指定で使用してください。詳しくはTvRockOnTVTestの説明ファイルを参照してください。※どうしてもRecTestを使用したい場合、「どうしてもRecTestを使用したい場合」を参照してください。
拡張モードBを使用するにはBonDriver_VTPT.dllの設定ファイルに「ChannelMode=3」を設定するか、設定ファイルは未設定(ChannelMode=空白)にし、VirtualPT設定の「BonDriver既定値＞チャンネルモード」を「拡張モードB(TvRock DTV Target用)」を設定してください。
チャンネル互換モードは内部チャンネル番号(BonDriverチャンネルインデックス)が0から始まります。チャンネル拡張モード(B)は内部チャンネル番号(BonDriverチャンネルインデックス)が1から始まります。なので、TvRockチャンネル番号も1つずれます（拡張チャンネルの方が+1です）のでご注意ください。地デジでは拡張モードを使うことで何かメリットがあるわけではないので互換モードを使用した方が無難かもしれません。
2011年05月21日
視聴・録画ソフトで指定されたチャンネルは、地デジのチャンネルでは周波数に変換しています。BS・CS(チャンネル互換モード)では周波数とTSIDに変換しており、BS・CS(チャンネル拡張モード)では周波数・TSID・サービスIDに変換しています。周波数は基本的に変わらないものですが、TSID(トランスポートストリームを識別する番号)とサービスID(チャンネル(サービス)を識別する番号)は頻繁ではないものの変更される可能性のある番号です。
ちなみに2011年10月1日(頃？)にBS・CSのチャンネル編成の変更(WOWOW3チャンネルのハイビジョン化、CSの一部のチャンネルがBSに移動、グリーンチャンネル等の追加)が予定されており、新たなTSIDの追加等が行われるものと思われます。この際VirtualPTだけでなく他のBonDriverでも変更の反映が必要となるでしょう。また、このようなTSIDの追加や削除は滅多にありませんが、TSIDの追加や削除は無いもののチャンネル(サービス)の追加・削除が行われることもあります。この際にはチャンネル拡張モードで変更の反映が必要になります。
VirtualPTでは、これらの変更を反映する為にプログラム自体を変更しなくても、チャンネルスキャンを行うことで最新の状況に対応します。
チャンネル互換モードでは周波数・TSID順に内部チャンネル番号が採番されており、チャンネルスキャンでの変更を反映する際にも周波数・TSID順に内部チャンネル番号を採番しなおします。現状、基本的に全てのBonDriverがこの法則で採番していると思われますが、今後予想される変更に対応する際に、他のBonDriverがこの法則どうりの対応がされるとは限りませんし、ともすると各BonDriverで違う対応となるかもしれません。チャンネル互換モードでもこの点では互換とならないかもしれないことをご了承お願いします。
チャンネルスキャンは自動で行うものと手動で行うものがあり、自動チャンネルスキャンは設定ダイアログでONにしておけば、あとは勝手にチャンネルスキャンが行われます。手動チャンネルスキャンはメニューからチャンネルスキャンダイアログを開きユーザーの操作の元で実行します。チャンネル拡張モード用のチャンネルスキャンは自動・手動の両方が可能ですが、チャンネル互換モード用のチャンネルスキャンは手動のみが可能です。
自動チャンネルスキャンが実行される条件としては、基本的には前回実行から24時間が経過した場合ですが、視聴・録画ソフトが受信するデータも監視しており、チャンネルスキャンの必要があると判断した場合にも実行されます。ただし、使用中のチューナーが1つでもあれば、全てのチューナーが未使用になるまでは実行しません。
チャンネル互換モードで自動チャンネルスキャンが出来ない理由は、チャンネルスキャンの前後でBonDriver内部チャンネル番号の互換性が無い為です。例えば、視聴・録画ソフト側でスター・チャンネルの内部チャンネル番号は5だと認識していたのに、チャンネルスキャンの後は内部チャンネル番号5がWOWOWになっていたということが起こりえます。なのでチャンネルスキャン後に、視聴・録画ソフトのチャンネルスキャン、予約録画のやり直し、自動予約の再設定、視聴・録画ソフトによっては設定の初期化からやり直す必要があるので、ユーザーがこれらの操作を行うという意思のもとに実行する必要があるからです。
チャンネル拡張モードでは、チャンネルスキャンの前後でBonDriver内部チャンネル番号の互換性が保たれる為、変更があったとしても視聴・録画ソフトはそのままでも正常に動作します。ただし、そのままでは追加されたチャンネル等が認識されない為、視聴・録画ソフト側でそれを認識する為のチャンネルスキャンは必要となります。
チャンネルスキャン方法
インストールしたVirtualPT.exeを起動して、画面右下のタスクトレイにVirtualPTアイコンを表示します。起動から5秒間ピコピコ点滅しているものがVirtualPTアイコンです。
VirtualPTアイコンをクリックしてメニューを開き、「チャンネルスキャン」を選択します。
チャンネルスキャンダイアログが表示されますので、「チャンネルスキャン開始」ボタンをクリックしてください。
チャンネルスキャン開始確認メッセージが表示されますので、「はい」をクリックしてください。
チャンネルスキャン状況が表示され、通常1分程度でチャンネルスキャンが完了します。チャンネルスキャン終了確認メッセージが表示されますので、「ＯＫ」をクリックしてください。この時点で拡張モード用チャンネルの変更は反映されていますが、互換モード用チャンネルは変更の有無をチェックするだけで変更の反映はされていません。
互換モード用チャンネルに変更が有る場合、「互換モードチャンネル登録」ボタンが有効になります。互換モードチャンネルの変更を反映する場合、「互換モードチャンネル登録」ボタンをクリックしてください。※互換モード用チャンネルに変更が無い場合は、「互換モードチャンネル登録」ボタンが無効化されておりクリックできません。
互換モードチャンネル登録確認メッセージが表示されますので、「はい」をクリックしてください。
互換モードチャンネル登録が完了すると、互換モードチャンネル登録完了メッセージが表示されますので、「ＯＫ」をクリックしてください。
チャンネル一覧
チャンネルスキャンダイアログで最新チャンネルの一覧が確認できます。
- １）チャンネルモードタブ
- 「互換モードチャンネル一覧」、「拡張モードチャンネル一覧」タブでチャンネル一覧を表示するチャンネルモードを選択します。
- ２）チューニング空間タブ
- 「UHF」、「CATV」、「VHF」、「BS」、「CS」からチャンネル一覧を表示するチューニング空間を選択します。
- ３）項目名
- 項目名をクリックするとその項目名で一覧が並べ替えられます。SVCをクリックするとサービスID順に表示されますし、更新日時をクリックすると最後に変更されたものから順に表示されます。
- ４）チャンネル一覧リスト
- 最新のチャンネル一覧が表示されます。
- ５）TVTest用プリセットファイル作成ボタン
- 最新のチャンネル情報でTVTest用のプリセットファイルを作成します。作成したファイルはTVTestのチャンネルスキャンで取込むことが可能です。チャンネルモード(互換モード・拡張モード・拡張モードB)別にそれぞれBS用、CS用の6種類を作成することが可能です。
- ６）TvRock用デフォルトチャンネル設定作成ボタン
- 最新のチャンネル情報でTvRock用のデフォルトチャンネル設定ファイルを作成します。作成したファイル(多少の編集が必要)をTvRock作業フォルダに入れてDTune.batを実行することで最新のチャンネル情報を取込むことが可能です。BS用、CS用の2種類を作成することが可能です。互換モード・拡張モードで内容に違いはありません。
TVTest用プリセットファイル作成
「互換モードチャンネル一覧」タブ内の「BS」タブ内に「互換モード・BS」用、「CS」タブ内に「互換モード・CS」用の作成ボタンがあります。「拡張モードチャンネル一覧」タブ内の「BS」タブ内に「拡張モード・BS」用、「拡張モードB・BS用」、「CS」タブ内に「拡張モード・CS」用、「拡張モードB・CS用」の作成ボタンがあります。作成したいファイルに対応するボタンをクリックします。
ファイル名指定ダイアログが表示されますので、フォルダとファイル名を指定し「保存」ボタンをクリックします。
TVTest用プリセットファイル作成が完了すると、作成完了メッセージが表示されますので、「ＯＫ」をクリックしてください。
作成したファイルはTVTestのチャンネルスキャンで取込むことが可能です。
TvRock用デフォルトチャンネル設定ファイル作成
「互換モードチャンネル一覧」、又は、「拡張モードチャンネル一覧」タブ内の「BS」タブ内に「BS」用の作成ボタン、「CS」タブ内に「CS」用の作成ボタンがあります。作成したいファイルに対応するボタンをクリックします。「互換モードチャンネル一覧」タブ内の作成ボタンから作成しても、「拡張モードチャンネル一覧」タブ内の作成ボタンから作成しても同じ内容のものが作成されます。
ファイル名指定ダイアログが表示されますので、フォルダとファイル名を指定し「保存」ボタンをクリックします。
TvRock用デフォルトチャンネル設定ファイルの作成が完了すると、作成完了メッセージが表示されますので、「ＯＫ」をクリックしてください。
作成したファイル(多少の編集が必要)をTvRockの設定フォルダに入れてDTune.batを実行することで最新のチャンネル情報を取込むことが可能です。
2011年04月01日
「スクランブル解除について」でも説明したように、BonDriverの内部チャンネル番号はトランスポートストリーム単位で採番されています。これをVirtualPTでは「チャンネル互換モード」と呼びます。このモードではVirtualPT側でスクランブル解除すると無駄が生ずるため、新たに内部チャンネル番号をチャンネル(サービス)単位で採番しスクランブル解除の無駄を無くします。これを「チャンネル拡張モード」とします。
※VirtualPT ver1.05まではチャンネル拡張モードがTvRockで正しく動作しませんでしたが、ver1.06でTvRock DTVターゲットに対応したチャンネル拡張モードBを追加しました。拡張モードBについて詳しくは「チャンネル拡張モードBについて」を参照して下さい。
チャンネル拡張モードでは内部チャンネル番号をチャンネル(サービス)単位で採番しますが、それに伴い、トランスポートストリームを下図のように、あたかも1つのチャンネル(サービス)だけを含んでいるかのように仮想化します。このようにすることで、視聴・録画ソフトの(プログラム的な)変更無しにどちらのチャンネルモードでも動作することが期待できます。また、どちらのチャンネルモードを使用するかは、視聴・録画ソフトごと(正確にはBonDriver単位)に設定できます。
例）チャンネル互換モード|
トランスポートストリーム1
|
トランスポートストリーム2
|
例）チャンネル拡張モード
|
TS1-1
|
TS1-2
|
TS2-1
|
TS2-2
|
TS2-3
|
この新しいチャンネルモードの主目的は、トランスポートストリーム内の不必要なチャンネル(サービス)を除外することで、除外したチャンネル(サービス)のECM処理(鍵情報の暗号化解除処理)を無くすことです。ただし、このメリットの効果が発揮されるのは、トランスポートストリーム内に複数のチャンネル(サービス)が存在し、それぞれが独自のECMデータを持っている場合です。これに該当するのはBSのWOWOW1・WOWOW2・WOWOW3とCSの有料放送のみです。その他はトランスポートストリーム内に1つのチャンネル(サービス)しか存在していないもの、複数のチャンネル(サービス)が存在していても1つのECMデータを共有していたり、そもそもスクランブルされておらずECMデータが存在していないものとなっています。
このことから、トランスポートストリームをチャンネル(サービス)別に分割することで、メリットがあるのはBSとCSで、地デジはトランスポートストリームを分割しても、しなくてもあまり変わらないことになります。そこで、地デジではトランスポートストリームの分割は行わず、チャンネル互換モードとチャンネル拡張モードのどちらでも同じ動作とします。BSとCSについては、チャンネル拡張モードではトランスポートストリームをチャンネル(サービス)別に分割します。
チャンネル拡張モードには利点だけでなく問題点もあります。PT1・PT2では1つのデバイスで地上2TS・衛星2TSの同時録画が可能です。例えば、NHK BS1とNHK BS2は同じトランスポートストリーム内に存在し、WOWOW1、WOWOW2、WOWOW3は同じトランスポートストリーム内に存在します。NHK BS1、NHK BS2、WOWOW1、WOWOW2、WOWOW3の5チャンネル(サービス)を同時に録画したとしてもトランスポートストリーム的には2つなので、衛星2TSの範囲内となり(録画ソフトが対応していれば)同時録画が可能です。しかし、チャンネル拡張モードでは、各チャンネル(サービス)が別々のトランスポートストリームに分割されるので、実トランスポートストリーム内に存在するチャンネル(サービス)がどれなのか知るすべがなく、地上2チャンネル(サービス)・衛星2チャンネル(サービス)の範囲内での録画可能チェックしか行えないことになります。
ただし、上で「録画ソフトが対応していれば」と書きましたが、EpgDataCap_BonやEPGデータビューアでは、地上2TS・衛星2TSではなく、地上2チャンネル(サービス)・衛星2チャンネル(サービス)での同時録画可能チェックを行っているようです。TvRockでも録画用に地上2プロセス・衛星2プロセスしか同時起動できないので、地上2チャンネル(サービス)・衛星2チャンネル(サービス)までしか同時に録画できません。このようなソフトではどちらのチャンネルモードを使用しても同じです。もしトランスポートストリーム単位でチェックを行う録画ソフトがあれば拡張チャンネルモードでは正確なチェックが出来ないことになります。
拡張チャンネルモードにおいて、BonDriverの内部チャンネル番号をどのように持つべきか、かなり試行錯誤しました。BonDriverの内部チャンネル番号は、0からの連番で抜け番が許されない設計になっています。これに対応する方法として3つの案を考えました。
案1) サービスID順に0からの連番で内部チャンネル番号を採番する。チャンネル(サービス)が追加・削除された場合は、最新の状況で新たにサービスID順に0からの連番で採番し直す。(新しいチャンネル(サービス)は途中に追加されることになる)
案2) 初期はサービスIDの順番で0からの連番で採番する。チャンネル(サービス)が追加された場合は続きに追加していく。チャンネル(サービス)が削除された場合、内部チャンネル番号は削除せず残しておく(選択しても何も受信しないチャンネルとして残る)。
案3) BS・CSのサービスIDが必ず1000未満であり、この法則が今後も続くと考えられる。これを利用し、BS・CSそれぞれの内部チャンネル番号を0～999の1000個分をあらかじめ採番して置き、チャンネル(サービス)をサービスIDと同じ内部チャンネル番号に割当てる。割当てられなかった内部チャンネル番号は選択しても何も受信しない。チャンネル(サービス)が追加された場合もサービスIDが等しい内部チャンネル番号に割当てる。チャンネル(サービス)が削除された場合は該当する内部チャンネル番号の割当てを解除する。
案1はチャンネル(サービス)が追加・削除された前後で内部チャンネル番号の互換性がありません。例えばWOWOW1が20から21になるといったことが起こりえます。案2と案3はチャンネル(サービス)が追加・削除されても、その前後で内部チャンネル番号の互換性が保たれます。内部チャンネル番号の互換性が無いと、内部チャンネル番号の採番し直しをユーザーの操作で行う必要があり(自動で変更は出来ない)、さらに視聴・録画ソフトのチャンネルスキャン、予約録画のやり直し、自動予約の再設定、視聴・録画ソフトによっては設定の初期化からやり直す必要もあります。案2と案3では内部チャンネル番号の互換性が保たれるので、視聴・録画ソフトのチャンネルスキャンで変更分の認識は必要ですが、それ以外の操作は必要ありません。
案2は使い込んでいくうちに削除されたチャンネル(サービス)が溜まり、追加されたチャンネル(サービス)が無造作に存在するようになります。以前にCSで大幅なチャンネル番号(このチャンネル番号＝サービスIDです)の変更がありました。ほとんどのチャンネルで変更されたように記憶していますが、今後も同様なことが起きる可能性が無いとはいえないので、無駄なチャンネルが多くなり並び順が乱雑になるということは考えられます。
案3は常に一定の規則で並び、案2のように並び順が乱雑になるといったことは無いのですが、実チャンネル(サービス)が割当てられていない内部チャンネルが多数存在していますので、視聴・録画ソフトのチャンネルスキャン時に時間が掛かる可能性があります。TVTestでは信号レベルを考慮することでそれほど時間は掛かりませんでしたが、EpgDataCap_Bonでは3時間近く掛かりました。
このように、それぞれの案で一長一短があるわけですが、チャンネル(サービス)の追加・削除がそれほど頻繁にあるものではないとしても、毎回設定の初期化が必要となるようではちょっと実用には向かないということで、案1はボツにしました。案2が一番良いような気がするのですが、なぜか引っ掛かるものがありやってみたら爆弾があったということになりそうな気がして、予感的なものでしかないのですがどうしても採用できず、とりあえず案3を採用することしました。チャンネルスキャンが長時間掛かるというのも実用的にどうかと思うのですが、あまりに問題になるようならEpgDataCap_Bonのチャンネルスキャンを代理で行うようなプログラムを作成することでも対応可能だと判断しました。他に何かもっと良い案があれば大幅な変更を行うかもしれません。
※2011/4/3追記：EpgDataCap_Bonのチャンネルスキャンを高速で行えるようにする方法が見つかり15分掛からない程度の時間で行えるようになりました。(ver1.04で対応)
とりあえず案3を採用することにしましたが、バージョン1.03の時点では内部チャンネル番号は固定で定義しており、チャンネル(サービス)の追加・削除を反映する機能はまだ未対応となっています。チャンネル(サービス)の追加・削除を反映する機能ついては出来るだけ早く対応したいと考えています。
↑ver1.05で対応しました。
このようにチャンネル互換モード・チャンネル拡張モードのそれぞれに一長一短があります。これらのことを考慮の上、どちらを使用するか判断していただければと思います。
※基本的には、VirtualPT側でスクランブル解除を行う場合は拡張モードを、視聴・録画ソフト側でスクランブル解除を行う場合は互換モードをお使いいただければと考えています。
2011年04月01日
VirtualPTのスクランブル解除機能を使用することで、各視聴・録画ソフトで行っていたスクランブル解除をVirtualPTで一元実行できるようになります。又、一部のOSでスクランブル解除が原因で起きていたクラッシュが改善されます。
しかし、BonDriverの設計では内部チャンネル番号がトランスポートストリーム単位で採番されています。PT1・PT2も(おそらく他のチューナーでも)トランスポートストリーム単位でデータを受信します。トランスポートストリームは複数のプログラム(サービス)を含むことが出来るように定義されていて、具体的には、NHK BS1、NHK BS2がそれぞれプログラム(サービス)で、それが1つのトランスポートストリーム内に存在します。また、WOWOW1、WOWOW2、WOWOW3が1トランスポートストリームですし、CSでは最大9個のプログラム(サービス)が1つのトランスポートストリーム内に存在します。
このことから、視聴・録画ソフトで必要とするチャンネル(サービス)がNHK BS1だとしても、VirtualPT側(BonDriver側)では、それを知るすべが無いためNHK BS1とNHK BS2を両方含んだトランスポートストリームを転送し、視聴・録画ソフト側でNHK BS2を破棄(というか無視)しています。
視聴・録画ソフトでスクランブル解除する場合、このことはあまり問題になりませんが、VirtualPTでスクランブル解除を行う場合、不要なチャンネル(サービス)までスクランブル解除しなければなりません。そこで、このことがどの程度問題になるか、負荷計測してみました。
1つ目の負荷計測はスクランブル解除に掛かる負荷です。VirtualPT用にアルゴリズム最適化したロジックの実測値は以下の通りです。
32ビット版最適化ロジック| ＣＰＵ | 動作周波数 | Ａ | Ｂ | Ｃ |
|---|---|---|---|---|
| Core2Duo E8600 |
3.33GHz | 1,914,131 | 7.83ms | 127.61 |
| Core2Duo E6400 |
2.13GHz | 1,245,511 | 12.04ms | 83.03 |
| Pentium4 630 |
3.00GHz | 705,461 | 21.26ms | 47.03 |
| Pentium4 3.0 |
3.00GHz | 685,177 | 21.89ms | 45.67 |
64ビット版最適化ロジック
| ＣＰＵ | 動作周波数 | Ａ | Ｂ | Ｃ |
|---|---|---|---|---|
| Core2Duo E8600 |
3.33GHz | 1,994,482 | 7.52ms | 132.96 |
| Core2Duo E6400 |
2.13GHz | 1,259,883 | 11.91ms | 83.99 |
| Pentium4 630 |
3.00GHz | 706,445 | 21.23ms | 47.09 |
CPUはPentium4が2種類、Core2Duoが2種類で計測しました。現状普及している多数のものは既にこれらより性能が良いと思います。Ａ欄の値は1秒間に実際に処理したパケット数の実測値です。Ｂ欄はＡ欄の値から計算した15,000パケットの処理に掛かる時間です。15,000パケットとは、ある日のBSハイビジョン放送のスクランブルされたパケットを計測したところ１秒当たり12,700パケット程度であったことから、少しの余裕をみた予想最大パケット数です。違っていても遠からずの値と思います。Ｃ欄はＢ欄の値から計算した同時並行にスクランブル解除可能な処理数です。実際にはマルチコアやハイパースレッド等が普及しているため、さらに改善されると思いますが、Pentium4で45以上、Core2Duoで80以上という結果から無駄なスクランブル解除を行ってもあまり問題にはならないと思います。参考にTVTestの設定ダイアログから実行出来るベンチマーク結果とVirtualPTとの性能比も掲載します。
32ビット版TVTest| ＣＰＵ | 動作周波数 | ベンチマーク結果 | 1秒間の処理パケット数 | 性能比 |
|---|---|---|---|---|
| Core2Duo E8600 |
3.33GHz | 804ms /800000回 |
995,025 | 1.924倍 |
| Core2Duo E6400 |
2.13GHz | 578ms /400000回 |
692,042 | 1.800倍 |
| Pentium4 630 |
3.00GHz | 1,704ms /800000回 |
469,484 | 1.503倍 |
| Pentium4 3.0 |
3.00GHz | 967ms /400000回 |
413,650 | 1.657倍 |
64ビット版TVTest
| ＣＰＵ | 動作周波数 | ベンチマーク結果 | 1秒間の処理パケット数 | 性能比 |
|---|---|---|---|---|
| Core2Duo E8600 |
3.33GHz | 720ms /800000回 |
1,111,111 | 1.795倍 |
| Core2Duo E6400 |
2.13GHz | 565ms /400000回 |
707,965 | 1.780倍 |
| Pentium4 630 |
3.00GHz | 961ms /400000回 |
416,233 | 1.697倍 |
Pentium4で1.5倍以上、Core2Duoで1.75倍以上となっていますので、概ね良好と言えるでしょう。
2つ目の負荷計測はBCASカードの処理性能です。使用したBCASカードとICカードリーダーは以下の通りです。
| 入手時期 | 備考 | |
|---|---|---|
| BCASカード1 | 2004年3月頃 | テレビに付属 |
| BCASカード2 | 2006年5月頃 | テレビに付属 |
| BCASカード3 | ？ | ヤフオクで入手(2010年6月)したPT2のおまけ |
| メーカー | 名称 | |
|---|---|---|
| ICカードリーダー1 | NTTコミュニケーション | SCR3310-NTTCom |
| ICカードリーダー2 | DECA | CX603 |
それぞれのBCASカードとICカードリーダーで、無料放送(地デジ・BS)と有料放送(CS)から抽出したECMデータの処理に掛かった時間を計測しました。ちなみに、無料放送の地デジとBSでは処理結果にほとんど差は有りませんでした。又、有料放送の契約済みチャンネルと未契約チャンネルではほとんど差が有りませんでした。なので表から省略しています。
無料放送| カード | リーダー | 処理結果 | 1回の処理時間 | 2秒の処理可能回数 |
|---|---|---|---|---|
| BCAS1 | SCR3310 | 66,066ms /829回 |
79.69ms | 25.10回 |
| BCAS2 | SCR3310 | 51,168ms /829回 |
61.72ms | 32.40回 |
| BCAS3 | SCR3310 | 54,397ms /829回 |
65.62ms | 30.48回 |
| BCAS1 | CX603 | 84,209ms /829回 |
101.58ms | 19.69回 |
| BCAS2 | CX603 | 61,948ms /829回 |
74.73ms | 26.76回 |
| BCAS3 | CX603 | 69,467ms /829回 |
83.80ms | 23.86回 |
有料放送
| カード | リーダー | 処理結果 | 1回の処理時間 | 2秒の処理可能回数 |
|---|---|---|---|---|
| BCAS1 | SCR3310 | 99,591ms /828回 |
120.28ms | 16.63回 |
| BCAS2 | SCR3310 | 74,288ms /828回 |
89.72ms | 22.29回 |
| BCAS3 | SCR3310 | 48,532ms /828回 |
58.61ms | 34.12回 |
| BCAS1 | CX603 | 125,471ms /828回 |
151.54ms | 13.20回 |
| BCAS2 | CX603 | 87,204ms /828回 |
105.32ms | 18.99回 |
| BCAS3 | CX603 | 59,951ms /828回 |
72.40ms | 27.62回 |
SCR3310の方がCX603より2割程度の処理速度が速いようです。又、2004年3月(まだ地デジの試験放送すら行われていなかった頃)のBCASカードの処理結果が全てに置いて悪いですが、他の2枚は得意・不得意があるようです。表の一番右の欄で2秒の処理可能回数を掲載していますが、これは、1つのECMで2秒分のストリームのスクランブル解除が可能(標準規格にはECMの更新最小時間間隔が1秒となっていますが、運用上2秒間隔となっているようです)な為、100％の効率で処理できた場合、最大でこの回数分のチャンネル(サービス)のスクランブル解除が行えるということになります。
この結果から、CSをトランスポートストリーム単位でスクランブル解除するには、トランスポートストリーム内の有料放送チャンネルの最も多いところで9チャンネル、次が7チャンネルであることから、1トランスポートストリーム(最大9チャンネル分)は何とかいけそうですが、2トランスポートストリーム(最大16チャンネル分)以上は厳しいかもしれません。
そこで、VirtualPTではこれに対応する為に2つの機能を実装することにしました。1つ目の機能は、複数枚のBCASカードが接続されている場合ECM処理を分散実行し処理可能数を引き上げます。当初、複数枚のBCASカードを管理する為に、各BCASカードが処理可能なチャンネルをあらかじめ設定しておく必要があるのではと考えていましたが、実際の実装では番組が始まる度にその番組に対応したBCASカードを自動的にチェックし対応しているカードのみ使用するようにしたので、特別な設定は必要ありません。ただ、BCASカードの入手が誰でも簡単に出来るものではないことと、有料放送はBCAS枚数分の契約が必要となってくる為、この機能を使える方は限られていると考えています。
もう1つの機能は、トランスポートストリーム単位で採番されているBonDriver内部チャンネル番号をチャンネル(サービス)単位で採番しなおし、あたかも、トランスポートストリームが1つのチャンネル(サービス)だけを含んでいるかのように仮想化します。このことで視聴・録画ソフトからの指定がチャンネル(サービス)単位となる為、必要のないチャンネル(サービス)のスクランブル解除がなくなり、上記BCASカードの処理能力の限界を気にする必要がなくなります。この新しいBonDriver内部チャンネル番号の持ち方を「拡張モード」、既存のBonDriver内部チャンネル番号の持ち方を「互換モード」とし、各視聴・録画ソフト別にそれぞれ必要なほうを選択出来るようになります。拡張モードについて詳しくは「チャンネル拡張モードについて」を参照して下さい。
2011年04月01日
チャンネルという用語が、あいまいなのでちょっと整理してみます。チャンネル周りの階層を標準化ドキュメントなどでどのように定義・表現されているか表にしました。
| ドキュメント | |||||
|---|---|---|---|---|---|
| ISO/IEC 13818-1 |
ARIB | BonDriver | PT2サンプル | ||
| 階 層 |
地上・衛星 | ISDB 受信方式 |
|||
| チューニング空間 | チューニング 空間(space) |
||||
| ネットワーク | network | ネットワーク | |
||
| 周波数 | channel 局発周波数 |
||||
| トランスポートストリーム | transport stream |
トランスポート ストリーム |
チャンネル (channel) |
TS | |
| サービス | program | サービス | |
||
チューニング空間は、具体的にはUHF,CATV,VHF,BS,CSとBonDriverで定義されています。ネットワークは、地デジでは各周波数1つでネットワーク1つです。例えば、UHF13chで放送されているものが1つのネットワークを構成します。BSではBS全てで1つのネットワークです。CSではCS全ての中でCS1とCS2の2つのネットワークに分割されています。トランスポートストリームはいわゆるTSデータ(拡張子.tsのデータ)のことです。サービスは番組が時系列に連続する(1つの番組が終わると次の番組が続く)もので、誤解を恐れずに言うと、一般的に表現されるところのチャンネルのことです。
地デジでは1つの周波数の中に、1つのトランスポートストリームしか存在できませんが、BS/CSでは1つの周波数の中に、最大8つのトランスポートストリームを含むことができます。そして、1つのトランスポートストリームの中には、複数のサービスを含むことが可能です。具体的には、NHK BS1、NHK BS2がそれぞれサービスで1つのトランスポートストリーム(ID:40f1)がNHK BS1、NHK BS2を含んでいます。また、別のトランスポートストリーム(ID:40f2)がNHK hを含んでいます。これら2つのトランスポートストリームが1つの周波数(BS15)の中に存在します。
アナログ放送では、チャンネルが上の表の周波数でありサービスであった訳ですが、デジタル放送では１つの周波数の中に複数のサービスが存在します。ただ「チャンネル」と表現するとどれを指しているのかあいまいになるので、このカテゴリ内では「チャンネル(周波数)」や「チャンネル(サービス)」という風に区別できるように記述するようにします。
2011年01月14日
このページのベータ版で動作確認していただいた機能はバージョン1.02で対応しました。ご確認いただいた方には、この場をお借りしてお礼申し上げます。
このページでの動作確認の募集は終了いたしますが、もしバグを発見されましたら。要望・バグ報告のページでお知らせ下さい。
VirtualPTでは「PT1/PT2 SDK バージョン 2.x」対応として開発してきましたが、PT2X2では「PT1 SDK バージョン 1.x」でないとBS/CSの受信が出来ないとの情報をいただきました。そこで、VirtualPTでSDK 1.xでも動作するよう修正をしたいと思うのですが、SDK 1.xで動作するハードウェアを持っていないため、動作確認が出来ない状態です。（動作確認用にPT2X2を購入しようと思っていたのですが、PT2 Rev.Bが定価で購入できるチャンスがあったので、そちらの方を購入してしまいました。寄付がどのくらい集まるか分からない状況ではこれ以上の支出は厳しいです）
そこで、VirtualPTのベータバージョンをPT2X2で動作するか確認していただける方を募集いたします。確認していただける方は、このページの手順に従い作業していただき、チェック項目をこのページのコメントとして送信してください。PT2X2をお持ちの方の参加をお待ちしております。
VirtualPTを既にインストールされている場合は、まずアンインストールを行って下さい。アンインストール方法はコチラを参照してください。
「PT1 SDK バージョン 1.x」と「PT1/PT2 SDK バージョン 2.x」を両方インストールしている場合、「PT1/PT2 SDK バージョン 2.x」をアンインストールして下さい。
VirtualPTのベータバージョンを下記からダウンロードして下さい。
VirtualPT 1.02β1
VirtualPT 1.02β2
チェック１：お使いのPT2X2で使用しているドライバとSDKのバージョン（もしくはインストールファイル名、例えばPT1_Windows_SDK_100.exe）をお知らせ下さい。これからの確認作業でも変更しないで下さい。
ダウンロードした圧縮ファイル内のx86フォルダを適当なフォルダにコピーして、そのフォルダ内のVirtualPT.exeを起動してください。画面右下のタスクトレイにVirtualPTアイコンが表示されます。起動から5秒間ピコピコ点滅しているものがVirtualPTアイコンです。
VirtualPTアイコンをクリックしてメニューを開き、「設定」を選択します。
チェック２：EARTH PT1/PT2タグ内のデバイス一覧にPT2X2が表示されたかお知らせ下さい。表示された方は「ボード種類」に表示された文字列もお知らせ下さい。
上でPT2X2が表示されない方は、ここで確認作業は終わりです。展開したフォルダを削除して下さい。
表示された方はコチラを参照してインストールを完了して下さい。
チェック３：TV視聴ソフトやTV録画ソフトで正常に受信出来るかお知らせ下さい。その際、受信できたチューニング空間（例えば、地デジ○、ＢＳ×、ＣＳ－）と受信できなかった場合は、状況を出来るだけ詳しくお知らせ下さい。
チェック項目をコメントで送信下さい。これで確認作業は終わりです。コチラを参照してベータバージョンをアンインストールして下さい。
確認作業に参加していただき誠にありがとうございました。
トラックバックURL
コメント一覧
正常に動作されたとのことで安心致しました。PCIスロットとの相性でもあるのでしょうか？差込みが甘かった可能性もありますね。
ボードの種類はPT1かPT2のみでPT2X2と表示されるわけではありません。私はPT2となるのではと思っていましたが、PT2X2はPT1に近いようでPT1で正しい表示です。
あと、LNB電源をOFFにされているようですが、PT2X2しか使用していない時（テレビやビデオ等の電源が入っていない時）、BS/CSアンテナにLNB電源が供給されず、受信出来ないということも考えられます。地デジとは関係ありませんがご確認下さい。
PCIスロットを差し替えた所 正常に動作致しました。
しかし,
ボード種類で表示されるのは相変わらずPT1です。
1.OS XPpro sp3 32bit
2.CPU PEN4HT 2.8
3.VirtualPTのバージョン 1.02
4.TVTestのバージョン 0.7.13
VirtualPT.exeのあるフォルダのVirtualPT.iniの内容
[GENERAL]
UHFValid=1
CATVValid=0
VHFValid=0
BSValid=1
CSValid=0
SharememValid=1
SocketValid=0
SocketPort=12300
CATVFrequency=0
[EARTHPT]
LnbPower=0
GrayOff=1
UseOldSDK=1
S1Valid=0
S1Priority=0
T1Valid=1
T1Priority=0
S2Valid=1
S2Priority=0
T2Valid=1
T2Priority=0
[EARTHPT_DEVICE3/10/1]
Setting=0
LnbPower=0
GrayOff=0
UseOldSDK=0
S1Valid=1
S1Priority=0
T1Valid=1
T1Priority=0
S2Valid=1
S2Priority=0
T2Valid=1
T2Priority=0
[EARTHPT_DEVICE3/9/1]
Setting=0
LnbPower=0
GrayOff=0
UseOldSDK=0
S1Valid=1
S1Priority=0
T1Valid=1
T1Priority=0
S2Valid=1
S2Priority=0
T2Valid=1
7.BonDriver_VTPTの設定
[SETTING]
HostName=
Priority=0
UHFValid=1
CATVValid=1
VHFValid=1
BSValid=1
CSValid=1
よろしくお願いします
お使いの環境を教えていただけないでしょうか？
1.OS(32ビット/64ビットの区別も)
2.CPU
3.VirtualPTのバージョン
4.TVTestのバージョン
6.VirtualPTの設定
VirtualPT.exeのあるフォルダのVirtualPT.iniの内容
7.BonDriver_VTPTの設定
TVTest用に使用したBonDriver_VTPT.dllのあるフォルダのBonDriver_VTPT.iniの内容
よろしくお願いいたします。
PT2X2を入手し暗中模索状態でこのページに辿り着きました。
Driverは1.00
SDKは1.02
ボード種類に表示されるのはPT1です。
Tvtest、EpgDataCap_Bonであたかも正常動作してるようですが
受信レベルが０でチャンネルスキャンが正常終了できませんせした。
以上 ご報告まで。
ICカードリーダー関連の処理はまだ一切やっていませんし、悪影響しそうなことはやっていないと思うのですが、なぜでしょう？気にしないとのことなので、これ以上追求しませんが、詳しいことが分かりましたら、お知らせいただければ幸いです。
PT2X2を使ってますがTvTestで4TS視聴出来ました
録画はしていませんが問題ないと思います
SDKは102です
ただ、NTTのｶｰﾄﾞﾘｰﾀﾞｰでは問題ないのですが
UD200をｶｰﾄﾞﾘｰﾀﾞｰにすると視聴出来ませんでした
特殊な使い方ですので気にはしてませんが
ベータ版でご確認いただいた機能は、バージョン1.02で正式にリリースする予定です。それまで、ベータ版をご使用いただいてかまいませんが、バージョン1.02のリリース後は、ベータ版をアンインストールしてリリース版をご使用いただきますようお願いいたします。
尚、PT2X2の動作確認はまだ受け付けておりますので、多数の方の参加をお待ちしております。
[SetStreamGrayがPT2X2で機能していない]
ばっちりでしたCHスキャンも無事完了、全CH見れました
BS、CSのほうも同様にOKです
SDKのバージョンは
SDK102を使用しています
ありがとうございました
さっそく今夜からテストしてみます
もしかして、地デジのチャンネル数は7でしょうか？8チャンネル毎に表示されるのであれば、SetStreamGrayがPT2X2で機能していない可能性があります。このページに「VirtualPT 1.02β2」を追加しましたので、そちらで確認をお願いいたします。
尚、ドライバとSDKのバージョンですが、アースソフトのサイト(http://earthsoft.jp/PT/download-old.html)内では、どれをお使いでしょうか？正常に動作した場合、どのバージョンでなら正常に動作するかを把握しておきたい為です。
1.02β1
問題ないようです
http://uptter.com/Rttm2.png
普段DECULTUREのBonDriverは
http://2sen.dip.jp/cgi-bin/pt1up/upload.cgi?page=0&lm=2000
BonDriver_PT1-ST-shm （人柱版３改） 0.3.0.13 / 残念な人Ver(up0199.zip)
ないし
最適化まとめてパックLite（ICCビルド）(up0204.zip)
で使用しています
さっそく、ありがとうございます
デバイスの認識はできました
http://uptter.com/7ywTF.png
チャンネルスキャンが・・・
http://uptter.com/GOv7T.png
何度か試すも1chのみ
決まってない模様
CH2ファイルを用意したもので
視聴するとやはり1つだけうつります
TVtestの右カーソルキーでチャンネルおくりしていくと、一回り後、次のチャンネルが見えます、
3chが写っている状態から順に送っていき、一まわりして4chまで行ったときに写ります
BSのほうもよく似た感じです
よろしくお願いします
コメントする
2011年01月09日
要望やバグ報告は当面このページのコメントで受け付けます。要望や不具合を発見しましたらぜひお知らせ下さい。
視聴・録画ソフト別注意点
- [TVTest]
-
- チャンネルスキャンを行う場合のオススメ設定は、「サービスを検索する」はチェックする、「信号レベルを無視する」はチェックしない、「チャンネル切り替え時の待ち時間」は「2秒(Plex PXシリーズの場合は+1秒、TCP-IP経由の場合はさらに+1秒)」、「チャンネル検出の最大待ち時間」は「10秒」です。
- [EpgDataCap_Bon]
-
- EpgTimer_Bonをサービスに登録していて電源投入後即録画が開始するとクラッシュする場合、EpgTimer_Bonのスタートアップの種類を「自動(遅延開始)」にすることで改善される可能性があります。
- 起動時のチャンネルを変更せずにしばらくすると、受信が停止することがあります。調査したところ、複数のEpgDataCap_Bonから1つのDLL(BonDriver_VTPT.dll)にアクセスした場合、チャンネルの変更をしていないにも関わらず、チャンネル番号0-0への変更指示が出るようです。チャンネル拡張モードでは、この現象が発生した時は無視するようにしましたが、チャンネル互換モードでは、DLLをチューナー毎にコピーする等してください。
- [TvRock]
-
- チャンネル互換モードは内部チャンネル番号(BonDriverチャンネルインデックス)が0から始まります。チャンネル拡張モード(拡張モードBも)は内部チャンネル番号(BonDriverチャンネルインデックス)が1から始まります(あえて0にダミーのチャンネルを定義しています)。なので、TvRockチャンネル番号も1つずれます（拡張チャンネルの方が+1です）のでご注意ください。地デジでは拡張モードを使うことで何かメリットがあるわけではないので互換モードを使用した方が無難かもしれません。
- [RecTest]
-
- RecTest(ver0.3.1時点では)はBonDriver内部チャンネル番号(BonDriverチャンネルインデックス)をプログラム固定で定義している為、拡張モードでは正しく動作しません。録画プログラムにはTVTestを/nodshowオプション指定で使用してください。※どうしてもRecTestを使用したい場合、「どうしてもRecTestを使用したい場合」を参照してください。
これまでに要望があったもの
- 独立U局対応（チューナー別の受信チャンネル設定） → ver1.09で対応
- PLEX PX-W3PE対応 → ver1.09でPLEX PXシリーズに対応
- 初心者向けページ → VirtualPT設定例カテゴリを追加
- BCASカード性能測定ツール
- サービス別受信設定に「デジタル音声」「データ放送」を追加 → ver1.14で対応
トラックバックURL
コメント一覧
pt3Timerは専用BonDriverが必要だと認識しております。pt3Timerについては詳しくありませんが、他のBonDriverと同様だとするとVirtualPTがアクセスしているチューナーは他のBonDriverからアクセス出来ません。又、他のBonDriverでアクセスしているチューナーはVirtualPTからアクセス出来ません。
サーバー:
pt3Timer
TVTest
クライアント:
TVTest
で運用していますが、サーバーで録画・視聴中、クライアントで何も視聴できません。
また、クライアントで視聴中はサーバーで録画・視聴できません。（BonDriverの初期化失敗のエラーがでます。）
一方で地デジ・衛星のどちらかを視聴・録画中はもう一方ではどちらも視聴不可状態になります。
また、VirtualPTのチューナー設定よりチューナー1セット(衛星1地上1)を無効にしても同様でした。
サーバー上、クライアント上それぞれでは複数チャンネル同時視聴は可能なのでPT3の問題ではなさそうです。
なにか設定見落としてますでしょうか。
修正されるまではこれで運用したいと思います。
ありがとうございました。
BS有効＆CS無効とした場合に、お知らせ頂いた現象が発生することを確認しました。この現象の改善はバージョン1.18で行います。
それまではBS・CS共に有効にしてお使い下さい。
CSは無効にしているのでBSだけになります。
==================
======
拡張モードチャンネルスキャン(BS)→開始
TSIDテーブル取得(BS01)→OK
TSIDテーブル取得(BS03)→OK
TSIDテーブル取得(BS05)→OK
TSIDテーブル取得(BS07)→OK
TSIDテーブル取得(BS09)→OK
TSIDテーブル取得(BS11)→OK
TSIDテーブル取得(BS13)→OK
TSIDテーブル取得(BS15)→OK
TSIDテーブル取得(BS17)→OK
TSIDテーブル取得(BS19)→OK
TSIDテーブル取得(BS21)→OK
TSIDテーブル取得(BS23)→OK
ネットワーク・サービス情報受信(BS01:4010)→OK
拡張モードチャンネルスキャン(BS)→終了：追加80件、変更0件、削除0件
互換モードチャンネルスキャンを登録するには、「互換モードチャンネル登録」を実行してください。
========================
になります。
このあと、互換モードチャンネル登録を行うと、強制終了します。
========================
障害が発生しているアプリケーション名: VirtualPT.exe、バージョン: 1.16.1300.40、タイム スタンプ: 0x501e6162
障害が発生しているモジュール名: VirtualPT.exe、バージョン: 1.16.1300.40、タイム スタンプ: 0x501e6162
例外コード: 0xc0000417
障害オフセット: 0x000000000013bde0
障害が発生しているプロセス ID: 0xbc4
障害が発生しているアプリケーションの開始時刻: 0x01cd7d2998995e69
障害が発生しているアプリケーション パス: C:\tools\VirtualPT\x64\VirtualPT.exe
障害が発生しているモジュール パス: C:\tools\VirtualPT\x64\VirtualPT.exe
レポート ID: eaab942d-e91c-11e1-9741-00224d993840
========================
互換モードチャンネル一覧のBSには空白で何も登録されていません。
拡張モードチャンネル一覧のBSにはデータが登録されています。
手順通り実行後、チャンネル情報が入っていることを確認しました。
この状態でTVTestでBS01/TS0の信号レベルは17db程度で、正しく表示されました。
画面表示を正確にお知らせ下さい。
「ネットワーク・サービス情報受信(BS01:4010)→開始」のままですか？「ネットワーク・サービス情報受信(BS01:4010)→ＯＫ」等の他の表示に代わっていませんか？
TVTestはチャンネル互換モード、チャンネル拡張モードのどちらでお使いでしょうか？
チャンネル互換モードでご使用になられている場合、チャンネルスキャンダイアログ内の「互換モードチャンネル一覧」＞「BS」内の表示はどうなっていますか？
チャンネル拡張モードでご使用になられている場合、チャンネルスキャンダイアログ内の「拡張モードチャンネル一覧」＞「BS」内の表示はどうなっていますか？
もし、チャンネルが全く無い場合、VirtualPTサービスを停止後、VirtualPT.exeのあるフォルダ内から「BDChannel00000021.dat」と「BDChannel00000022.dat」を削除後、バージョン1.14のVirtualPT.exeのあるフォルダ内から「BDChannel.dat」をバージョン1.16のVirtualPT.exeのあるフォルダ内にコピー後VirtualPTサービスを開始すれば、TVTestでチャンネルスキャンをしなくてもBS朝日が受信できるはずです。（互換モードの場合「BS01/TS0」を受信、拡張モードの場合「BS151ch」を受信）
「エラーが発生した為、チャンネルスキャンに失敗しました。」
TVTest等でチャンネルスキャンすると
「チャンネルが検出できませんでした。
信号レベルが取得できないか、低すぎます。」
そのため、BSは映りません。
なお、地デジは正しく映ります。
PT3_ST では正しく受信できています。
ほかに必要な情報がありましたら、お知らせください。
画面表示を正確にお知らせ下さい。
「ネットワーク・サービス情報受信(BS01:4010)→開始」までは表示されたのだと思いますが、エラー発生時はどのように表示されていますか？またメッセージボックスの表示内容を正確にお知らせ下さい。
後、BS朝日をTVtest等で受信できるか？シグナルレベルはどの程度か？もお知らせ下さい。
チャンネルスキャンから手動でチャンネルスキャンを行うと
ネットワークサービス情報受信（BS01:4010）でエラーが発生したとのPOPUPウィンドウが出ます。
環境
OS：Windows7 x64
VirtualPT：1.16 x64版
PT3 Driver：1.00
PT3 SDK：0.96
なお、この環境で1.14でスキャンした場合は正常に完了します。
お知らせ頂いた情報だけでは、こちらとしては調べようが有りません。
・自動チャンネルスキャンor手動チャンネルスキャン？使用中の環境、現象等、もっと分かるようにお知らせ下さい。
1.14では正常にスキャン完了します。
エラー内容についてはイベントビューアーにもかかれていないのでわからないです。
ご報告までに
EpgDataCap_BonのバージョンはそのままでVirtualPTだけv1.15からv1.16に変更後このような現象が発生しだしたのでこちらに書かせていただきました。
今はv1.15に戻して使っていますが、v1.15ですと現象は起きずにいます。
EpgTimerSrv.exe側で発生してる現象をこちらに書込してすみませんでした。EpgDataCap_Bonの作者様にもあたってみます。
EpgDataCap_Bonのバージョンが分からない為、詳しく調べられません。ただ、EpgDataCap_Bon.exeであればBonDriverのメモリ関連の不具合の可能性がありますが、EpgTimerSrv.exeの場合VirtualPTが直接的な原因とは考えられません。間接的に不具合を引き起こす原因になっている可能性はありますが、EpgTimerSrv.exe側で発生している現象ですので、EpgDataCap_Bonの作者様へお問合せ下さい。
v1.15の時はこのような事は何日間連続使用しても発生していませんでした。
EDCBとVirtualPTどちらもエラーなど落ちるような事はありませんし録画失敗することもありませんが、当方の環境ではv1.16を使うと半日程度で「EpgTimerSrv.exe」の使用メモリーが1.2Gになってしまう現象の再現性は100%でした。
v1.15ですとこのような事にはならないのでv1.15からv1.16への仕様変更で発生するようになったと思います。
対応出来そうな事でしたら修正して頂けると助かります。
PT1・PT2用のドライバ2.1＆SDK2.1でVirtualPT側の対応は必要ないはずです。もしPT1が新ドライバ・SDKで認識しなくなったのであれば、アースソフト側の対応を待つか以前のドライバ＆SDKをお使い下さい。
尚、VirtualPTはver1.16からPT1でご使用になる為には、VirtualPT.exeのあるフォルダにDeviceEarthPT.dllが必要です。こちらもご確認下さい。
VirtualPTを使わせていただいております。
PT1/PT2のドライバ、SDKが更新されましたので対応お願い出来ますでしょうか
現行の1.16ですとSDKの更新によりVirtualPTからPT1が見えなくなりました。
http://earthsoft.jp/PT1_PT2/download.html
了解いたしました。
次バージョンにも期待しております。
ご調査ありがとうございました。
画像をお送り頂きありがとうございました。
当方でも、ウィンドウのデザイン設定次第で現象が発生することを確認しました。タブを切り替えることで、見た目は悪いものの機能的には問題無いことも確認しましたので、とりあえずそのように対応お願いいたします。
尚、この現象の改善は次のバージョン(ver1.17)で行います。
メールをお送りいたしましたのでご確認くださいませ。
現象を確認できる画像（画面のPrintScreen）をいずれかから公開、もしくは、doma@do-ma.info宛にメール添付でお送りいただけないでしょうか？
お手数をお掛けしますがよろしくお願いします。
Windows7 SP1環境にて、VirtualPT.exe（1.16）から設定ウインドウを開くと、白い背景色に設定項目が消えた状態で表示されます。
タブを切り替える、またはチェックボックスにマウスカーソルを乗せるなどで一部項目は表示されますが、背景色はおかしいままです。
x86、x64の両バージョンにて発生しておりますので、お手数ですがご調査をお願いいたします。
残念ですがスクランブル解除機能を単独で公開する予定はありませんのでご了承下さい。又、TRMPが開始されたとしてもB-CASが使えなくなるわけではないと思いますよ。
b25decoder.dllの公開停止から暫く経ち、それまで目立った更新もなかったものですから、Virtual PTのスクランブル処理速度には非常に魅力的なものがあります。また、TRMPのECMがB-CASのそれよりも若いPIDに繰り上がった場合、我々一般ユーザーには為す術もありません。
図々しいとは重々承知しておりますが、ご検討の程よろしくお願い致します。
ご報告頂いた現象は、sonicboom様からご報告頂いた現象、もしくは、ver1.10で改善した現象と同じではないかと思われます。次のバージョン(ver1.16)でも、同現象が発生する場合は、再度、ご指摘いただけますと助かります。
タイミングの関係なのかサーバーでの復帰録画失敗。（Ver.1.08）視聴したまま寝落ちは初めてなので痛かったです。
この度はご協力頂きありがとうございました。ver1.16β1で確認頂いた修正内容はver1.16に反映いたします。ver1.16公開までの間、ver1.16β1をそのままご利用いただいても構いません。
以上、よろしくお願いいたします。
VirtualPT_0116B1.zip
で当方で発生していた現象は消えました。
ありがとうございました。
お知らせ頂いたイベントログの内容から、不具合箇所を発見できたのですが、当方の環境ではそれが原因の現象を再現することが出来ませんでした。そこで、sonicboom様の環境で改善バージョンを実行していただき、不具合が改善しているか確認していただけないでしょうか？
ご協力いただけるようでしたら、以下のアドレスから改善バージョンをダウンロードしていただき、現象が変化するかご確認していただき、結果をコメントでお知らせ下さい。
http://www.do-ma.info/VirtualPT/VirtualPT_0116B1.zip
Windowsのイベントログを以下に示します。
-----
障害が発生しているアプリケーション名: VirtualPT.exe、バージョン: 1.15.1041.30、タイム スタンプ: 0x50013ee3
障害が発生しているモジュール名: VirtualPT.exe、バージョン: 1.15.1041.30、タイム スタンプ: 0x50013ee3
例外コード: 0xc0000005
障害オフセット: 0x000a5cc2
障害が発生しているプロセス ID: 0x874
障害が発生しているアプリケーションの開始時刻: 0x01cd6ee79607f504
障害が発生しているアプリケーション パス: C:\VirtualPT\VirtualPT\x86\VirtualPT.exe
障害が発生しているモジュール パス: C:\VirtualPT\VirtualPT\x86\VirtualPT.exe
-----
イベントログのタイムスタンプからは、スリープからの復帰時に問題が発生するのでは無く、ネットワーク経由で視聴している最中にスリープになったときが発生するタイミングみたいです。
イベントIDは1000、タスクのカテゴリ(100)、例外コードと障害オフセットは常に同じでした。
VirtualPTを使用させて頂いてから10日程度しか経っていませんが、視聴サーバーとして2台のPCで使用してみましたがネットワーク経由での視聴以外ではスリープからの復帰を含めて問題は発生していません。
前回「タスクトレイでは《サービス実行中》」の場合もあると報告しましたが恐らく私の勘違いで、問題が発生する時は常に《サービス停止中》でした。
サーバー側のスリープ時間を1分にしてサービスの状態を確認してみました。
1.クライアントから視聴中にサーバーがスリープになり、クライアントからWOLした場合。
60%以上の確率で《サービス停止中》でした。
2.クライアントから視聴中にサーバーがスリープになり、サーバーをキーイベントでウェイクアップした場合。 60%以上の確率で《サービス停止中》でした。
3.クライアントから視聴し、サーバーがスリープになる前に視聴を停止した後WOLした場合。
常に《サービス実行中》でした。
4.クライアントから視聴し、サーバーがスリープになる前に視聴を停止した後サーバーをキーイベントでウェイクアップした場合。
常に《サービス実行中》でした。
お問合せの件ですが、「クライアント側からWOLを行った場合」のみ現象が発生するのでしょうか？電源ボタン等、他の手段でリジュームした場合には発生しませんか？
「高頻度で発生」とは、必ず発生するわけではなく、発生する場合としない場合があるということですね？
タスクトレイでは「サービス実行中」となっているとの事ですが、「プログラム」＞「管理ツール」＞「サービス」を起動した場合、「VirtualPT Core Service」の状態は「開始」になっていますか？また、スリープ直前もしくはリジューム直後にVirtualPTのイベントログが出ていませんか？
また、現象発生時にタスクマネージャでVirtualPTのCPU使用率がどのくらいになっているか教えてください。
高頻度で発生。（規則性不明）
タスクトレイでは「サービス実行中」になっていてもサーバー側TvTestで「BonDriver初期化出来ません」となる事がある。
WOLとは無関係かもしれません。
VirtualPTはVer.1.15、OSはクライアント・サーバー共にWindows 7 Ultimate x64 SP1。
録画環境はEpgDataCap_Bon(9.46)を使用。
WOL193を使用。
対処方法等教えて頂けるとありがたいのですが・・・
ipアドレスかホスト名かに限らず、同じ名前解決関数を使用していたような気がします。ipアドレスが指定された際に名前解決を行うのは意図とは違いますので、（出来れば次のバージョンで）改善したいと思います。
TCP-IP経由での視聴について少し怪しい挙動があったので報告させていただきます。
パケットキャプチャを見たところ、BonDriver_VTPT.iniのHostNameにIPアドレスを設定した場合に、
クライアント（BonDriver）側から、そのIPアドレスの逆引き（NBNSプロトコル等）が行われているようです。
実験としてパケットフィルタを使ってわざと名前解決を妨害してみると、サーバーへの接続に失敗し
視聴ができませんでした。
このような設定項目に対してIPアドレスを指定した場合に期待される動作は、名前解決を行わず接続を行うこと
のはずだと思うのですが、逆引きを行っているのは意図された動作なのでしょうか？
※VirtualPTはVer.1.15、OSはクライアント・サーバー共にWindows 7 Ultimate x64 SP1です。
承知しました。
詳細はメールで送信します。
当方で用意した確認プログラムを実行していただき、「衛星2を受信するとそれまで受信していた40chが0Mbpsになり、衛星2をＯＦＦすると40chがまた受信できるようになります」を再現して、その際の結果（ログファイルなど）をお知らせいただくということは可能でしょうか？
複数回お願いする可能性があります。もちろん、即座に確認を強要するものではなく、Pig様の都合のよい時に確認していただいて構いません。
もしご協力いただけるということであれば、確認プログラムの準備が出来次第、ご連絡しますのでdoma@do-ma.info宛にPig様の連絡先メールアドレスをあらかじめお知らせいただけないでしょうか？
・sb35960はサービスIDです
・40chのみ受信出来なくなります
・衛星2を受信するとそれまで受信していた40chが0Mbpsになり
衛星2をＯＦＦすると40chがまた受信できるようになります
・互換モードです。
・RecTask・TVTest・/nodshowどれでも同じ現象です。
sb35960が分からないのですが何でしょうか？地上1 or 地上2 ＋ 衛星2の組合せで、地上デジタルの13～26chは受信できるが40chが受信出来ないという事ですね？
ご使用のチャンネルモードは互換モードでしょうか？拡張モードでしょうか？
TVTestとRecTaskの両方とも同じ現象が発生しますか？RecTaskの代わりにTVTestを/nodshowオプション付きで代用した場合は現象が変化しますでしょうか？
前回はご対応ありがとうございます。
度々すみません私ではないが、下記の現象が発生しています。
衛星2を受信すると地上Dの40(27)ch(sb35960)が受信できなくなる。(0Mbps)
１．地上のみ →OK
２．地上＋衛星1 →OK
３．地上＋衛星1＋衛星2 →NG
４．地上 ＋衛星2 →NG
地上1・2とも同様、衛星の優先を変更しても衛星2受信時におかしくなる。
DMAを8→12→16→32に変更しても変わらない。
ver 1.08では、受信できていたようです。（TVROCKのログより）
アップデートはver 1.08→ver 1.13→ver 1.14のため間は解りません。
ver 1.08は消してしまった（確認不可）他のチャンネルは13～26ch内です。
BonDriver_PT-STでは発生しないよう。
OS：WinXP MB：D510MO
メモリ：4G チューナー：PT1
ドライバー：PT1 2.0 SDK：2.01
VirtualPT：ver 1.14・1.13
TvRock09u2 RecTask ver.0.1.4 TVTest 0.7.23 (x86)
すみませんが対応策等お願いします。
SDK0.96は３点修正があり内２点はSDKの入れ替えだけで対応されるのに対して、残り１点はSDKの入れ替え及びアプリ側の修正も必要になります。
SDKの入れ替えだけで改善したのであれば、２点の内のどちらかが「S0の0Mbps問題」に対応するものだったのかもしれません。（デバイスの初期化時に周波数設定をする修正がありますが、それかもしれません。）
残り１点はCPUとPCIデバイスのメモリアクセスに関する修正ですが、これに対応するVirtualPTバージョンも今晩中に（ベータ）リリースしたいと考えています。
「S0の0Mbps問題」の件、ボード（チューナでは無く）のオープン毎にT0のスリープ解除＆スリープを行えば改善するらしいということですね！ただ、当方で状況を再現出来ていないので、テストをどうしたら良いかという点が悩ましいところです。
ご対応ありがとうございます。
SDK0.96に入替、１０回程度起動終了を繰り返してみました。
現象は発生しないようです。
試したのはこれだけですがとりあえず連絡まで
SDK0.96対応の頑張ってください。
チューナーデバイスを初オープンする際に SetTunerSleep でスリープにする前に
一旦無効にするだけで良いみたいです。
// 一旦スリープ解除
SetTunerSleep(..., ..., false);
...
...
// スリープ
SetTunerSleep(..., ..., true);
あと、当方ではTVTestでしか上記現象は確認できてないですね、今のところ。
利用ソフトウェア実装依存で行儀の悪いコードがあるのかもしれないです。（詳しく追ってないですが・・・）
アースソフトからSDKバージョン0.96が公開されているようですが、そちらを使用した場合、現象が変化しますか？
また、SDKバージョン0.96で改善された不具合に対応するには、アプリケーション側の変更も必要になるようなので、SDKバージョン0.96に対応したものをとりあえずベータバージョンとして公開したいと思います。（出来れば今晩公開したいと思います。）そちらを使用した場合にも、現象が変化するかお知らせ下さい。
・時間帯に関しては、発生率が変わるだけで必ずおきています。
・発生時は、D・E・S：0のままで
信号レベルのMbpsが0、dBはそれなりの数値。
・LNB電源関連は、
先に液晶テレビをＯＮ（LNB供給）で実施、さらにVirtualPTのLNB電源OFFも試していましたが、NG
LNB電源の可能性は低いと思っていました。
・S1、S2の優先は、
S1優先で1番目に発生。S2優先で2番目に発生。
S1で発生しているのは間違えないようです。
・とおりすがり様の言う「PT3Ctrl」改良版で再現しなくなりました。
（改良前では、S1は再生できませんでした）
・評価として、
mod6にてTvTestでPT3のS0側使用した際のエラーが解消するよう
0Mpbs病が解消した
で、今回の現象のように思います。
お知らせ頂いた現象ですが、当方では再現出来ませんでした。「一度でもT0のスリープを解除すれば」とありますが、この「一度」とはいつからいつまでの間に「一度」なのか分かりますか？（例えば、デバイス装着後一度、ＰＣ電源投入後一度など）その現象は必ず発生するものなのでしょうか？何回かに一度の割合で発生するといったものでしょうか？当方で確認する為の手段として、例えばこのようにすれば再現するといった手段は無いでしょうか？
データが来ないみたいです。
一度でもT0のスリープを解除すれば
発生しないようです。
PT3Ctrlに上記のパッチがあたっているみたいです。
ご参考までに。
当方で簡単に確認してみましたが、現象を確認できませんでした。初回というのはチャンネル切り替えなどしていない状態で衛星が選局されているということでしょうか？あるいは、TVTestが1台しか起動していない場合は、衛星のどのチャンネルに切り替えても表示されないということでしょうか？どちらにしても地デジでは現象が発生しないということですね？後、時間帯で異なる可能性があるとのことですが、全く現象が発生しない時もありますか？もしあるということであれば、この時間には確実（あるいは高確率）に発生するといった条件はありますか？
現象が発生している時ですが、D(ドロップ)やS(スクランブル)がカウントされますか？信号レベルのdBやMbpsの値はどうなっていますか？
LNB電源関連が怪しいと思うのですが、VirtualPTの設定＞チューナー設定で、S1だけ優先度を高くした状態、及び、S2だけ優先度を高くした状態で現象が変わりますか？PT2であれば分波機などの可能性もあると思いますが、PT3でS1、S2で違う状態なら外部の可能性は低いと思います。後、アースソフトのサンプルプログラムでS1だけ受信状態、及び、S2だけ受信状態にした時にも同様の現象が出るなら、アースソフトに確認した方が良いかもしれません。
又、VirtualPTのver1.14を公開しておりますが、そちらを使用した場合、現象に違いが有りますでしょうか？
PT3で使わしてもらっています早速ですが、
PT3のファームウェア:0x03では、発生していなかった（おそらく）
ファームウェアを0.95(0x04)にアップデートしたところ、
・初回にBSCSで起動すると表示しない現象が発生します。
ただし、別で地デジを表示するとBSCSも表示し始める。
・BSCSを2つ表示したときは、2つ目は表示する。
この場合も地デジを表示すると１つ目も表示する。
・初めから表示する時もあり確率的には半々ぐらい
時間帯（電波状態？）で違うようにも・・・。
のような感じです。
環境設定の問題かもしれませんのでご教授お願いします。
OS:Win7(32)
TVTest:Ver.0.7.23(x86)
PT3:ドライバ:0.92 SDK:0.95 FPGA回路:0.95(0x04)
VirtualPT:1.13(LNBをON CATV,VHF解除あとは初期値)
BonDriver_VTPTは、２種類地デジ・BSCS用のみの設定
当方で簡単に確認してみましたが現象を確認できませんでした。詳しく調べますので以下の内容を教えてもらえないでしょうか？後、チャンネルスキャンとはEPG取得のことですね？
1．現象は必ず発生するか？発生する場合としない場合があるか？
2．VirtualPTのバージョン
VirtualPT.exeを右クリック→プロパティ→詳細タブで確認できます。
3．VirtualPTの設定
VirtualPT.exeのあるフォルダのVirtualPT.iniの内容
4．BonDriver_VTPTのバージョン
BonDriver_xxxx.dllを右クリック→プロパティ→詳細タブで確認できます。
5．BonDriver_VTPTの設定内容
BonDriver_xxxx.dllのあるフォルダのBonDriver_xxxx.iniの内容
PT3 SDK0.95 / driver 0.92 / FPGA 0x04
Win7 x64 / VirtualPT x86 / EDCB9.46 x86
の環境で利用させていただいているのですが、
EpgTimer_bonからチャンネルスキャンを実行し、
S0,S1,T0,T1のEpgDataCap_Bonを起動すると、そのうちの一つが、
「EpgDataCap_Bon.exe は動作を停止しました。」と表示され、強制終了してしまいます。
設定は「VirtualPT設定例:基本編:④EpgDataCap_Bon設定」の通り設定しています。
不具合であるのか設定が悪いのか、解決方法はありますでしょうか。宜しくお願いします。
ただ、PT3のSDKやドライバがまだ安定していないようなのでご注意下さい。近いうちにアースソフトから対策版が公開されるかと思います。
結果は問題なくチャンネル取得できました。
これでPT3でも安定した環境が構築できそうです。ありがとうございます。
EpgDataCap_Bon 9.46でチャンネルスキャンが出来ない件、当方でも現象が発生することを確認しました。原因は、PT3の場合チャンネル変更からシグナルレベルが取得可能になるまでに多少時間が掛かるようで、その為にチャンネルが受信できないと判断されるようです。
次のバージョン(ver1.13)で、シグナルレベル取得処理を改良したバージョンをリリース致します。ベクターは申請から公開までに数日掛かる為、ベクター公開までの期間、以下のURLからもダウンロードできるようにしておきますので、お急ぎであればこちらをご利用下さい。
http://www.do-ma.info/VirtualPT/VirtualPT_0113.zip
epgdatacap_bon 9.46でチャンネルスキャンを試みるも、チャンネル取得に失敗してしまいます。設定に注意点はありますでしょうか？ PT2利用時は問題は起きなかったのですが・・・
ちなみに視聴は問題ないです。
お問合せありがとうございます。
放送大学ラジオは「デジタル音声サービス」に分類されます。WNI910は「データサービス」に分類されます。この判定は放送受信時に行うので、チャンネル設定等を修正しても改善されません。
サービス別受信設定に「デジタル音声」＆「データ」を追加することで改善されると思いますので、要望として受付けさせていただきます。
放送大学ラジオはラジオ、WNI910はデータ放送と認識されているためなのか、
サービス別受信設定で「その他」をチェックしないと受信できません
ですがそうするとデータ放送も含まれてしまうので伝送量が増えてしまいます
チャンネル設定を弄ればできそうですがどこに保存されているのか教えてください
まだたくさん要望がありますがこれが解決したら書こうと思います
デカルチャーを使っています
よろしくお願いします
情報提供誠にありがとうございます。
当方でも同現象が発生することを確認しました。これについては、恐らく近いうちにアースソフトが対策するのではないかと考えられる為、アースソフト待ちにしたいと思います。もし、なかなか対策されないということであれば、VirtualPT側で何らかの対策を行いたいと思いますが、SetTransferEnabled(?,?,false)を呼ばずにSetFrequencyを呼んだ場合にも不具合があるようなので、アースソフトが対策されることを期待します。
2TS同時視聴中に、片方でチャンネル切り替えを繰り返す0Mbpsになってしまう問題ですが、
VirtualPTでも同様の問題が発生しています。
恐らく根本的な原因はハードウェアにあると思うのですが、
対症療法としてチャンネル切り替え時の処理においてSetTransferEnabledを呼び出さない
ようにすると不具合の発生頻度を軽減できるようです。
実際にBonDriver_PT3-STにおいて上記のようにソースコードを変更し、
不具合の発生頻度の軽減を確認できました。
VirtualPTでは対応可能でしょうか？
よろしくお願いします。
ご協力頂きありがとうございます。お手数をお掛けしますがよろしくお願いします。
EBCBで録画したところ、ドロップやスクランブルカウントが増え続けるもののtsファイルを見てみると正常に再生できました。
tvtestではスクランブルカウントが増え画面が映りませんでしたが、同じく録画したtsファイルは正常に再生できました。
PT3・PT2で実験しましたが、同じ結果でした。
近日中にメールにてtsデータを送りますのでよろしくお願いします。
当方、J:COM HDを受信できないので、スクランブル解除していないデータを30秒程保存していただき送っていただけないでしょうか？受け渡し方法をひと目に付く場所に公開したくないということであれば、doma@do-ma.info宛にメール下さい。又、適当な受け渡し方法が無いという場合も返信メールアドレスを記入の上、doma@do-ma.info宛にメールをお願いします。
tvtest単体でのECM処理やVirtualPTを通してtvtestでのECM処理は成功しています。
ECM処理不可チャンネルはJ:COM HDです。他民放やBSCSはすべていけますが、上記１チャンネルだけ解除されません。
よろしくお願いします。
VirtualPTをご利用頂きありがとうございます。
ver1.10で（というかver1.03以降で）PT2X2向けの修正などはしていませんが、なぜでしょう？
ご期待頂きありがとうございます。しかし、録画や番組表について、機能の構想はあるのですが着手する予定は今のところありません。開発の難易度もあるのですが、スクランブル解除と録画を１つのアプリケーションで行っても良いのか？といった点に引っかかっています。
ご質問のスクランブル解除の件ですが、VirtualPTではb25decoder.dllは使用しておりません。独自に最適化したスクランブル解除機能を実装しており必要十分な性能を既に実現できていると考えています。これ以上の高速化は考えておりません。（このサイトやReadMeの「スクランブル解除について」を参照して下さい。またver1.07からSSSE3に対応しており該当CPUではさらに1割程度高速化していると思います。）
お世話になります。
DECULTURE PT2×2で
VirtualPT1.10 win7(32) ドライバ100 SDK102の環境で新BSチャンネル・CS映るようになりました。
VirtualPT1.10開発して頂きありがとうございました。
tvrockが更新停止した今、後継にあたる候補はVirtualPTに違いないと陰ながら応援しております。
質問になりますがスクランブル解除の更なる高速化にはb25decoder.dllがネックになるかと思われます。かなりシンプルなソースで尽くせる手はないようにも見えますが、今現在 何らかの方策はお考えでしょうか。
ご要望ありがとうございます。
やるとしたらVirtualPTのおまけソフトとして付加する形式になると思います。一定量のECMデータの処理に掛かった時間を計測するようなプログラムになると思いますが、ECMデータをどうするかが課題になります。2012年6月のECMデータを使用したとしたら、1年後とかでもベンチとして成立すのか、あるいは何らかの方法で最新のECMデータを使用するのか？検討事項がありますが、ご要望として承らせていただきます。
あまり有意義ではありませんが、気持ちの問題として手持ちのB-CASカードで最速の物を使いたいと考えています。
VirtualPTにベンチマーク機能を組み込んで頂くか、multi2_bench（http://bit.ly/MDI3Ua）のようにツールとして公開して頂けると大変有り難いです。
解決されたとのことで安心致しました。
ちなみに、VirtualPTは詳細ログをオフにしたものを一般公開しています。サービス実行中のインフォメーションはGUIを持たない為、イベントログに出力します。（イベントビューアーで確認できます。）タスクトレイに常駐している際のインフォメーションはメッセージボックスで通知しています。
ずっと前に設定したPCだったのですが、同容量のドライブが２つあったので
もしやと思って設定変更してみると無事に動きました。
junction.exe で、D:\ -> G:\home\
として Dドライブを使っていたので、G:\home\program\EarthSoft-PT2\VirtualPT\x86\VirtualPT.exe で
起動したら無事に起動できました！
お手数かけて申し訳ありませんm(_ _)m。
詳細なログを取るモードとかって実はないですよね？(汗;
エラー番号から、ファイルアクセス関係のエラー？ということまでは認識していたのですが
じゃあOSのエラー番号なのに管理ツールのエラーログに出ないのはナゼ？ってところで
ずっと詰まってました。
VirtualPT\ImagePathの値ですが、
「D:\program\EarthSoft-PT2\VirtualPT\x86\VirtualPT.exe」
になっています。
実際に存在しているフォルダと同じです。
お問合せありがとうございます。
エラー80070003ですが、フォルダ関係のエラーのようです。VirtualPT.exeを格納しているフォルダはどのようになっておりますでしょうか？レジストリの「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VirtualPTSvc」内の「ImagePath」にVirtualPT.exeのフルパスがセットされていると思いますので、その値をお知らせいただけないでしょうか？
VirtualPTを起動するとタスクバーには入るのですが、右クリックからサービス登録しても
「サービスの開始中にエラーがありました。(80070003)」
と出てサービス開始できません。
WinXP Pro/SP3 で PT2です。BonSDKは２０１です。
WinUpdateはすべて適用してあります。
管理ツールのシステムエラーログにもアプリケーションエラーログにも事象が出てきてないので
判らないのですが、何か思い当たるフシなどありませんか？
BonDriver_PT-STやSpinelの場合は何の問題もなく動くのですが･･･
(もちろんVirtual-PT時はSpinelも終了させてやってみました)
よろしくお願いします。
お世話になります。
ご回答ありがとうございます。
それでは、後ほどメールさせて頂きます。
ネットワーク使用率に変化が無いとすると、通信処理以外に問題がある可能性もあります。ただ、ジャンボフレームで改善したとのことから、やはり通信処理の可能性が高いように思われます。当方でHyper-V環境（2008R2を所持していない為、ホスト側に2008(x64)、及び、仮想マシン側にVista(x64)を「内部」仮想ネットワークで接続）で、試してみたのですが現象を再現できませんでした。
そこで、確認プログラムを実行していただき、結果（ログファイルなど）をお知らせいただくということは可能でしょうか？複数回お願いする可能性があり、１本目は直ぐに用意できますが、２本目以降は各１週間ほど用意に時間が掛かる可能性があります。もちろん、即座に確認を強要するものではなく、たかちん様の都合のよい時に確認していただいて構いません。
もしご協力いただけるということであれば、メールでやり取りさせていただきたいのでdoma@do-ma.info宛にたかちん様の連絡先メールアドレスをお知らせいただけないでしょうか？
お世話になります。
１．
下記にて確認致しましたが同現象でした。
TVTest(x64)ver.0.7.21
EDCB9(x64)ver.9.46
２．
変化なし。
３．
Drop開始時には変化なし。
４．
ご案内頂いたバージョンでも再現しました。
追加で一つ判明しました。
別セグメントにある物理PC(無線LAN)からTVTestにてアクセスしたところしばらくしても大量なDropは発生しませんでした。
母艦と同一セグメント上にある録画サーバ以外のPC(10GbE)からアクセスしたところDropが発生しました。
高速なNICだと発生しているような感じです。関係ありますでしょうか・・・
ver1.07以前に発生していた状況と似ているようにも思われます。ver1.08で改善した原因の他にも原因があるのかもしれません。何点か確認していただきたい点があります。お手数ですが以下の内容をご確認いただけないでしょうか？
１．EpgDataCap_Bon10以外のプログラムでも発生するか？もし、録画サーバー側でTVTestやEpgDataCap_Bon9が動作するならそれらでも同じ現象が発生するか？
２．Microsoft Security Essentialを停止させた場合に、現象が変化するか？
３．タスクマネージャを起動していますが、ネットワークタブのグラフはどうなっていますでしょうか？現象発生までは、ほぼ一定量の通信量だと思いますが、現象発生後も通信量は変わらないか？変化しているか？
４．現在、次のバージョンのリリース作業を行っているのですが、新しいバージョンで通信処理にも関係する修正を行っていますので、そのバージョンで現象が変化するか？
新しいバージョンを
http://www.do-ma.info/VirtualPT/VirtualPT_0109B1.zip
からダウンロードして、サービスを停止後、VirtualPT.exe及びBonDriverを入れ替えてどの様になるかお知らせ下さい。
お手数をお掛けしますが、お調べいただけると助かります。
母艦側にPT2×2枚実装されてます。
母艦側にVirtualPTを入れておりそこからTCP-IPで録画サーバにて録画してます。
お世話になります。
早速の回答ありがとうございます。
１．CPU・OS・メモリ量等
母艦
OS:Window Server 2008 R2 SP1(x64)EnterpriseEdition
CPU:Intel Xeon E5620 ×2CPU(8Core)
MEM:32GB
録画サーバ
OS:Window Server 2008 R2 SP1(x64)EnterpriseEdition
CPU:母艦のHyper-V上
MEM:4GB(ダイナミックメモリな為、上限は母艦MEM)
２．VirtualPTのバージョン
VirtualPT.exeを右クリック→プロパティ→詳細タブで確認できます。
1.08(x64)
３．BonDriverのバージョン
EpgDataCap_Bonでお使いのBonDriver_xxxx.dllを右クリック→プロパティ→詳細タブで確認できます。
1.8.149.15
４．EpgDataCap_Bonのバージョン
人柱版10.66
５．チャンネルモード(互換or拡張)
どちらでも現象発生
６．セキュリティ製品を使用しているか？使用している場合は製品名
Microsoft Security Essential
７．どの様な現象が発生したのか？
4,5分は問題ないがその後から急激にDropが発生。
以下、3分ほどおいてから録画したものです。(しばらくおいておきます)
http://nonexist.ddo.jp/temp/flv.asp?file_name=/temp/VirtualPT.mp4
地デジとBS/CSのDLLを分けたりチューナ毎にも分けたりもしたのですが同現象が出てしまいます。
また、母艦と録画サーバ間のNWは内部的なNICでつながっており10Gbリンクになってます。
情報としてお役に立てれば幸いです。
ドロップが発生したとのことですが、以下の内容を教えてもらえないでしょうか？
１．CPU・OS・メモリ量等
２．VirtualPTのバージョン
VirtualPT.exeを右クリック→プロパティ→詳細タブで確認できます。
３．BonDriverのバージョン
EpgDataCap_Bonでお使いのBonDriver_xxxx.dllを右クリック→プロパティ→詳細タブで確認できます。
４．EpgDataCap_Bonのバージョン
５．チャンネルモード(互換or拡張)
６．セキュリティ製品を使用しているか？使用している場合は製品名
７．どの様な現象が発生したのか？
「瞬間的に数フレームドロップ後、改善」、「ある時点から全てドロップ」、「ある時点から再生が細切れになる」等、詳しく教えてください。
当方もTCP-IPにてEDCBでしばらく受信しているとドロップが発生しました。
DMAバッファサイズ(変更前2×4MB)を変更(変更後4×4MB)→改善せず
ジャンボフレーム(変更前無効)を変更(変更後9014MB)→改善
ただ、当方の環境にてジャンボフレームを有効にすると他のアプリに盈虚が出てしまうことがわかったため戻しております。
また、Spinel環境ではドロップがないことは確認できてます。
非常にいい機能が備わっているので是非使いたいと思ってますので是非がんばって下さい。
その他必要な情報あれば提示させて頂きます。
丁寧なお返事ありがとうございます。
そうですか。Spinelで実現できる機能のうちでVirtualPTで実現できないものがあるというのはファンとして残念ではありますが、致し方ないですね。
今後ともVirtualPTに期待しています。
まず、BonCasService，BonCasProxy等のBonCasLink関連につきましては、VirtualPTではサポート対象外と考えております。BonCasLinkではICカードリーダ関連の関数の全てに対応しているわけではなく、特定のプログラムが使う一部の関数にしか対応していない為、VirtualPTが必要とする関数の一部では機能しないものがあるようです。なので、BonCasLink関連は特定のプログラム向けであり、汎用的なものではないと考えております。
また、VirtualPTの機能として、ネットワーク越しにB-CASカードを一元管理する機能の構想はありますが、プログラムの難易度や必要とする方がどれだけいるか等も考慮すると、今のところ対応のメドは立っていない状態です。（B-CASカード自体の処理能力が低い為、あまり考える必要は無いのかもしれませんが、不特定多数の方でB-CASカードを共有できるという点もちょっと躊躇させる点です。）
将来的に対応する可能性は有りますが、即座にご期待に沿えずに申し訳ありません。もしかしたらBonCasLinkを改善してくださるつわものの出現のほうが早いかもしれませんね！
ところで、一枚のB-CASカードをWAN越しに複数拠点のチューナー＋VirtualPTで共有するにはBonCasServiceとBonCasProxyを使うのが一般的じゃないかと思うのですが、親となるマシンではICカードリーダーとしてBonCasProxyとUSBカードリーダーの2個が見えることになります。当方ではなぜかこの状態でBonCasProxyをICカードリーダーとして動作させることができません。選択はできるのですが、VirtualPTでスクランブルが解除されません。一覧表示からもBonCasProxyが消えたり現れたりします。リモートデスクトップは使用していません。別の方がBonCasServiceを別マシンにしてBonCasProxyだけの状態であれば成功すると書かれていたのが気になるのですが、もしかしてVirtualPTでは親となる1台でBonCasServiceとBonCasProxyを兼ねる事はできないのでしょうか？
もしそうであるなら、これは要望なのですが、BonCasService+BonCasProxyを使わなくても複数のVirtualPT間でB-CASを共有できるような機能をご検討いただけないでしょうか？B-CASまで含めた仮想的なチューナ機能をVirtualPTに集約できればVirtualPT+（TVTest、EDCB）と構成がすっきりします。
設定については、リモートデスクトップではない、通常のデスクトップ上で行っていただければ、BonCasLink関連は必要ないと思います。
どのようなことでお困りなのか詳しく分からないのですが、「そういうことではない」、「改善しない」などありましたら、詳しい状況をお知らせ下さい。
現在、リモートデスクトップ接続のためだけにBonCasServiceとProxyを使用しています。
VirtualPTの設定画面では、設定アプリを起動したユーザの権限で使用可能なカードリーダを検索していると思うのですが、
これをサービスが動いているSYSTEM権限で検索するようにできないでしょうか？
そうすればリモートデスクトップ接続で切断されてしまうカードリーダが見えるようになり、BonCasServiceが不要になるのではないかと考えております。
よろしくお願いします。
通信不具合の原因がセキュリティ製品の可能性もあるかもしれないとは思っていたのですが、そうでしたか。もしかしたらVirtualPTの通信を無条件で通すような設定をしたら改善したかもしれませんね。ただVirtualPTを100％信用するのは危険でしょうから、それは現実的では無いのでしょうね。
新バージョンの動作結果もお知らせ頂きありがとうございます。今のところ大丈夫みたいですね。当方のテストだけでは実際の環境で本当に改善されるのか不安だったので、お知らせ頂き安心致しました。もしまた何かありましたらご遠慮なくお知らせ下さい。この度は検証にもご参加頂き誠にありがとうございました。
新しいバージョンがリリースされたということで、早速試してみました。
と、その前ビットレートが低下する原因について調べていたのですが、
どうもSymantec Endpoint Protection(SEP)が悪さをしていたようです。
Client、Serverの両方に入っておりましたが、
SEPがOFFの状態ではビットレートの低下は無く、
ONにすると途端にビットレートが低下しました。
SEPはBase Filtering Engineを利用しているので、
通信に何か影響を与えていたのかもしれません。
話は戻りまして、SEPをOFFにするわけにもいかずビットレート低下の状態にしていたのですが、
ver1.08を導入したところビットレートが低下することが無くなりました。
8ch同時に視聴しても今のところ問題はでておりません。
このまましばらく利用して再発しないか確認したいと思います。
サービスの再起動ですか、なかなか難しいですね…。情報提供は何にしてもとてもありがたいです。誠にありがとうございます。
また、只今、次のバージョンをVectorに申請中なのですが、それが公開された後で、「通信不具合が改善するかもしれないバージョン（ベータ）」を公開する予定ですので、ぜひそちらも試してみてください。
VirtualPTがインストールされたサーバを起動した直後は事象がよく発生するのですが、
何回かVirtualPTサービスを再起動させると事象が発生しにくくなります。
また事象が発生したとしても、最初に報告した時と違い、数秒たてば視聴可能になります。
やったことはサービスの再起動のみで、ネットワークなどの設定値は触っておりません。
ここまで書いてなんですが、こちらの環境固有の現象かもしれません･･･。
Linuxの件、現象再現の為のアドバイスで、Linuxでは通常そのような設定では使わないので不具合とは関係ないということですね。
データ長の件ですが、VirtualPTプロトコルでは何層かに分かれており、一番下の層の送信側が、データを加工して流すことで、受信側でどのような区切りで受信したとしても復元できるようにしています。(区切り文字(0xff)から区切り文字(0xff)の間が送信側で1パケットとして送信されたものとして処理。もし送信時に部分送信されるようなことになっていたとしたら最後の区切り文字が欠落することになりますが、次のパケットの先頭の区切り文字で、前のパケットが終わったことを認識します。)この層では32KBまでの可変長データを扱えるように設計しております。その１つ上の層では、パケットヘッダなどから文字化けやデータ長などの整合性のチェックを行っています。
一部しかデータが受信できなかった場合のエラー処理ですが、ストリームデータの場合は一度だけ再送処理を行い、それでもだめなら、除外します。
WSASend関数の件、ご指定のURLの内容とほぼ同じものを翻訳して保有しているのですが、私の理解力が足りない為、引数で指定した変数に実際に受け付けられたサイズがセットされるところまでは分かるのですが、戻り値などであいまいな点があり、実際に再現して確認したいところなのですが、当方ではなかなか再現出来ないので、わらにもすがる思いでお聞きしてしまいました。申し訳ありませんでした。
その２
また長文です。ごめんなさい。
WSASend関数の戻り値についてですが・・・
送信バッファに渡せたサイズは、lpNumberOfBytesSentが指し示す先にセットされます。
ちなみにWSAEMSGSIZEはデータグラムソケット（UDP）とかの場合で、最大サイズを
超えている場合に返されます。この場合エラーですので1Byteも送信されません。
TCP -> パイプに水を流すようなイメージ
※ 1回目の送水と2回目の送水の境目は判らない
※ まだパイプに水が残っているかもしれない
UDP -> 小包のイメージ
※ 他の小包とはくっつかない
※ 一部のみ送信されることは無く、丸ごと送るか送らないか
で、WSAEMSGSIZEは小包のサイズが大きすぎて取り扱えないというエラーです。
WSASendのリファレンスです。
http://msdn.microsoft.com/en-us/library/ms742203(VS.85).aspx
その１
また長文です。ごめんなさい。
> 通信途中にLinux等を経由した場合にも起こりえるとのことですが、※以下略
ごめんなさい。言葉が足りませんでした。
Linuxには帯域を絞る機能がありまして、任意の帯域幅に（おおよそですが）設定できます。
間にLinux機がいれば・・・と言うのは、このLinux機で帯域を1Kbpsとかに絞って
送信バッファFullを起こした後に、制限解除すれば・・・という意図でした。
> 通信負荷の高い状態にしてしまえば、再現できるかもしれませんね。
そうですね。
言われてみれば簡単な話でした。
シンプルに、別のPCに向けて大量送信するプログラムを沢山実行していれば再現できるかも
しれません。
ブロックの分割・結合についてですが、データ長は固定なのでしょうか？
以前の50番の書き込みで・・・
> ただ、VirtualPTではパケット最大長を32KBで送受信しています。
とありましたので任意長かと思っていました。
しつこいようで申し訳ありませんが、一部しか受信できなかったときの判定は
どのようにされていますか？
ユーザーレポートでの状況から、一部分しか受け取れなかったことがきっかけで
以後正常に動作していないように見えましたので、このあたりの処理になにかあるのかも
しれません。
他のアプリの送信負荷が高い場合にバッファの空きが少なくなる可能性があるわけですね。盲点でした。試しに大きなデータ(1GB)を一気に送信してもすんなり送れてしまったので、どうしたら一部だけが送信される状態を発生させられるか首をかしげていたのですが、通信負荷の高い状態にしてしまえば、再現できるかもしれませんね。
通信途中にLinux等を経由した場合にも起こりえるとのことですが、当方ではハブしか無かったのでそれで再現できなかった可能性はありますね。当方Linuxの知識はお子様レベルですしハードウェアの調達も現状難しいのでLinuxを介したテストは厳しいのですが、Windowsサーバーにルータ機能を追加すれば同様のテストが出来るかもしれません。
受信時にブロックが分割・結合されることには対応しており、解説いただいた方法とは違いますが、VirtualPTでは送信時にパケットの先頭と最後に区切り文字(0xff)数バイトを付加し、データ中に区切り文字(0xff)が無くなるような変換をしてから流すので、受信側では送信時の状態に復元できますし、一部しか受け取れなかったとしてもエラーとして処理するようになっております。なので受信時の仕組みは問題ないと思います。
あと、都合のいい話なのですがお分かりになるようでしたら教えていただきたいことがあります。送信にC言語のWSASend関数を使用しております。一部だけ送信された場合に、関数の戻り値が0なのか、戻り値がSOCKET_ERRORでWSAGetLastErrorにWSAEMSGSIZE？等がセットされるのか、疑問に思っているのですが、現象を発生させられなかった場合のために教えていただければ幸いです。
※ 仕組み的なことを説明する為に、細かいことも含めて書いています。
※ 長文でごめんなさい。
再現方法についてですが、環境や他のアプリにも依存するのでなかなか難しいのですが、
帯域を可変出来れば可能かもしれません。
例えば、間にLinux機を置いてFW若しくはローカルルーターとし、帯域幅を絞る（そして元に戻す）
アプリ側の責任範囲としては、送信バッファに余裕が出来たら復旧できれば良いと思います。
基本的に送信バッファFullはしばらくすると解消します。
他のアプリが大量に送っていたとしても、送信できる機会は回ってきます。
もちろん、一気に送りたいサイズ分受け取ってもらえるかどうかは判りませんが・・・
今回の事象はユーザーレポートからすると、しばらく経っても復旧できていないようです。
なにか制御に問題があるのかもしれませんね・・・
通信系のアプリの場合、相手がいますし中継するモジュールやドライバ、H/W機器も沢山あります。
色々な細かいトラブル（混雑・パケロス・CRCエラー・再送等）が頻繁に発生しています。
また、おのおのの都合の良いタイミングで都合の良い様に処理されてしまいますので、
受け取ったデータは最初は未知のものとして扱い、慎重に確認してから使った方が良いと思います。
土台がしっかりしていないと色々面倒くさい事になるので、正確に丁寧に確実に処理するようにすると
ハッピーになれます。
「急がば回れ」です。
最後にもう一度・・・・長文でごめんなさい・・・
以下、C言語での一例ですが・・・
１．組み立てバッファに追加で読み取り（組み立てバッファの空きサイズ分だけ読み取り要求）
２．組み立てバッファ内にあるデータからマーカー"\x00**VirtualPT1**\x00"を探します。
見つからない場合、１へ
３．共通ヘッダを受け取っているか計算します。
マーカー位置＋共通ヘッダサイズ(24Byte) <= 組み立てバッファ内のデータサイズ
受け取っていない場合、１へ
４．共通ヘッダのデータサイズを取得し、全データを受け取っているかを計算します。
マーカー位置＋データサイズ <= 組み立てバッファ内のデータサイズ
受け取っていない場合、１へ
５．全データを受け取っているので、データを切り出す
６．処理したデータを組み立てバッファから削除し、前に詰める
マーカー位置＋データサイズ以降のデータを組み立てバッファの先頭に移動し、
組み立てバッファ内のデータサイズ -= データサイズ
７．１に戻る
注意点としては、（テキスト文字列ではなく）バイナリに対しての処理なので、文字列検索系の
関数を使用しないこと（\x00で終端されている保証がない）と、常に有効なサイズを意識して、
無効なデータ（未初期化値や昔のデータ）を取得しないこと等があります。
そして重要なことなのですが、これらは双方向通信の場合、両方のアプリに実装する必要があります。
色々なやり方がありますが、例えば・・・
offset size
------ ----
0 16 \x00,'*','*','V','i','r','t','u','a','l','P','T','1','*','*',\x00,
16 4 データサイズ(DWORD) ※マーカーのサイズを含む
20 4 データ種別('TSDT','CHCG') ※文字終端\x00は入れない
ここまで共通ヘッダ
以後、個別データ。TSDTの場合・・・
24 4 チャンネルID(DWORD)
28 4 信号レベル(DWORD)
32 4 TSデータサイズ(DWORD)
36 xxxx TSデータ（任意の長さ）
※ 「"\x00**VirtualPT1**\x00"」はVirtualPT通信規約Ver.1のつもりです
とした上で、受信側でマーカーを基にデータを処理します。
ただし、どのタイミングで区切られるか判りませんので、ヘッダサイズも含めた最大送信長の
２倍のサイズの組み立てバッファを持って、受け取ったデータを組み立てます。
これらを踏まえて、コメントさせていただくと・・・
> 現状では、リターンコードがＯＫかつ送信サイズが要求サイズ＝受取りサイズの場合のみ成功とみなし、以外はエラー扱いとしていたので、そのような場合、エラー扱いとしておりました。
先にご説明させていただいたとおり、データグラムではなくストリームですので
この場合、「一部」が受信側に送信されてしまいます。
受信側できちんと中途半端なデータを識別して弾いていればOKですが、先に書いたように
TCPには一連のデータに区切りはありませんので、送信時に自分でマーカーをデータの中に
入れて、そのマーカを受信側で見つけて頭出しをした上でサイズチェックをする必要があります。
ただし、一部分のデータだけ送られてきたのか、単純に受信中で次の読み取りで後半が来るのかは
区別が付きませんので、次のマーカーを見つけるまでは判断できません。
ですので、途中までしか受け取ってもらえなかった場合は、エラー扱いにするのではなく、
続きから送り直した方がシンプルになります。
単純な垂れ流しの場合は別ですが、バイナリストリームの場合、基本的には自分でヘッダを
規定して送るパターンが多いです。
仕組み的なことを説明する為に、細かいことも含めて書いています。
長文でごめんなさい。
そして、お役に立てるのでしたら光栄です。
開発頑張ってください。応援しています。
ご質問にお答えする前に、まず仕組みというか概念の説明をさせていただくと・・・
プロトコルスタックの送信バッファについてですが、概念的なお話をすると
たとえ2Byteの送信要求でも1Byteしか受け取ってもらえないかもしれません。
（実際にはOS側の管理上の都合でもう少し大きなサイズでないと受け取ってしまいますが）
なぜならそのOS上の全てで送信バッファを共有しているからです。
他のアプリなどが大量の送信をしていると送信バッファは混雑します。
また、TCPはストリームなので32KByteを2回送っても、受け取り側は16KByte＋32KByte＋16KByteと
3回に分けてアプリに渡してくるかもしれません。
（真ん中の32KByteには両方の一部が含まれています）
極端なたとえをすると1Byteずつ渡してくるかもしれません。（概念的には・・・ですが）
ただのパイプなので元々データの区切りはありませんし、OS等も自分の都合で好きなように
送ってきます。
保証されているのは、Byte単位であることと各Byteの順番がそのままであることだけです。
一連の流れの中で区切りを見つけて自分でデータを切り出すのはアプリ側の仕事になります。
逆にUDPはデータグラムなので、送ったサイズがそのまま届きます。
小包みたいなものです。
その代わり確実に届く保証はありません。
アプリ側が自分で検知して再送処理をする必要があります。
そしてジャンボフレームでは再現率が下がる理由についてですが、単純に送信バッファが
増えるからだと思います。
こちらでは、お手上げに近い状態になっていましたので、些細なことでもお知らせいただけると大変助かります。
これまで、寄せられたコメントからジャンボフレームに関連したものと思い、その辺を当方でいろいろやってみたのですが、現象を再現出来ていませんでした。ご指摘いただいたとおり、送信時に「一部だけ送信できた」という状態のチェックは行っておりませんでした。現状では、リターンコードがＯＫかつ送信サイズが要求サイズ＝受取りサイズの場合のみ成功とみなし、以外はエラー扱いとしていたので、そのような場合、エラー扱いとしておりました。
これまで寄せられた情報から、必ずそうなるわけではなくて、最初は大丈夫だが数秒から数十秒すると現象が発生しはじめるように思われます。さらに、当方では発生していないように、現象が出る環境と出ない環境があるものと思います。当方でも現象を再現する為にはどのようなことをすれば良いと思いますか？
ちなみに、VirtualPTでは仕組み上、受信側が受け取ったことを確認してから次を送るので、送信側・受信側ともにプロトコルレベルでのバッファフルは起きないと思います。（バグが無ければですが！）
OSのプロトコルスタックの送信バッファとか受信バッファが溢れていませんか？
APIやメソッドで32KBの送信要求出しても4KBしかOSが受け取ってくれないことがあります。（バッファが一杯とか）
APIやメソッドの戻りで実際にOSに渡したバイト数が帰ってきていませんか？
要求したサイズと受け取ってもらえたサイズが違う場合、続きからもう一度送る必要があります。
また逆の話として、受信側アプリで長時間受け取らないと受信バッファが溢れてしまいます。
そうなると送信側の送信バッファのデータがなかなか消えないことになるので送信バッファが溢れやすくなります。
基本的に、送信側で送信時にOSに渡すことが出来たサイズを管理することと
受信側で速やかに受け取ることが出来ればすんなり流れていくと思います。
そんなこととっくに知っている！という事であればただの落書きだと無視してください。失礼しました。
少しでも糸口になればと思い書き込みさせていただきました。
ネットワーク通信の不具合の件、複数の方からご指摘いただいておりますが、当方では現象を再現出来ていないため、保留状態になっております。こちらの希望としては、より多くの方から、より多くの情報をいただけると助かります。「こうすれば現象が発生するのに！」といった情報であればより助かります。
ただ、VirtualPTではパケット最大長を32KBで送受信しています。下位のプロトコルで実際に通信できるサイズに分割されるはずですが、分割されないようなサイズ(1KB程度)にしたら、もしかしたら改善するのかもと考えています。
現象を再現出来ていないため、それを実証する術がないのですが、試しに設定で変更可能なバージョンを公開してみようと思います。
なお、サーバにて自分自身へTCP-IP接続の場合は発生しません。
現象としてはサーバとは別クライアントからTvTestを起動し、
チャンネル切り替え後、地上波ですと約13Mbpsぐらいのビットレートですが、
0～50秒後に3Mbpsぐらいに落ち込み視聴ができなくなります。
一度落ち込むと、チャンネルを切り替えるまで改善は致しません。
サーバ側で視聴しますと、ビットレートは安定して13Mbpsとなります。
なお以前BonDriver_UDPでネットワーク視聴していしましたが、
その時は正常に視聴できていました。
サーバとクライアントの環境は概ねhageさんと一緒です。
VirtualPTについては32bit版でも試しております。
またNICについては10GbEにてP2P接続もしておりますが、
こちらも同様の現象が発生します。
ジャンボフレームの調整による改善については、
こちらの環境上変えることができないため試せませんでした。
ただ、以前BonDriver_UDPを使った際はジャンボフレームを設定すると同様の現象が発生し、
TvTest側の受信バッファリング設定やジャンボフレームをオフ(MTU=1500)にして改善したことがありました。
ただ今回はバッファリング中もビットレートが低下しており、バッファが空になるとやはり視聴ができなくなります。
現象のご参考になれば幸いです。
現象が再現できるかどうかで不具合改善できる可能性が大きく変わってきますので、情報提供は本当に助かります。また何かありましたらぜひよろしくお願いいたします。
以下現象が発生した環境
※サーバ、クライアントともにアンチウイルスの類はインストールしていません。
サーバ環境
CPU:Core i3 2100T
M/B:ASUS P8H67-M LE REV 3.0
MEM:DDR3-1333 2GB×2
NIC:Intel Gigabit CT Desktop Adapter
O/S:Windows Server 2008 R2 Standerd SP1(x64)
PTx:PT1 RevA ×2
C/R:SCR3310-NTTCom
その他:
PTxドライバ:PT1-Windows-Driver-200.exe
（PT1/2 Windows64bit署名問題対策ドライバはhttp://2sen.dip.jp/cgi-bin/pt1up/source/up0255.rarを使用）
PTxSDK:PT-Windows-SDK-201.exe
C/Rドライバ:Ver.4.46(http://www.ntt.com/jpki/dl_files/SCR_112.exe)
VirtualPT:Ver1.061 x64版
BonCasServer:DTV UPLOADERの[up061.zip]BonCasLink(1.10.z1)x64ビルドテスト
クライアント環境
CPU:PhenomII 1090T
M/B:ASRock 990FX Extreme4
MEM:DDR3-1333 2GB×4
NIC:OnBoard(Broadcom BCM57781)
O/S:Windows 7 SP1(x64)
その他:
BonDriver:VirtualPT Ver1.061
TVTest:TVTest 0.7.20 (x86)、TVTest 0.7.19r2 (x64)
※x86版でクライアントでデコードをする場合は
DTV UPLOADERの[up061.zip]BonCasLink(1.10.z1)x64ビルドテストを使用
x64版でクライアントでデコードをする場合は
DTV UPLOADERの[up060.zip] BonCasLink(1.10.z1) ホワイトリスト対応等
のBonCasProxyを使用
この情報が何かのお役に立てれば幸いです。
映像、音声ともにブツ切れになってしまう現象が出ましたので報告します。
Domaさんの返答にあった
>通信するデータの量を減らす方法としては、
>１．VirtualPTのチャンネルモードが互換モードであれば拡張モードにする。
> ※地デジでは効果ありませんが、BS・CSでは(特にCSでは)無駄なチャンネルのデータの通信がなります。
>２．通信するパケットの受信設定で不要なパケットを通信しないようにする。
> ※必要なパケットは「サービス別受信設定」の「デジタルTV」だけで、その他は基本的には必要無いので、その他が有効になっていたら無効にする。特に「TSパケット別受信設定」の「NULLパケット」を無効にするだけでかなり軽減されます。
なども試し、更にTVTest側のバッファリング、スクランブル解除の位置をサーバ／クライアントで切り替えてみたのですが、改善されませんでした。
サーバ、クライアント共にFirewallは切っています。
Kuroさんの対処方法と同様にジャンボフレームの設定をサバ／クラともに9014byteまで大きくすれば収まりました。
DMAバッファサイズを変えてみる事と、同一PC内で共有メモリではなくTCP-IPで試してみる事を忘れていましたので、後日試してみて報告します。
もしBonDriver_FileでOKなら、HomeServer2011側のVirtualPT設定ファイル(VirtualPT.ini)の内容、XP側のTVTest用にコピーしたBonDriver_VTPT.dllの設定ファイルの内容をお知らせいただけないでしょうか？
BonDriver_FileでもNGなら、まずBonDriver_Fileで再生できるようにしたほうが良いでしょう
外から録画する方法はわかったので、録画したのをbondriver_fileでみるっていうのも考えてます。
これを入れています。
とりあえずほかのを入れてみます。
13Mbps程度とのことなので、おそらく通信は問題なく出来ていると思います。ちなみにiniファイルのHostNameにIPアドレスを設定されているようですが、
HostName=IPアドレス[:ポート番号]
HostName=コンピュータ名[:ポート番号]
HostName=DNS名[:ポート番号]
といった設定内容でもＯＫで、ポート番号が12300の場合は省略可能です。
音声だけで映像が出ないとのことですが、XPはMPEG-2デコーダが既定で入っていなかったと記憶しています。何かしらのMPEG-2デコーダをインストールされましたでしょうか？もし、インストールされていないようでしたらMPEG-2デコーダのインストールを試して下さい。無料で入手できるMPEG-2デコーダには以下のようなものがあります。
ATI MPEG Video Decoder ← 当方の環境では最近うまく機能しなくなりました。
CyberLink Video/SP Decoder ← PowerDVDに付属するものですが、試用版のPowerDVDでもＯＫのようです。
他にも探せばいろいろあると思います。
それでも改善しない場合、再度お問合せいただけると幸いです。
とりあえず、iniのところに192.168.0.5:12300といれて、繋がりはしたのですが、音声しか出ません。13Mbpsぐらいでてます。
PT2をつけているパソコンでは映像も見れるのですが…
こんなかんじなんです。
Windowshomeserver2011にPT2にまい、12300ポートをあけてます。←開けるまでは音声も出なかったのでたぶんちゃんとあいてる…はず。
見てるパソコンはwindowsXP32bit
TVTEST。
ルータは8700NのNECのやつです。
ルータはいじり方わかんなかったのでそのままです。でも音声でてるので 、たぶん大丈夫なはずです。
音声しか出ないのはどういうのが悪いんでしょうか？
VirtualPTと視聴・録画ソフトの設定例を、取り急ぎ最低限必要となりそうなものを掲載いたしましたが、応用編としてネットワーク関連の設定やワンセグ視聴の設定、64ビットアプリの利用方法なども折を見て掲載したいと考えております。
直ぐには手を付けられませんが、もし設定方法で分からないことは、お問合せいただければ分かる範囲でお答えしたいと考えております。
凄くわかりやすくてよかったです。
同じネットワークのパソコンから見たり、番組表を見て録画したりできるんですよね？
その設定方法が知りたいです。
ネットワークを通すとややこしくなったり、人によって設定変わるとは思いますが、一例を見てみたいです。
お願いします。
改善策が分かりましたら、対策版をリリースしたいと思います。
変更したのは、ネットワークカードのジャンボフレーム設定で、それ以外のVirtualPTを含むソフト側の設定の変更はしていません。
ジャンボフレームについては、
変更前：
サーバ側 1514byte
クライアント側 なし
変更後：
サーバ側 9014byte
クライアント側 9014byte
にしたところ安定して視聴できるようになりました。
ちなみに、先ほど両方とも4088byteへと変更したところ、やはり低速になりましたので、どうやら、これ以外の設定ではダメなようです。
よく分かっていませんが、パケットの送信方法がSpinel経由の場合とは違っているんですかね。
ひとまずお知らせまで。
こちらでも調べてみたいので、改善前と改善後の設定をなるべく詳しく教えていただけないでしょうか？
お手数をおかけしますが、ご協力いただけると助かります。
その後イーサネットの設定を見直したところ、ジャンボパケットの設定を9014へと変更したところ、どうやら問題は解消したみたいです。
どうもお騒がせしました。
ただ、前にも書きましたが、Spinel+BonCasServiceを組み合わせて視聴していたときは全く問題なかったのはなんでなんでしょうかねえ。
自分の環境を書いてなかったですね。後出しですいません。
VirtualPTを導入したサーバがWindows Home Server2011で、PT2の2枚差し、クライアントがWindows7です。いずれもデスクトップで優先のギガビットでの接続になってます。CSが視聴できないというのはこちらの勘違いだったようで、設定を見直したら視聴自体はできるようになってました。
しかし、TVTestで視聴を開始すると、最初は14～15Mbpsほどでているんですが、しばらくすると3～5Mbpsまで落ちていき、ドロップが発生しています。
ネットワーク帯域に関しては、こちらでもいろいろ調べてみましたが、Spinel+BonCasServiceを組み合わせて視聴していたときは全く問題なかったのと、リソースモニタ等でみても帯域には十分な余裕がある状態です。
VirtualPTの設定もいろいろ変えてみたり、x64もx86も試してみましたが、状況は改善していません。
やはりOSの問題ですかね。でも、ローカルでは普通に視聴できているんですよね…。
ネットワークは無線LANでしょうか？あるいは、十分な帯域があってもネットワークに負荷の掛かった状態ではないでしょうか？ネットワーク帯域不足の際に起きる現象のように思われます。
もしそうであれば、通信するデータの量を減らすか、ネットワーク帯域を増やすかを検討お願いします。
通信するデータの量を減らす方法としては、
１．VirtualPTのチャンネルモードが互換モードであれば拡張モードにする。
※地デジでは効果ありませんが、BS・CSでは(特にCSでは)無駄なチャンネルのデータの通信がなります。
２．通信するパケットの受信設定で不要なパケットを通信しないようにする。
※必要なパケットは「サービス別受信設定」の「デジタルTV」だけで、その他は基本的には必要無いので、その他が有効になっていたら無効にする。特に「TSパケット別受信設定」の「NULLパケット」を無効にするだけでかなり軽減されます。
ネットワーク帯域を増やす方法としては、
現状の通信機器を改善する。例えば、無線LANが802.11bであれば802.11gに、802.11gであれば802.11nに、又は有線LANにする。有線LANでは、お問合せの様な現象はまず起きないと思いますが、100Mであればギガビットにする。これらは割りと手軽にできると思います。
もし、改善しないなどありましたら、再度お問合せいただけると幸いです。
ローカルに関しては、ひとまずTVTestでの視聴（UHF, BS, CS）まではうまくいきました。
ところが、TCP-IPを有効にしてローカルネットワーク上で視聴しようとするとCSについては、視聴できず、UHF, BSについては視聴自体はできますが、しばらくすると速度が落ちてドロップが発生し、最後にはほぼ見れなくなります。
信号レベルには問題がないので、おそらくネットワーク接続に関して何か問題があるようなんですが、いろいろ設定を変えてみてもうまくいきません。
何か対処方法があれば教えていただけないでしょうか。よろしくお願いします。
御回答いただき、ありがとうございました。
一応現在でもBonCasProxyを使えば一つのカードを見に行けますが、せっかく複数のカードを使える様になっているので直接IP:ポートを指定して複数のBonCasServerへの接続ができれば有り難いです。
尚、BonCasServerとしていますが、実際にはBonCasServerのクローンを非Windows OSで動かしています。
毎回迅速なご回答を頂き助かります。
チャンネル互換モードを使用する場合、ご提示の変更で問題無いと思います。その際、BonDriver_VTPT.dllをBonDriver_VTPT_T.dllとBonDriver_VTPT_S.dllにコピーしてそれぞれのiniファイルを設定してください(サンプルiniフォルダの同名ファイルが参考になると思います)。又、PT2を2枚にした場合も同様にE～Hを定義していただければ良いと思います。
チャンネル拡張モードで使用する場合、RecTestではチャンネル変更が出来ず、代わりにTvTestを使用したところチャンネル変更までは出来ましたが、番組表の取得が出来ませんでした（ので、録画は確認すらできていません）。思い当たる点を調べてみたものの、番組表の取得にはいたらずTvRockはソースも公開されていないようなので、現時点ではこれ以上分から無い状態です。もし改善策が分かりましたら対策したバージョンをリリースしたいと思います。
現在BonDriver_PT-STを利用して、下記の設定でTvRockを運用中です。
[実行アプリ名（視聴用）] TVTest.exe
[オプション]
/d BonDriver_PT-T.dll /DID A 地デジ
/d BonDriver_PT-T.dll /DID B 地デジ
/d BonDriver_PT-S.dll /DID C BS・CS
/d BonDriver_PT-S.dll /DID D BS・CS
[実行アプリ名（録画用）] RecTest.exe
[オプション]
/tvrock /d BonDriver_PT-T.dll /min /DID A 地デジ
/tvrock /d BonDriver_PT-T.dll /min /DID B 地デジ
/tvrock /d BonDriver_PT-S.dll /min /DID C BS・CS
/tvrock /d BonDriver_PT-S.dll /min /DID D BS・CS
これをVirtualPTに変更する場合は以下の設定内容でよろしいのでしょうか？
[実行アプリ名（視聴用）] TVTest.exe
[オプション]
/d BonDriver_VTPT_T.dll /DID A 地デジ
/d BonDriver_VTPT_T.dll /DID B 地デジ
/d BonDriver_VTPT_S.dll /DID C BS・CS
/d BonDriver_VTPT_S.dll /DID D BS・CS
[実行アプリ名（録画用）] RecTest.exe
[オプション]
/tvrock /d BonDriver_VTPT_T.dll /min /DID A 地デジ
/tvrock /d BonDriver_VTPT_T.dll /min /DID B 地デジ
/tvrock /d BonDriver_VTPT_S.dll /min /DID C BS・CS
/tvrock /d BonDriver_VTPT_S.dll /min /DID D BS・CS
またPT2を2枚に増やす際には上記の各チューナー設定A~Dへ更にE,F,G,Hと追加すれば8チューナーで運用できるのでしょうか？
初歩的な質問で申し訳ありません。
Spinel+TVH264で行う予定でしたが新しい選択肢ができました。近いうちにVirtualPT+TVH264を試してみます。
TVH264のBonDriverを格納するフォルダにBonDriver_VTPT.dllをBonDriver_VTPT_1Seg.dllに名前を替えてコピーします。設定ファイルを以下の内容で作成しファイル名BonDriver_VTPT_1Seg.iniで保存します。
[SETTING]
HostName=
Priority=0
UHFValid=1
CATVValid=0
VHFValid=0
BSValid=0
CSValid=0
ChannelMode=1
Descramble=0
RecvNULL=0
RecvDuplicate=0
RecvError=0
RecvUnknown=0
RecvDigitalTV=0
RecvOneSeg=1
RecvOtherService=0
RecvPrivate=1
RecvLow=0
RecvOtherStream=0
これで、ローカルでワンセグ視聴が可能になります。
リモートから視聴するには、VirtualPTの設定画面で全般＞通信方法＞TCP-IPにチェックして設定を保存します。既にVirtualPTサービスが起動している場合は再起動します。上のBonDriver_VTPT_1Seg.iniファイルの2行目のHostName=にVirtualPTサービスが起動しているコンピュータ名(IPアドレスでも可)を設定してください。
後はTVH264を起動して、ドライバをBonDriver_VTPT_1Seg.dllに変更しチャンネルスキャンを行ってください。
設定の一例を掲載したページを追加しようと思います。それでも分かりづらい等ありましたら、再度ご指摘いただけるとありがたいです。
もし、こちらで解決できない場合、ぜひご協力お願いいたします。もちろんそちらの都合にあわせていただいて構いません。
つきましては、準備が整いましたら連絡いたしますので、doma@do-ma.info宛にwatch-men様の連絡先メールアドレスをあらかじめお知らせいただけないでしょうか？よろしくお願いいたします。
試しに、普段クライアントに使っているPC（PT未装着、Win7 Pro x64）でも起動してみましたが同様にメニューが表示されませんでした。別のクライアント（XP Pro x86）では、問題ありませんでした。
確認プログラムの実行につきましては、あまり素早いレスポンスができないかもしれませんが、可能な範囲で協力させていただくことは可能です。
VirtualPTのバージョンと、現象が必ず起きるかをお知らせいただけないでしょうか？もしここが怪しいなどもありましたら些細なことでもかまいませんのでお知らせいただければ助かります。
又、こちらで現象の再現が出来なかったり、不具合の発見が出来なかった場合、不具合を確認するためのプログラムを実行して頂き、結果（ログファイルなど）をお知らせいただくということは可能でしょうか（複数回お願いする可能性があります）？
現状、次バージョンの詰め作業が忙しいため、確認プログラムをお願いする場合、1週間から10日ぐらい後になると思います。
終了できないので、タスクマネージャから強制終了するしかないんだけど、これってうちだけでしょうか？
Windows Media Centerについては詳しく分かりませんが、それ様には作成していませんので、動作しないと思います。
こちらの仮想チューナーはWMC上からも認識できますか？
現状bwhelper経由ではPT2を認識2TSチューナとしてのみ認識するので４TSチューナーとして認識できるのであれば利用してみようとおもってます。
ダメモトでPLEXにも確認してみます。
SDKとかは無いかも知れません
有志の方が作られたBonDriver(1353204.zip)があり、
ソースファイルも添付されています
http://www22.atwiki.jp/px-w3pe/pages/14.html
参考になるか分かりませんが…
なるべく新しい情報はチェックしているつもりなのですが、PX-W3PEについては知りませんでした。PCI Express、ロープロファイルは確かに裾野が広がりそうな気がします。このためにPT2を買えない方も少なからずいるでしょうし。価格はPT2同様高いですけど。
VirtualPTにおいては、PT1・PT2以外のデバイスにも対応しやすいように設計しており、将来的にPT2の後継機や他の普及デバイスも視野に入れております。ただPX-W3PEがPT2と同様に、世の中に浸透するか見極める必要はあると考えます。
また、VirtualPTがまだ中途半端であることと、一人で開発しているため、時間的・金銭的に余裕が無いことを考えると、対応するにしても、まだ先の話になりそうです。
公式サイト確認しましたが、開発者向け情報のようなものは見つかりませんでした。もしお分かりでしたら、（他の方でもかまいません）教えて頂けると助かります。
とても素晴らしいコンセプトだと思います
PT1・PT2専用とのことですが、PX-W3PEにも対応していただけないでしょうか？
PT2同様3波対応の4TSで、PCI-e、ロープロにも対応した機種です
まだ不安定？なようですが、これからのTVチューナーの中心になる機種だと思います
Spinelなら区別できるので
あればうれしいです
独立U局の件、解説頂きありがとうございます。勉強になります。
この件についてはプログラムの難易度に対して、必要な方がどのくらいいらっしゃるのかが気になるところです。今後、要望がどのくらいくるかも判断材料としたいと思います。
また、通常、テレビやビデオでは地上波のアンテナ入力は１つだと思うのですが、その場合どのようにされているのでしょうか？アンテナ混合器のようなものを使うのでしょうか？
独立U局が受信出来る様にアンテナの方向を変えると今度はキー局のレベルが低くて受信出来なくなる
この対策の為にアンテナを2本立ててT1、T2で分けたりしてる人もいるということです
この場合チューナー毎に受信出来るチャンネルと出来ないチャンネルがあるので指定出来ないとマズいことになるわけです
> 地上波では独立U局の為にアンテナ複数立ててる人もいるのでチューナー指定も出来るといいと思います
すいません、ちょっと分からないので、詳しく教えて頂けないでしょうか？
スクランブル解除の件については、現状のBonDriverの範疇では受信したデータ全てをスクランブル解除する必要があります。これは、必要の無いチャンネル（サービスと言ったほうが正確かもしれません）まで解除しなければならないと言うことは把握しており、BonDriverのチャンネル定義を拡張することで対応できないかと考えております。ただ、現バージョンでサービス側のCPU負荷がほとんど掛かっていないので、スクランブル解除のコードを最適化すれば全データ解除しても問題ないかもとも考えております。開発していく上で、その辺を考慮しながら開発していきたいと考えております。
ネットワークの件、参考になります。ネットワーク帯域節約と言うことで、不要チャンネル（サービス）を送らないのは、確かに正しい方法と思います。ただ、BonDriverがそのようなことに対応できないため、単純には対応できません。VirtualPT専用録画ソフト等では、その辺のことも対応出来るように考えております
地上波では独立U局の為にアンテナ複数立ててる人もいるのでチューナー指定も出来るといいと思います
恐らくこの機能は考えていると思うんですけど
鯖側でスクランブル解除する時
spinelでB25を使用した場合
CS等同一トラポンに複数CHがあるものを全て解除しようとして負荷が高くなって遅延が発生していたので視聴or録画対象CHのみのスクランブル解除が出来るといいと思います
ネットワーク越しのアクセスも同一トラポン内に複数CHがある場合対象CHのみ転送出来るといいと思います（こちらは可能なのかどうかわかりませんが）
VirtualPTをSDK 1.x系でも使えるようにしたいと思います。別ページ(http://blog.livedoor.jp/domamemo/archives/2326671.html)で、動作確認していただける方を募集していますので、ぜひとも、そちらの確認もお願いできたらと思います。
また、PT1の動作報告までいただき、大変感謝です。
自家製ドライバもない卑怯なコピー商品をかまう必要はないと思う
よろしくお願いします
尚、PT1でのEDCB10、TVTestの
2008R2での動作は確認できました
PT2X2の件ですが、ちょっと調べたところPT1用のバージョン1.xドライバーで無いとBS/CSが受信できないと分かりました。当方、現物を持っていない為、てっきりPT2と同じものと思っておりましたが、PT1の方に近いのですね。勉強になりました。
ところで、SDKも1.x系を使用しないといけないのでしょうか？もし、2.x系が使えればVirtualPTで認識できそうな気がします。(最新の2.0.1が理想ですが、「ソフトウェアのダウンロード (過去のバージョン)」のページにある2.0でもVirtualPTで認識できると思われます。)
大変お手数ですが、当方で確認できないため、確認していただき結果を教えていただけないでしょうか？もし、ＮＧなら別の手段を考えますのでよろしくお願いいたします。
旧Driver、SDK
http://earthsoft.jp/PT/download-old.html
(でしかBSCS使えないため)
それが原因なのか？
VirtualPT起動しても
「デバイスが見つかりません」状態です
どうか御一考をお願いします
コメントする
2011年01月09日
インストール方法
ハードウェアを装着し、ドライバやSDKをあらかじめインストールして下さい。
| デバイス | 推奨ドライバ | 推奨SDK |
|---|---|---|
| PT1 | 2.1 PT1-Driver-210.exe |
2.1 PT1-PT2-SDK-210.exe |
| PT2 | 2.1 PT2-Driver-210.exe |
2.1 PT1-PT2-SDK-210.exe |
| PT3 | 1.0 PT3-Driver-100.exe |
0.96 PT3-SDK-096.exe |
| PT2X2 | 1.0 PT1-Windows-Driver-100.exe |
1.0.2 PT1-Windows-SDK-102.exe |
※アースソフトPT1・PT2関連のダウンロードはコチラから行えます。
※アースソフトPT3関連のダウンロードはコチラから行えます。
※PT2X2の場合、PT1用の「旧ドライバ」及び「旧SDK」をインストールして下さい。ダウンロードはコチラから行えます。
※PT2X2での動作を保障するものでは有りません。あくまで自己責任でお願いします。
| デバイス | 推奨ドライバ |
|---|---|
| PX-W3PE | 1.0.6 BDA driver |
| PX-S3U | 1.0.2 BDA driver |
| PX-S3U2 | 1.0.2 BDA driver |
| PX-W3U2 | 1.0.1 BDA driver |
| PX-W3U3 | 1.0.0 BDA driver |
※Plex PXシリーズ関連のダウンロードはPlex公式サイトの各商品詳細ページから行えます。OSに合わせて32ビット版か64ビット版のBDAドライバをインストールして下さい。
VirtualPTをあらかじめダウンロードして下さい。ダウンロードはコチラから。
| フォルダ | ファイル | 備考 | |
|---|---|---|---|
| \ | ReadMe.txt | 説明ファイル | |
| DevicePluginSrc.zipt | デバイスプラグインソースファイル | ||
| x86\ | VirtualPT.exe | VirtualPTサービス本体(32ビット用) | |
| DeviceEarthPT.dll | アースソフトPT用デバイスプラグイン(32ビット用) | ||
| DevicePlexPX.dll | Plex PX用デバイスプラグイン(32ビット用) | ||
| x64\ | VirtualPT.exe | VirtualPTサービス本体(64ビット用) | |
| DeviceEarthPT.dll | アースソフトPT用デバイスプラグイン(64ビット用) | ||
| DevicePlexPX.dll | Plex PX用デバイスプラグイン(64ビット用) | ||
| BonDriver\ | x86\ | BonDriver_VTPT.dll | VirtualPT用BonDriver(32ビット用) |
| BonDriver_VTPT.ini | BonDriver_VTPT.dll用の設定ファイル | ||
| x64\ | BonDriver_VTPT.dll | VirtualPT用BonDriver(64ビット用) | |
| BonDriver_VTPT.ini | BonDriver_VTPT.dll用の設定ファイル | ||
| サンプルini\ | BonDriver_VTPT.ini | BonDriver用設定ファイルサンプル(視聴用) | |
| BonDriver_VTPT_S.ini | BonDriver用設定ファイルサンプル(録画(衛星)用) | ||
| BonDriver_VTPT_T.ini | BonDriver用設定ファイルサンプル(録画(地上)用) | ||
圧縮ファイル内のx86フォルダもしくはx64フォルダを適当なフォルダにコピーします。32ビットOSの場合、x86フォルダをコピーして下さい。64ビットOSの場合、どちらでも動作しますがx64をお勧めします。視聴・録画ソフト(TVTest等)の32ビット・64ビットと合わせる必要はありません。違っていても動作します。
上でコピーしたフォルダ内のDeviceEarthPT.dll、DevicePlexPX.dllは使用する機器用のdllだけあれば、以外は削除してもかまいません。削除しなくても問題無く動作します。
上でコピーしたフォルダ内のVirtualPT.exeを起動します。画面右下のタスクトレイにVirtualPTアイコンが表示されます。起動から5秒間ピコピコ点滅しているものがVirtualPTアイコンです。
VirtualPTアイコンをクリックしてメニューを開き、「設定」を選択します。
設定ダイアログが表示されますので、適切に設定しOKボタンを押して下さい。
- 通信方法
- TV視聴・TV録画ソフト等からの接続方法を指定します。通常共有メモリのみで問題ありません。これは、ローカルコンピューター（同一コンピューター）内での通信方法です。もし、ネットワーク経由での接続を受付ける場合、TCP-IPを選択して待受けポートを指定します。待受けポートの初期値は12300です。
- 起動待機時間
- スリープ解除時にデバイス等にアクセスせずに待機する時間を秒単位で設定します。スリープ復帰直後にICカードリーダー等のデバイスリセットを行っている場合で、リセットが完了するまでデバイスにアクセスしたくない場合、リセットが完了するまでの時間を設定してください。
- チューニング空間
- 受信するチューニング空間を指定します。地デジは通常UHF、BSデジタルはBS、スカパーe2はCSです。ご使用の環境に合わせて選択して下さい。もし、分からなければ全てチェックでも問題無いと思います。
- チャンネルスキャン
- チャンネル拡張モードのチャンネルスキャンを自動で行いたい場合、チェックしてください。チャンネル互換モードのチャンネルスキャンは自動では出来ません。手動で行ってください。(チャンネルスキャンについて参照)
- CATV
- ケーブルテレビの一部の局ではC24ch～C27chの周波数が2MHz高い場合があるようです。もし該当する場合チェックして下さい。
- ICカードリーダー
-
BCASカードを検索するICカードリーダーに関する設定をします。BCASカードを検索するICカードリーダーを限定したい場合、「以下で選択されたもののみ」にチェックしICカードリーダー一覧から対象となるものを選択します(複数選択可)。一部のICカードリーダーをBCASカードの検索から除外したい場合、「以下で選択されたものを除く」にチェックしICカードリーダー一覧から除外したいものを選択します(複数選択可)。全てのICカードリーダーを対象とする場合は、「以下で選択されたものを除く」にチェックしICカードリーダー一覧で何も選択しないで下さい。
※リモートデスクトップではプログラム実行中のコンピュータではなく操作中のコンピュータ（操作中のマウスやキーボードがある側のコンピュータ）のICカードリーダーが一覧表示されますのでご注意ください。
※BCASカードが複数見つかった場合、受信中の番組のスクランブル解除に使用できるものを自動判定します。スクランブル解除に使用できるものが複数ある場合は、それぞれのBCASカードに負荷分散し負担を軽減します。 - ECM処理を行う
- ECMとは放送ストリーム中に含まれる暗号化された鍵情報です。放送ストリームをスクランブル解除するにはこの鍵情報が必要ですが、そのままでは暗号化されているのでBCASカードを通して鍵情報の暗号化解除を行う必要があります。VirtualPTでスクランブル解除を行う必要がある場合、ここにチェックする必要があります。逆にVirtualPTでのスクランブル解除を全く行わない場合はチェックしないでください。
- EMM処理を行う
- EMMとは放送ストリームと共に流れてくる有料放送契約情報です。有料放送は通常１ヶ月単位で契約継続していきます。又、PPVのように１番組だけ別途購入するようなものもあります。このEMMデータをBCASカードで処理することで契約したチャンネルや番組の視聴が可能に（上記ECMの鍵情報の暗号化解除が可能に）なります。有料放送をVirtualPTでスクランブル解除する場合はここにチェックすることを推奨します。
※地デジやBSの無料放送しか視聴・録画しない場合はBCASカードに始めから格納されている情報を使用するのでEMM処理は必要ありません。
- 共通設定・個別設定
- 「共通設定」は全てのデバイスに対する設定です。デバイス別に設定を変えたい場合、「デバイス一覧」から対象デバイスを選択して「このデバイスは個別に設定する」にチェックすると、そのデバイス個別の設定をすることが可能になります。
- LNB電源
- BS/CSアンテナに電源供給が必要な場合、「ON」を選択してください。集合住宅の共同アンテナ等で、他の手段で電源供給されている場合は「OFF」を選択して下さい。
- DMAバッファサイズ
- 指定された値×4MBを1ボード毎に割当てます。2から32までの値を設定可能です。推奨値は6～8(24MB～32MB)です。DMAバッファサイズが少ないと受信開始に失敗したり受信中に停止する場合があります。
- ストリーム補助コードをチェックしない
- チャンネル切り替え時にDMAバッファに既に書込まれたストリームをスキップするためにストリーム補助コードを使用しています。PT2X2ではこの機能が使えないため、チャンネル切替えに不具合が生ずるのでONに(チェックボックスにチェック)してこの機能を無効にして下さい。
- 旧SDK(PT1 SDK 1.x系)使用
- 基本的にSDKは最新版の使用を推奨します。ただ、PT2X2では旧SDKでないとBS/CSの受信が出来ないので、「PT1 SDK 1.x系」をインストールしココにチェックをしてください。PT1(もしくはPT2X2)でのみココの設定が有効です。
Plex PXシリーズの設定は公式サイトで配布されたレジストリ設定ツールで行い、VirtualPT側で設定を行う必要はありませんが、このツールと同じことをこの画面上で行うことが出来ます。
- デバイス一覧
- レジストリ設定を行いたいデバイスを一覧から選択すると各デバイス毎の設定を行えます。設定はVirtualPT設定ファイルに保存されるわけではないので、デバイス毎に設定後「レジストリ登録」ボタンで都度登録してください。
- LNB電源
- BS/CSアンテナに電源供給が必要な場合、「ON」を選択してください。集合住宅の共同アンテナ等で、他の手段で電源供給されている場合は「OFF」を選択して下さい。
- 地デジ感度調整
- 地デジの受信レベルがより良くなるように調整してください。ただし、「自動調整」はドロップが発生する可能性があるため選択しないことを推奨します。
各チューナー毎に使用優先度や周波数別に有効・無効を設定できます。
- チューナー一覧
- システムに接続されたチューナーが一覧表示されますので、一覧から設定したいものを選択します。
- 有効・無効
- 有効を選択したチューナーを使用対象にします。通常は有効にしてください。ケーブルが接続されていない等で使用したくない場合は無効を選択してください。
- 優先順位
- どのチューナーから優先的に使用するかを-128～127の範囲で指定します。数字の大きいものから順に使用していきます。優先順位が同じ場合は、デバイス認識順に使用していきます。
- 周波数別受信設定
- チューニング空間・周波数別に使用対象とするかを設定します。チェックした周波数以外は受信しません。独立U局を特定のチューナーだけで受信する場合は、独立U局を受信しないチューナー全てで独立U局の周波数のチェックを外してください。
BonDriverで設定する内容の既定値を設定します。BonDriverでの設定値が未設定の場合にここでの設定内容が反映されます。各BonDriverで共通の設定や代表的な設定をしておくと便利です。※例えば、「デジタルTV」をONに設定しBonDriver側では未設定にする。ワンセグ視聴ソフト(TVH264等)用のBonDriverでは「デジタルTV」をOFF、「ワンセグ」をONと設定するといった使い方も可能です。
- チューニング空間 (BonDriver設定ファイル：UHFValid、CATVValid、VHFValid、BSValid、CSValidに対応)
- 使用するチューニング空間を指定します。全般タブ＞チューニング空間でチェックしたもののうち、各視聴・録画ソフトで対象とするものを指定します。例えば、視聴ソフトでは全てのチューニング空間を対象とし、録画ソフトでは衛星(BS,CS)と地上(UHF,CATV,VHF)に分割します。
- 優先順位 (BonDriver設定ファイル：Priorityに対応)
- 各視聴・録画ソフトのチューナー割当ての優先順位を-128～127の範囲で指定します。チューナーの空きが無い場合、優先順位の高い(数字の大きい)ものがチューナーに割当てられ、チューナーが割当てられなかった優先順位の低い(数字の小さい)ものは、チューナーの空きが出来るまで待機状態になります。例えば、視聴ソフトより録画ソフトの優先順位を高くしておくと、視聴ソフトが既にチューナーを使用している場合でも、それを中断して録画ソフトにチューナーが割り当てられます。
- スクランブル解除 (BonDriver設定ファイル：Descrambleに対応)
- VirtualPT側でスクランブル解除したデータを視聴・録画ソフトに転送するか、スクランブル解除しない生のデータを転送するかを指定します。
※VirtualPT側でスクランブル解除を行う場合、視聴・録画ソフトではスクランブル解除を行わない設定にすることを推奨します。TVTestでは設定ダイアログの「一般＞カードリーダー」で「なし(スクランブル解除しない)」を選択するか、「ドライバ別設定」で「ドライバ側でスクランブル解除する」を選択します。EpgDataCap_BonではEpgDataCap_Bon.exeのあるフォルダ内のB25Decoder.dllを削除(あるいはファイル名変更)します。詳しくは各アプリケーションの説明書を参照して下さい。 - チャンネルモード (BonDriver設定ファイル：ChannelModeに対応)
- 互換モード・拡張モード・拡張モードBのどれを使用するかを指定します。互換モードは従来からのBonDriverと互換性のあるチャンネル設定で、トランスポートストリーム単位でBonDriver内部のチャンネル番号が割当てられています。拡張モード・拡張モードBはVirtualPT独自のチャンネル設定で、チャンネル(サービス)単位でBonDriver内部のチャンネル番号を割当てます。拡張モード・拡張モードBはスクランブル解除時の無駄を無くすために新たに追加したモードです。２つの拡張モードの違いは、標準は拡張モードですが、拡張モードではTvRock DTVターゲットが正しく動作しないのでそれ専用のモードが拡張モードBです。詳しくは「スクランブル解除について」、「チャンネル拡張モードについて」、「チャンネル拡張モードBについて」を参照して下さい。
※チャンネルモードを変更する場合、視聴・録画ソフトのチャンネルスキャンをやり直す必要があります。(EpgDataCap_Bonではチャンネルスキャンだけでは古い設定が消えませんので「設定関係保存フォルダ」内の全てのファイルを削除してからチャンネルスキャンする必要があります。なので予約録画・自動予約等の再設定も必要です) - 再生遅延時間 (BonDriver設定ファイル：DelayTimeに対応)
- 視聴・録画ソフトにデータを送り始めるまでの時間(ミリ秒)を指定します。0～2000の範囲で指定します。TVTestが(デコーダ・レンダラの選択によって)受信開始時に操作不可能になる場合、100ms程度の値を指定すると軽減する可能性があります。
- 受信設定
- それぞれのデータを受信するかどうかを指定します。各設定項目の内容は以下の通りです。
- TSパケット別＞NULLパケット (BonDriver設定ファイル：RecvNULLに対応)
- NULLパケットの受信設定です。NULLパケットは帯域幅の調整等に使用されます。通常、破棄しても問題ありません。NULLパケットは大量に存在しますので、破棄することで録画ファイルサイズや通信帯域の節約になります。
- TSパケット別＞複製パケット (BonDriver設定ファイル：RecvDuplicateに対応)
- 複製パケットの受信設定です。私が確認したところでは発見できませんでしたが、ワンセグ等の部分受信データでデータの整合性を保つために使用する場合も有るようです。通常、破棄しても問題ありません。
- TSパケット別＞エラーパケット (BonDriver設定ファイル：RecvErrorに対応)
- エラーパケットの受信設定です。通常、破棄しても問題ありません。
- TSパケット別＞不明パケット (BonDriver設定ファイル：RecvUnknownに対応)
- 不明パケットの受信設定です。パケットの到着時点では、何か分からないパケットです。特にストリームの受信開始時に発生します。
- PSIセクション別＞PAT,CAT,PMT
- PSIセクション(PAT,CAT,PMT)はトランスポートストリームの基本情報です。PAT,CAT,PMTは無条件で受信されます。
- PSIセクション別＞NIT (BonDriver設定ファイル：RecvNITに対応)
- PSIセクション(NIT)の受信設定です。NITは物理ネットワークの情報です。EPG番組表を取得する場合は必要ですが、それ以外はおそらく破棄しても問題ありません。
- PSIセクション別＞SDT (BonDriver設定ファイル：RecvSDTに対応)
- PSIセクション(SDT)の受信設定です。SDTはチャンネル(サービス)の情報です。EPG番組表を取得する場合は必要ですが、それ以外はおそらく破棄しても問題ありません。
- PSIセクション別＞EIT (BonDriver設定ファイル：RecvEITに対応)
- PSIセクション(EIT)の受信設定です。EITは番組の情報です。番組名や番組内容等の番組情報やEPG番組表を取得する場合は必要ですが、それ以外はおそらく破棄しても問題ありません。
- PSIセクション別＞BIT (BonDriver設定ファイル：RecvBITに対応)
- PSIセクション(BIT)の受信設定です。BITは事業体の情報です。通常、破棄しても問題ありません。
- PSIセクション別＞TDT,TOT (BonDriver設定ファイル：RecvTDTTOTに対応)
- PSIセクション(TDT,TOT)の受信設定です。TDT,TOTは現在時刻の情報です。動画再生に必要な時刻情報はこれ以外の情報が使用されるため、通常、破棄しても問題ありません。
- PSIセクション別＞ECM (BonDriver設定ファイル：RecvECMに対応)
- PSIセクション(ECM)の受信設定です。ECMはスクランブル解除キー等の情報です。VirtualPT側でスクランブル解除を行う場合には破棄しても問題ありません。ただ、録画する場合はスクランブル解除ミスに備えて一緒に録画した方が良いでしょう。
- PSIセクション別＞EMM (BonDriver設定ファイル：RecvEMMに対応)
- PSIセクション(EMM)の受信設定です。EMMは有料放送の契約等の情報です。VirtualPT側でスクランブル解除を行う場合には破棄しても問題ありません。EMMデータは大量(ストリームに対して10％から30％)に存在しますので、破棄することで録画ファイルサイズや通信帯域の節約になります。
- PSIセクション別＞その他 (BonDriver設定ファイル：RecvOtherPSIに対応)
- その他PSIセクションの受信設定です。
- サービス別＞デジタルTV (BonDriver設定ファイル：RecvDigitalTVに対応)
- デジタルTVサービスの受信設定です。通常受信する必要がありますが、ワンセグ視聴ソフト(TVH264等)では、破棄しても問題ありません。
- サービス別＞デジタル音声 (BonDriver設定ファイル：RecvDigitalSoundに対応)
- デジタル音声サービスの受信設定です。
- サービス別＞データ放送 (BonDriver設定ファイル：RecvDataSvcに対応)
- データ放送サービスの受信設定です。
- サービス別＞ワンセグ (BonDriver設定ファイル：RecvOneSegに対応)
- ワンセグサービスの受信設定です。通常、破棄しても問題ありませんが、ワンセグ視聴ソフト(TVH264等)では、受信する必要があります。
- サービス別＞その他 (BonDriver設定ファイル：RecvOtherServiceに対応)
- その他サービスの受信設定です。
- ストリーム別＞映像・音声
- 映像・音声ストリームは無条件で受信されます。
- ストリーム別＞プライベートデータ (BonDriver設定ファイル：RecvPrivateに対応)
- プライベートデータストリームの受信設定です。字幕データ等が含まれます。
- ストリーム別＞低階層 (BonDriver設定ファイル：RecvLowに対応)
- 低階層ストリームの受信設定です。天気などの影響で電波状況が悪い場合でも視聴できるように、データ量を抑えて解像度を落としたストリームです。通常BS1・BS2にのみ含まれるようです。
- ストリーム別＞その他 (BonDriver設定ファイル：RecvOtherStreamに対応)
- その他ストリームの受信設定です。(ストリーム単位の)データ放送等が含まれます。
【用途別必要データ一覧】通常放送 サービス別＞デジタルTV 音声放送 サービス別＞デジタル音声 (チャンネル単位の)データ放送 サービス別＞データ放送 ワンセグ放送 サービス別＞ワンセグ 字幕等の文字データ ストリーム別＞プライベートデータ チャンネルスキャン PSIセクション別＞NIT
PSIセクション別＞SDT番組名・番組内容等 PSIセクション別＞EIT EPG番組表 PSIセクション別＞NIT
PSIセクション別＞SDT
PSIセクション別＞EIT視聴・録画ソフト側でスクランブル解除を行う PSIセクション別＞ECM 視聴・録画ソフト側で有料放送契約更新を行う PSIセクション別＞EMM 録画時スクランブル解除ミスがあった場合に再デスクランブルを行えるようにする PSIセクション別＞ECM
VirtualPTアイコンをクリックしてメニューを開き、「《サービス未登録》」＞「サービス登録」を選択します。既にサービス登録されている場合は、メニューの表示が変わりますので注意してください。正常に登録されると「サービスを登録しました」と表示されサービスが起動されます。
↓
VirtualPTアイコンをクリックしてメニューを開き、「チャンネルスキャン」を選択します。
チャンネルスキャンダイアログが表示されますので、最新チャンネル情報を取得してください。詳しくは「チャンネルスキャン方法」を参照してください。
VirtualPTアイコンをクリックしてメニューを開き、「終了」を選択します。VirtualPTアイコンが消えますが、サービスは目に見えないところで常駐していますので、通常時はVirtualPTアイコンが表示されていなくても問題ありません。設定等を行う場合のみ、VirtualPT.exeを起動してVirtualPTアイコンを表示させて下さい。
圧縮ファイル内のBonDriverフォルダを適当なフォルダに展開し、視聴ソフトや録画ソフトのBonDriver格納フォルダにBonDriver_VTPT.dllとBonDriver_VTPT.iniをコピーして下さい。視聴ソフトや録画ソフトが32ビットアプリケーションの場合、x86フォルダ内のものを使用して下さい。64ビットアプリケーションの場合、x64フォルダのものを使用して下さい。コピーするフォルダは、TVTestの既定値ではTVTest.exeのあるフォルダです。EpgDataCap_Bonの既定値ではEpgDataCap_Bon.exeのあるフォルダ内のBonDriverフォルダ内です。BonDriver格納フォルダについて詳しくは各アプリケーションの説明書を参照して下さい。
もし衛星と地上で別々に扱う必要があるなど、複数のDLLが必要ならBonDriver_VTPT.dllとBonDriver_VTPT.iniをコピーして別の名前にして下さい。別の名前にする際、BonDriver_で始まり、拡張子(.dllや.ini)以外の部分は同じである必要があります。（例えば、BonDriver_VTPT_S.dllとBonDriver_VTPT_S.ini）
視聴ソフト(TVTest)では1つのDLLで３波(地デジ・BS・CS)対応がオススメです。録画ソフト(TvRock、EpgDataCap_Bon等)では2つのDLLにコピーし１つは衛星(BS・CS)用、もう１つは地上(地デジ)用とすることで、同時録画可能チェックを行うことが出来ます。（例えばPT2では１枚のボードで地上2TS・衛星2TSまでの同時録画が可能）
| ソフト | フォルダ | ファイル |
|---|---|---|
| TVTest | TVTest\ | ： TVTest.exe ： BonDriver_VTPT.dll BonDriver_VTPT.ini |
| EpgDataCap_Bon | EpgDataCap_Bon\ | ： EpgDataCap_Bon.exe ： |
| EpgDataCap_Bon\BonDriver\ | BonDriver_VTPT_S.dll BonDriver_VTPT_S.ini BonDriver_VTPT_T.dll BonDriver_VTPT_T.ini |
コピーした各BonDriver_VTPTの設定ファイルを適切に修正します。設定内容は以下の説明やBonDriver用設定ファイルサンプル(サンプルiniフォルダ内)を参照して下さい。
- HostName
- 通信相手のVirtualPTのホスト名を指定します。未指定の場合、ローカルコンピュータ（同一コンピューター）のVirtualPTと通信します。TCP-IP経由で接続する場合は、接続先コンピューターを"ホスト名:ポート番号"もしくは"ホスト名"で指定します。ポート番号を省略した場合は12300を使用します。"localhost"と指定するとTCP-IP経由でローカルコンピュータと通信しますので、ローカルコンピュータの場合は何も指定しないで下さい。
- UHFValid、CATVValid、VHFValid、BSValid、CSValid
- 使用するチューニング空間を指定します。1が「使用する」で、0が「使用しない」です。
- Priority
- チューナー割当ての優先順位を-128～127の範囲で指定します。
- Descramble
- VirtualPT側でスクランブル解除したデータを受信する場合、1を指定します。スクランブル解除しない生のデータを受信する場合、0を指定します。
- ChannelMode
- チャンネル互換モードを使用する場合は1、チャンネル拡張モードを使用する場合は2、チャンネル拡張モードB(TvRock DTV Target用)を使用する場合は3を指定します。
- DelayTime
- 視聴・録画ソフトにデータを送り始めるまでの時間(ミリ秒)を0～2000の範囲で指定します。
- 受信設定
- それぞれのデータを受信するかどうかを指定します。1が「受信する」で、0が「受信しない」です。以下の設定項目があります。
- RecvNULL
- NULLパケットの受信設定です。
- RecvDuplicate
- 複製パケットの受信設定です。
- RecvError
- エラーパケットの受信設定です。
- RecvUnknown
- 不明パケットの受信設定です。
- RecvNIT
- PSIセクション(NIT)の受信設定です。
- RecvSDT
- PSIセクション(SDT)の受信設定です。
- RecvEIT
- PSIセクション(EIT)の受信設定です。
- RecvBIT
- PSIセクション(BIT)の受信設定です。
- RecvTDTTOT
- PSIセクション(TDT,TOT)の受信設定です。
- RecvECM
- PSIセクション(ECM)の受信設定です。
- RecvEMM
- PSIセクション(EMM)の受信設定です。
- RecvOtherPSI
- その他PSIセクションの受信設定です。
- RecvDigitalTV
- デジタルTVサービスの受信設定です。
- RecvDigitalSound
- デジタル音声サービスの受信設定です。
- RecvDataSvc
- データ放送サービスの受信設定です。
- RecvOneSeg
- ワンセグサービスの受信設定です。
- RecvOtherService
- その他サービスの受信設定です。
- RecvPrivate
- プライベートデータストリームの受信設定です。
- RecvLow
- 低階層ストリームの受信設定です。
- RecvOtherStream
- その他ストリームの受信設定です。
アンインストール方法
インストールしたVirtualPT.exeを起動して、画面右下のタスクトレイにVirtualPTアイコンを表示します。起動から5秒間ピコピコ点滅しているものがVirtualPTアイコンです。
サービスが実行中の場合は、VirtualPTアイコンをクリックしてメニューを開き、「《サービス実行中》」＞「サービス停止」を選択し、サービスを終了させます。
VirtualPTアイコンをクリックしてメニューを開き、「《サービス停止》」＞「サービス解除」を選択します。正常に解除されると「サービスを解除しました」と表示されます
↓
VirtualPTアイコンをクリックしてメニューを開き、「終了」を選択します。
後は、フォルダごと削除して下さい。以上でアンインストールは完了です。
2011年01月09日
動作環境
【想定動作OS(設計上動作可能と思われるOS)】
・Windows XP (32ビット/64ビット)
・Windows Vista (32ビット/64ビット)
・Windows 7 (32ビット/64ビット)
・Windows Server 2003 (32ビット/64ビット)
・Windows Server 2008 (32ビット/64ビット)
・Windows Server 2008 R2 (32ビット/64ビット)
【動作確認OS】
・Windows Vista Ultimate SP2 (32ビット版)
・Windows Vista Ultimate SP2 (64ビット版)
・Windows Server 2008 Standard SP2 (32ビット版)
・Windows Server 2008 Standard SP2 (64ビット版)
ダウンロード
【'12/9/5追記】
'12/9/5付でダウンロードは終了いたしました。
| サイト | バージョン | 備考 |
|---|---|---|
| 1.18 | 公開終了 |
寄付
【'12/8/31追記】
'12/8/31付で寄付の受付は終了いたしました。
VirtualPTは、皆様からの寄付を募集しております。使用してみてお金を払う価値があると感じた方は、寄付にて金銭的支援をしていただければ幸いです。金銭的支援は今後の活動のモチベーションを保つためにも大変励みになります。
| サイト | 金額 | お支払い方法 | 備考 |
|---|---|---|---|
| 525円、1,000円、2,000円 他に購入者負担手数料105円が必要 |
クレジットカード | 受付終了 |
|
(エニィウェアプラス) |
1円～ | 郵便振込、銀行振込、WebMoney、BitCash ※クレジットカードはWebMoney・BitCashで可能 |
受付終了 |
ソースについて
【'12/8/31追記】
'12/8/31付でソースコードの一般公開は終了いたしました。
【'12/9/2訂正】
「拡張ツール中の人」さんが設計したBonDriverインターフェース(IBonDriver.h,IBonDriver2.h,IBonDriver3.h)がLGPLとなっていますが、ヘッダーファイルをインクルードしているだけで、静的・動的リンクは行っていないので、ソースコードの公開義務は無いと考えます。ただ、TV視聴・録画関連のソフトが充実されるのであれば、全てのソースコードを公開しても構わないと考えております。また、TV視聴・録画関連の学習のために参照したいといった方にも公開しても構わないと考えております。しかし、TV視聴・録画関連ではない（特に商用）アプリケーションに使用されるのは本意ではありません。無断で使用されても気づくことさえ出来ないでしょう。そこで、当面は希望のあった方に限り(ソースコード全てを)公開いたします。希望される方は連絡先メールアドレス、もしくは、プロフィールのメールボタンからご連絡下さい。メールで返信しますので、メールアドレスの入力を忘れずに行ってください。
ライセンスについて
・VirtualPTの著作権者は「Doma」です。
・BonDriverインターフェースの著作権者は「拡張ツール中の人」さんです。←もし誤解などありましたらご連絡下さい。
・PT1 SDK、PT1/PT2 SDK、及び、PT3 SDKの著作権者は「有限会社アースソフト」さんです。
・TV視聴・録画関連のフリーウェアへは自由に転載、改変、再配布を可能とします（ただし、著作権を放棄するものではありません）。
・TV視聴・録画関連以外のアプリケーションへの転載、改変、再配布は禁止します。
・商用・シェアウェアなどへの転載、改変、再配布は禁止します。
免責事項
本アプリケーションを利用して直接もしくは間接的な損害が生じても、いっさいの責任を負いかねます。自己責任でのご利用をお願いします。
更新履歴
ver 1.18 2012/8/26
・手動チャンネルスキャン等でチューニング空間有効フラグの反映・確認が正しく行われない不具合を修正
ver 1.17 2012/8/10
・設定ダイアログの表示がおかしくなる場合がある不具合を修正
ver 1.16 2012/8/5
・チューナー機器独自処理をDLLに分離し、実行に必要な機器のDLLだけで動作するように修正
・TCP-IP接続で接続先がIPアドレスで指定された場合、不必要な名前解決を行わないように修正
・ストリーム受信中にサービス停止やスリープすると異常終了する場合がある不具合を修正
・異常終了等でファイルの残骸が残った場合、自動で削除するように修正
・各種調整
ver 1.15 2012/7/14
・アースソフトPTシリーズの受信パフォーマンス改善
・多数の受信(10以上)を同時に停止すると、全て停止するまでに長時間掛かることがある不具合を修正
・アースソフトPT3 SDKバージョン0.96で追加された関数に対応
・視聴・録画ソフトにデータを送り始めるまでの時間を指定出来るように変更
ver 1.14 2012/7/7
・シグナルレベル取得方法の改良
・サービス別受信設定にデジタル音声とデータ放送を追加
・各種調整
ver 1.13 2012/6/30
・アースソフトPT3のシグナルレベル取得処理の改善
ver 1.12 2012/6/24
・アースソフトPTシリーズの受信パフォーマンス改善
・アースソフトPTシリーズ設定のDMAバッファサイズの設定前初期値を2から8に変更
・視聴・録画ソフトで非スクランブルデータにもかかわらず、スクランブルデータとして扱われる場合に対応(J:COM HD対応)
ver 1.11 2012/6/18
・アースソフトPT3に対応
・PSIセクションの種類によって受信するか指定できるように修正
・各種調整
ver 1.10 2012/5/24
・シグナルレベル取得方法の改良
・BonDriver_VTPTのバッファ処理の改良整
・TCP-IP接続中にスリープすると応答しなくなる場合がある不具合を修正
ver 1.09 2012/5/12
・Plex PXシリーズ(PX-W3PE、PX-S3U、PX-S3U2、PX-W3U2、PX-W3U3)に対応
・チューナー・周波数別に受信可否を設定できるように変更(独立U局対応)
・シグナルレベル取得方法の改良
・TCP-IP通信時の設定値をチューニング
・各種調整
ver 1.08 2012/2/26
・TCP-IP通信時の不具合を改善。送信側と受信側とで同期を取りながら通信していましたが、同期を取らずに通信する機能を追加。問題無く動作していた環境ではこれまでどおり通信し、問題が発生していた環境では状況に応じて同期を取らない通信を織り交ぜて通信するように変更。
ver 1.07 2012/2/5
・開発環境をVisual Studio 2005からVisual Studio 2008に変更
・スクランブル解除ロジックをSSSE3にも対応
・ICカードリーダーの状態監視処理の不具合を改善
・ICカードリーダーで回復不可能なエラーが発生した場合、イベントログにメッセージ(ID=3004)を出力するように変更。
・自動チャンネルスキャンの不具合を改善
ver 1.06.1 2011/6/7
・ReadMe.txtの記述に誤りがあったので修正。プログラムに変更はありません。
ver 1.06 2011/6/3
・拡張チャンネルモードB(TvRock DTVターゲット用)の追加
・TvRock用デフォルトチャンネル設定ファイル作成機能の追加
・スリープ解除時待機時間の値が0の時、スリープ復帰時の処理が正しく行われない不具合を改善
・放送波に不正データが発生した時のリカバリ処理を見直し
・WinXPでICカードリーダーを列挙できなくなる不具合を修正
・WinXPでメニュー表示がおかしくなる点を改善
ver 1.05 2011/5/21
・自動・手動チャンネルスキャン機能を追加
・受信開始・受信停止が極短時間で行われた場合やストリーム受信中にスリープした場合、まれにECMデータ・EMMデータの待ち行列がクリアされずにたまり続ける不具合を改善
・ストリームデータ破棄処理でBonDriver_VTPT内の一部データが廃棄されない不具合を改善
・WinXPでICカードリーダーを列挙できなくなる不具合を修正
ver 1.04 2011/4/3
・まれにスクランブル解除が正常に行われない不具合を改善
・拡張モードでチャンネルスキャンが長時間掛かる問題点を改善
ver 1.03 2011/4/1
・拡張チャンネルモードの追加(仮)
・スクランブル解除機能追加
・BCAS関連処理の追加
・パケット・サービス・ストリームの種類によって受信するか指定できるように修正
・DMAバッファサイズを設定画面で変更できるように修正
・不可軽減
・メモリ解放の不具合を修正
・管理者権限の無いユーザーでメニューが表示されない不具合を修正、又、管理者権限の無いユーザーでサービス登録等を行った際のエラーメッセージを修正
・各種調整
ver 1.02 2011/1/18
・「PT1/PT2 SDK ver 2.x」のみの対応から「PT1 SDK ver 1.x」・「PT1/PT2 SDK ver 2.x」の両方に対応
・ストリーム補助コードのチェック／非チェックを切替可能に(PT2X2対応)
・各種調整
ver 1.01 2011/1/12
・ストリーム受信中にサービス停止または一時停止するとサービスが異常終了する不具合を修正
・BonDriver_VTPTでストリーム受信中にサービスとの接続が切断された後に再接続されると正常にストリーム受信再開が出来ない不具合を修正
ver 1.00 2011/1/7
・新規リリース
2011年01月09日
デジタルAVパソコンを構築するにあたり、最初はOSにWindows Server 2008 (x86版)を選択したのですがクラッシュが頻発したので、このOSの使用をあきらめ64ビットOS上で32ビット版アプリケーションを動作させることで安定稼動させることが出来ました。この状況から少なからずいるであろう32ビットOSを使用されている方々は苦労されているのではないかと思い(後にXPの32ビット版では問題なく動作することが分かり32ビットOS全ての問題では無いことが分かりましたが)、32ビットOS上でも安定稼動するものが作れないかと考えたことが、私がPT2関連のアプリケーションを開発してみようと考えるきっかけとなりました。また、TV視聴ソフトであるTVTestの出来はとてもすばらしく、これがもしなかったらPT2の存在価値が無いと思えるほど十分な機能を備えたとてもすばらしいソフトなのですが、TV録画ソフトやEPG番組表ソフトは、必要十分な機能を備えているのでしょうが、ちょっと安定しなかったり、この機能はどうしても欲しいというものが無かったりと、すばらしいものではありますがあと一歩というものばかりだったので、TV録画ソフトやEPG番組表ソフトも後々開発していけたらと考えています。
PT2等の物理チューナーとTV視聴・TV録画ソフトの間を取り持つBonDriverというものがあります。「拡張ツール中の人」さんが考案した種類の異なるチューナーを同様に扱えるようにしたインターフェースでDLLで実装します。これまでに数種が開発されており、PT2で使えるものはBonDriver_PT2、BonDriver_PT-ST、BonDriver_PT-ST-shm、Spinelといったものが有ります。
| 名前 | 複数プロセスでデバイス共有 | 複数プロセスでチューナー共有 | 共有メモリ使用 | 32ビット・64ビット両対応 | ネットワーク対応 | スクランブル解除 | 備考 |
|---|---|---|---|---|---|---|---|
| BonDriver_PT2 | × | × | × | × | × | × | 開発者向けBonDriverという位置付け。運用には向かない |
| BonDriver_PT-ST | ○ | × | × | ○ | × | × | 複数プロセスでデバイスを共有出来るように拡張したもの |
| BonDriver_PT-ST-shm | ○ | × | ○ | × | × | × | BonDriver_PT-STの負荷を軽減する為に共有メモリを使用 |
| Spinel | ○ | ○ | × | × | ○ | △ | 複数のBonDriverをラップし高機能化したBonDriver |
まず、VirtualPTの当面の目標としては、PT1・PT2専用とはなりますが、上記BonDriverの機能を網羅し、受信したデータを既存のTV視聴・TV録画ソフトになるべく少ない負荷で安定して放送波を供給することを目指します。さらには、ネットワーク越しのアクセスを可能にしたり、放送波のスクランブル解除をTV視聴・TV録画ソフトで行うのではなく、スクランブル解除されたデータを供給することも考えています。
VirtualPTが最終的に目指すところとしては、
- 安定稼動
- 常駐プロセスはサービス
- 32ビット・64ビット両対応
- 複数のアプリケーションで同一のチャンネルにアクセスする場合はチューナーを共有
- ネットワーク経由でアクセス可能
- ローカルコンピュータ内の通信は共有メモリ
- スクランブル解除をVirtualPT内で行い、視聴・録画ソフト側では行わない
- 1枚のBCASカードをネットワーク越しに共有
- 複数枚のBCASカードを分散管理
- 使いやすい番組表(チャンネルのグループ管理等)
- VirtualPT専用録画ソフト
- 外出時でも携帯から録画予約可能
- 録画ファイル再生機能
- wmv形式に変換しながらストリーミング配信
現バージョン迄で、実現したものは、
- 常駐プロセスはサービス 1.00～
- 32ビット・64ビット両対応 1.00～
- 複数のアプリケーションで同一のチャンネルにアクセスする場合はチューナーを共有 ver 1.00～
- ネットワーク経由でアクセス可能 ver 1.00～
- ローカルコンピュータ内の通信は共有メモリ 1.00～
- スクランブル解除をVirtualPT内で行い、視聴・録画ソフト側では行わない 1.03～
- 複数枚のBCASカードを分散管理 1.03～
となります。
「32ビット・64ビット両対応」については、やはり64ビットOS上では64ビットアプリケーションを使用した方がベストなパフォーマンスを発揮できると考えます。VirtualPTでは全てを両対応でと考えております。
Windows Server 2008 (x86版)でクラッシュが頻発した現象は、現バージョン(ver1.00)の時点では改善されていませんが、原因がスクランブル解除にありそう(スクランブル解除をせずに録画した場合は全く現象が起きなかったことから)というところまでは分かりました。なので、「スクランブル解除をVirtualPT内で行い、視聴・録画ソフト側では行わない」が完成した時点で改善できると考えています。
↑ver1.03ではVirtualPT側でスクランブル解除を行うことで改善されたことを確認しました。
「複数枚のBCASカードを分散管理」については、チャンネル毎にどのBCASカードを使うか(あるいはどれでも良い)という設定が必要になると思います。他にも必要条件があるかもしれません。あったら良さそうと思ったのですが、難易度のわりに必要とする方がどれだけいるのかが疑問なので、やらないかもしれません。
↑BCASカード1枚の処理能力があまり高くないことから負荷分散の意味でこの機能の実装意義があると判断し、ver1.03から実装しました。又、どのBCASカードがどのチャンネル(番組)に対応しているかの判断は自動で行うようにしました。
「録画ファイル再生機能」については、BonDriver_Fileという必要十分な機能を備えたものが既にあるのですが、64ビット版が無いためにTVTestも32ビット版を使わざるをえないといった方が（私も含めて）いらっしゃると思います。BonDriver_Fileの64ビット版があれば必要の無い機能と思います。
「wmv形式に変換しながらストリーミング配信」は、ノートパソコン等で無線LAN経由でTV視聴するにはビットレートを下げないと帯域が問題になるのではと思ってのことなのですが、使い方によってはインターネット経由で不特定多数に公開することも可能になってくるわけで、その辺のことがクリアできないと完成しても一般公開はしないかもしれません。他はなんとか開発＆公開したいと考えています。
「安定稼動」については、上記のクラッシュ多発の様な現象を改善することはもちろんですが、使用していただいた方々から不具合報告がなくなった時に達成だと考えています。これが一番難易度が高く最後まで達成できないかもしれませんが、可能なものは改善していきたいと思いますので、不具合を発見しましたらぜひお知らせ下さい。
関連するアプリケーション群(BonDriver互換ソフト等も含めて)において、録画ファイルのコピープロテクトが掛からないことにより、不特定多数に公開される危険性があるわけですが、コピープロテクトが掛かるメーカー製の製品においても、DVD・ブルーレイ経由でコピープロテクトを外す方法があるわけで、そこが問題だとは考えておりません。使用する側のモラルの問題だと考えております。そして、関連するアプリケーション群を使われる大多数の方々はモラルを守って使用していると考えております。
トラックバックURL
コメント一覧
「VirtualPT設定例：基本編：③TVTest設定」ではBS・CSについては解説しておりません。TvRockをお使いの場合、以下のページを順番に説明どおりに操作してください。
「VirtualPT設定例：基本編：①設定準備」
「VirtualPT設定例：基本編：②VirtualPT設定」
「VirtualPT設定例：基本編：③TVTest設定」
「VirtualPT設定例：応用編：BS・CS設定」
「VirtualPT設定例：応用編：TvRock設定」
VirtualPTを導入しようとしましたが、途中で挫折しました
③TVTest設定 でbs,csがスキャンできませんでした。
コメントする
2011年01月09日
VirtualPTはアースソフトPT1・PT2等のチューナーをラップし仮想チューナーを公開するサービスアプリケーションです。BonDriverインターフェースに対応しているアプリケーション（TVTest(TV視聴)、TVRock(TV録画)、EpgDataCap_Bon(TV録画)等）でお使いいただけます。仮想チューナーは無制限に作成できますが、物理チューナーの制限内で自動的に最適な物理チューナーを割当て・共有します。TV視聴ソフトとTV録画ソフトで同じチャンネルを受信しても、自動的に1つの物理チューナーを共有するので、TV録画中はTV録画ソフトからUDP経由で視聴するというような面倒なことをする必要がなくなります。
初期リリースでは、BonDriver互換アプリケーション(TVTest,TVRock,EpgDataCap_Bon等)からの使用に限られますが、将来的にはVirtualPT専用録画ソフト等も開発したいと思っています。BonDriver互換では無くVirtualPT専用とすることで、BonDriver互換では出来ないことも実現できると考えています。その場合でも、もちろんBonDriver互換アプリケーションからも使用できます。
ver1.03からはVirtualPT側でスクランブル解除が行えるようになります。各視聴・録画ソフトでスクランブル解除を行う必要が無くなり、VirtualPTでスクランブル解除を一元実行できるようになります。
ver1.09からはPlex PXシリーズ(PX-W3PE、PX-S3U、PX-S3U2、PX-W3U2、PX-W3U3)でもご利用いただけるようになりました。また、チューナー・周波数別に受信可否が選択できるようになりました（独立U局対応）。
ver1.11からはアースソフトPT3でもご利用いただけるようになりました。また、PSIセクション別の受信設定が出来るようになりました。
全ての機能は無料でお使いいただけますが、皆様からの寄付を募集しております。使用してみてお金を払う価値があると感じた方は、寄付にて金銭的支援をしていただければ幸いです。金銭的支援は今後の活動のモチベーションを保つためにも大変励みになります。
※VirtualPTでスクランブル解除したデータの取り扱いについては、どのような事態になってもいっさいの責任を負いかねますので、自己責任でのご利用をお願いします。