search

EMWUI / EDCB_Material_WebUI

69 stars 18 forks source link

リモート視聴がエラー：MEDIA_ERR_SRC_NOT_SUPPORTED #10

Closed amkzku closed 5 years ago

amkzku commented 5 years ago

＝問題の様子＝ 放送中タブで任意のサービスのリモート視聴を押してしばらく砂嵐するとERR：MEDIA_ERR_SRC_NOT_SUPPORTEDが表示して再生できない。

＝使っている環境＝ xtne6f氏のEDCBバージョンwork-plus-s-181019をWin7・VS2015でビルドしてみた。 B25Decoderを使っている。 EMWUIのcommit cfe3926【日付2018年10月9日】までのソースコードを使っている。 ffmpeg-4.0.2-win32-staticを使っている。readexはEDCB同梱しているのをビルドしたもの。 ライブラリからの再生は問題なく出来ている。

＝問題の再現手順＝ ①EpgDataCap_Bonの設定でTCP送信を0.0.0.1:0に追加。 ②EpgTimerの設定で外部アプリケーション・NetworkモードとUDP・TCP送信をチェック。 ③EpgTimerSrvの設定でUDP・TCP送信を許可する。 ④EMWUIを立ち上げ、放送中タブで任意のサービスのリモート視聴を押してしばらく砂嵐するとERR：MEDIA_ERR_SRC_NOT_SUPPORTEDが表示して再生できない。 ⑤EpgDataCap_Bonは無事起動していて、サービスも指定したサービスになっている。TCP送信もチェックされている。 ⑥EMWUIで再生を閉じる、EpgDataCap_Bonは閉じることなくそのまま開いている。

＝予想の正常稼働＝ ①リモート視聴が正常稼働。 ②再生画面を閉じるときEpgDataCap_Bonも一緒に閉じる。

もしかしてどこかで設定を間違っているや忘れているかもしれませんから、色々ご指導いただけたら幸いです。よろしくお願いします。

EMWUI commented 5 years ago

端末、ブラウザは何を使用でしょうか？ iosであった場合webMに対応してない場合が多いのでmp4で配信する設定にすればできると思います

もう一つ考えられる原因といてはEpgDataCap_Bonからのデータの送信が確認できない場合です 最大5秒間送信されてるか確認してるのでこの時間を長くしてみてください 方法としてはapi/TvCastの72行目if ff or retry > 25 then break endの25という数字を大きくしてください 25*200で5000ms(5秒)です

それとここの設定は特に必要ありませんのでご自身の環境にあった設定をどうぞ ＞ ②EpgTimerの設定で外部アプリケーション・NetworkモードとUDP・TCP送信をチェック。 ＞ ③EpgTimerSrvの設定でUDP・TCP送信を許可する。

amkzku commented 5 years ago

端末、ブラウザは何を使用でしょうか？ iosであった場合webMに対応してない場合が多いのでmp4で配信する設定にすればできると思います

もう一つ考えられる原因といてはEpgDataCap_Bonからのデータの送信が確認できない場合です 最大5秒間送信されてるか確認してるのでこの時間を長くしてみてください 方法としてはapi/TvCastの72行目if ff or retry > 25 then break endの25という数字を大きくしてください 25*200で5000ms(5秒)です

それとここの設定は特に必要ありませんのでご自身の環境にあった設定をどうぞ ＞ ②EpgTimerの設定で外部アプリケーション・NetworkモードとUDP・TCP送信をチェック。 ＞ ③EpgTimerSrvの設定でUDP・TCP送信を許可する。

お返事ありがとうございます。 WindowsのChrome・FirefoxとAndroidのFirefoxから試みました。いずれ最新版です。 送信確認を30秒まで伸ばしてみたのですが、相変わらずERR：MEDIA_ERR_SRC_NOT_SUPPORTEDが出ました。 タスクマネージャーを観察してみたが、ファイル再生の時ffmpegが立ち上がるが、リモート視聴だと立ち上がらないんです。これは何らかの関係があるのでしょうか？

ちなみにもう一つの発見ですが、出力をmp4にすると、ファイル再生を止める時ffmpegが引き続きCPUを使っているらしいです。ページをリフレッシュすると閉じるらしい。webmなら赤×で視聴を止めるとffmpegも閉じるようです。

EMWUI commented 5 years ago

WindowsでもということなのでおそらくEpgDataCap_Bonからのデータ送信ができてないだと思います TCP送信の設定は間違ってなさそうなのでSendTSTCP.dllがあるか確認をお願いします。

リモート視聴だと立ち上がらないんです。これは何らかの関係があるのでしょうか？

EpgDataCap_Bonからのデータ送信開始前にffmpegを起動してしまうとソースなしということなのかうまくいかないのでEpgDataCap_Bonからのデータ送信が確認できてから起動してるようにしています。

ffmpegが起動したかどうかは'edcb.io.popen'の最後の引数に'true'を指定すれば確認プロンプト画面が表示されるので一時的に追加してみてください。 ただ真っ黒な画面で何か表示されるとかはないです f=edcb.io.popen('""'..ffmpeg..'" -f mpegts -i "\\\\.\\pipe\\'..ff[1].name..'" '..XOPT..'"', 'rb',true)

amkzku commented 5 years ago

SendTSTCP.dllはちゃんとEpgDataCap_Bonやlua52.dllなどと同じフォルダに置いてあります。EDCBをビルドするとき一緒にビルドした模様です。これは今使っているSendTSTCP.dllです。 SendTSTCP.zip

リソースマネージャーのネットタブで見てみたら、EpgDataCap_BonのUDPをチェックするとき、16MbpsくらいのI/Oが発生するに対し、TCPのチェックを入れるときネット使用が完全に止まっていました。やはりTCP送信ができていないみたいですが、考えられる原因は何でしょうか？

EMWUI commented 5 years ago

そちらのSendTSTCP.dllを使っても問題なくできたのでSendTSTCP.dllの問題ではなさそうですね 送信先を0.0.0.1にすると、TCPではなく名前付きパイプになるのでネットワークはそれで正常だと思います 視聴中に確認してみましたがネットが使われる様子はなかったです データ送信ができてないという原因についてはTCPの設定ミスまたはSendTSTCP.dllがないくらいしか申し訳ないですが思いつかないです

この機能の元となったLegacy WebUIのview.luaではどのようになるでしょうか？ 事前にEpgDataCap_Bonの起動、TCPのチェックを入れておく必要があります。

amkzku commented 5 years ago

legacyのフォルダはビルド後全く触っていませんのでよくわからないです。添付します。 legacy.zip

一応http://localhost:port/legacy/view.luaを開いてみましたがChromeの404ページが返ってきました。debuglog.luaやnotifylog.luaのようなNot Found or Forbidden.と違います。

EMWUI commented 5 years ago

ありがとうございます こちらのコードの方も疑ってみたのですが404が返ってくるということなのでデータの送信ができてないということで間違いないと思います ですが原因についてはこれ以上は思いつかずすいません。

amkzku commented 5 years ago

長らく付き合わせていただいて本当にありがとうございました。 これはもしかしてEDCBの方に聞く方がいいか気がしてきましたがなんだかんだで疲れてきました。

最後に一つ気になる点がありまして、関係なかったらもうあきらめるつもりです。 実は最初にEDCBのチャンネルスキャンの時、消しても消しても「msvcr100d.dllが見つかりません」のメッセージが出てきましたので、ネットで拾ったmsvcr100d.dllをそのままEDCBのフォルダに置いてすべてが落ち着きました。 「system32にコピーしregsvr32 msvcr100d.dllする」を試しましたが、エラーばっかりですので、まあ大丈夫かなと思って。 「Visual C++ 2010 再頒布可能パッケージ x86とx64」はちゃんと事前に入れました。それでも「msvcr100d.dllが見つかりません」なので、仕方なく。 これは、もしかして関係あったりするのでしょうか？

EMWUI commented 5 years ago

関係ありそうですね そのエラーが出るのはランタイムが正しくはいってないからのはずです そして入れなければならないランタイムはビルド環境によって違うものを入れなければならないはずです

amkzku commented 5 years ago

msvcr100d.dllエラーの原因がわかりました。 フォルダ内にあるWinSCard.dllを一時削除したらエラーが出なくなりました。 その反面、録画したtsが再生できなくなりました。 WinSCard.dllを削除しても、TCP送信は依然にできないままでいます。 これは…どうするものでしょうか。

EMWUI commented 5 years ago

WinSCard.dllについては自分で調べてください。 ここでは助言することができません。 またその環境でWinSCard.dllを削除したならばTCP送信できてたとしてもffmpegでトランスコードできませんよ

amkzku commented 5 years ago

事情が事情ですので、WinSCardについては触れないでおきましょう。 これで気になる点もなくなり、送信できない原因はもう思いつきません。 ですので、もう諦めます。今まで本当にありがとうございました。

corfton commented 5 years ago

クローズ寸前?に横から失礼します。

実は(msvcr100d.dllエラーとWinSCard.dllは別として)、私の環境(Win7Pro 64bit)でもamkzkuさんと同じMEDIA_ERR_SRC_NOT_SUPPORTEDの現象が起きます。しかし、構築したxtne6f氏のEDCB(32bit版)とEMWUIを、ファイル一式(設定内容を含む)丸ごとWin7からWin10Pro(1803)に乗せたらあっさりリモート視聴が機能しました。(Win10にはC++ランタイム2005、2008、2010、2015、2017(いずれもx86)をインストールしてあります)

Win7では、 ・EDCBとEMWUIの設定を色々試す ・ブラウザはChrome、FireFox、Vivaldiを試す、キャッシュも削除する ・C++ランタイム、.NETフレームワーク等、バージョン違いやx64なども入れてみる ・xtne6f氏のEDCBとEMWUIの各Releaseの組み合わせを試す ・WindowsUpdateを当てる ・IE11を導入する など色々試しましたが、リモート視聴機能だけはMEDIA_ERR_SRC_NOT_SUPPORTEDでどうしても動きません。(TVTestはEpgDataCap_Bon.exeからのTCPで正しく映ります)

唯一リモート視聴っぽいことが出来たのは、Android機にアプリMagnezioを入れてWin7のEMWUIにアクセスした場合で、Android機のChromeでリモート視聴のTVアイコンをタップすると、Magnezioが起動して視聴できました。(ただしこれはUDP通信。あらかじめEpgDataCap_BonのUDP送信先にAndroid機のIPアドレスとポート番号の設定が必要でした)

詳しいことはわかっていないのですが、ご参考になれば幸いです。

amkzku commented 5 years ago

corftonさん、情報提供ありがとうございました。 まさかWindowsの問題？でしたなんて、想像すらしませんでした。 さっそくWindows10入れてみます…と言いたいところですが、あいにくパソコンがWindows10非対応ですので、さすがにこれは仕方ありません。 自分はこれで諦めますが、corftonさんの情報は大変参考になるものですので、このイシューをご覧になった誰かさんのためになれたらいいなって思っています。

corfton commented 5 years ago

amkzkuさん、お返事ありがとうございます。

未だ解決には至っていませんが、上記のEMWUIさんのご助言を参考に数日間調べたところ、ようやく原因の一角が見えてきた気がしています。以下に私の調査と検証の内容を書きますが、LuaもC++もほとんど知識経験がありませんので、とても乱暴なもの(もしかしたら全く外している)かもしれないことをあらかじめお断りしておきます。

結論から先に書きます。私のWin7環境においては、EDCBの機能のedcb.FindFile()が名前付きパイプを対象とした場合に正しい値を返さないことが原因ではないかと思えます。(Win10環境なら同機能は正常動作)

FindFileについてはxtne6fさんのEDCBのDocument/Readme_Mod.txtに記述があります。指定したファイルの存在を検出し、存在する場合はファイルの情報を返し、そうでない場合はnilを返します。私のWin7環境では、通常ファイルを指定した際は正常に機能しますが、名前付きパイプを指定した際はnilが返ってきます。

以下、調査内容を記します。

(ア)名前付きパイプを表示するツールpipelist.exeをダウンロードします。 https://docs.microsoft.com/en-us/sysinternals/downloads/pipelist コマンドプロンプトを開きpipelist.exeを実行すると、現在の名前付きパイプの一覧が表示されます。

(イ)EpgDataCap_Bon.exeを起動します。ネットワーク設定でTCP送信先に0.0.0.1ポート0が設定してあれば、再びpipelist.exeを実行することで、一覧の中にSendTSTCP_0_xxxx (注:xxxxは数字。3桁のこともありました)の行を見つけることができます。ちなみにこの数字部分はEpgDataCap_Bon.exeプロセスIDなので、EpgDataCap_Bon.exeを終了→起動する度に異なる値に変化します。

(ウ)下記のtest.luaを\EDCB\HttpPublic\legacyにコピーします。test.luaは、edcb.FindFile()が通常ファイルと名前付きパイプでどういう値を返すのかを表示する機能を持たせたつもりです。 test.zip

(エ)上記の(イ)で表示されたSendTSTCP_0_xxxxのxxxxの数字をメモします。

(オ)エディタなどを使ってtest.luaを開き、15行目「SendTSTCP_0_9999」の「9999」の部分をメモした数字に書き換え、上書き保存します。（3桁の場合は4桁にせず3桁のまま記述します）

(カ)Chromeでhttp://localhost:5510/legacy/test.luaを開くと、edcb.FindFile()の返す値が表示されます。私のWin7では、通常ファイル(ここではffmpeg.exe)の場合は何らかの値が返りますが、名前付きパイプの場合は常にnilが返ります。(Win10ではどちらも何らかの値が返る。下記参照)

====Win7 64bit での実行結果(例) Checking function of edcb.FindFile() path of ffmpeg.exe = C:\DTV\EDCB\Tools\ffmpeg.exe ← 実在する通常ファイル名 ffmpeg.exe exist or not, checked by edcb.FindFile()= table: 05ACC050 ← 値が返る name of named pipe= SendTSTCP_0_3712 ← pipelist.exeで確認した実在するパイプ名 named pipe exist or not, checked by edcb.FindFile()= nil ← nilが返る

====Win10 での実行結果(例) Checking function of edcb.FindFile() path of ffmpeg.exe = C:\DTV\EDCB\Tools\ffmpeg.exe ffmpeg.exe exist or not, checked by edcb.FindFile()= table: 00153050 name of named pipe= SendTSTCP_0_512 ← pipelist.exeで確認した実在するパイプ名 named pipe exist or not, checked by edcb.FindFile()= table: 00153000 ← 値が返る

上記を踏まえて以下の通り検証してみました。

内容は、\EDCB\HttpPublic\apiのTvCastを改変し、名前付きパイプの情報取得手段としてedcb.FindFile()を使わず、パイプ名を直指定するというものです。結果はMEDIA_ERR_SRC_NOT_SUPPORTEDエラー無しに正常視聴ができました。もちろんリモート視聴ができる設定をEpgDataCap_Bon、EpgTimerSrv、EMWUIに済ませていることが前提です。

(1)まずエラーの再現を確認します。EpgDataCap_Bon.exeが起動していない状態で、EpgTimer.exe、EpgTimerSrv.exeを起動し、ChromeでEMWUIを開きます。続いて左上の3本横棒→放送中→地デジ→いずれかの放送のTVアイコンをクリックすると、自動的にEpgDataCap_Bon.exeが起動し、砂嵐の数秒後にMEDIA_ERR_SRC_NOT_SUPPORTEDエラー。EpgDataCap_Bon.exeは起動したままです。

(2)この状態でコマンドプロンプトを開きpipelist.exeを実行、一覧の中のSendTSTCP_0_xxxx探してxxxxの数字をメモします。

(3)EpgDataCap_BonやEpgTimerSrvが起動したままの状態で、エクスプローラなどを使って、\EDCB\HttpPublic\api\TvCastを下記の改変したTvCastと差し替えます。(お約束ですがオリジナルのTvCastはバックアップしておいてください) TvCast.zip

(4)エディタなどを使って、差し替えた改変TvCastを開き、81行目の後半の「SendTSTCP_0_9999」の「9999」を(2)でメモした数字に書き換え、上書き保存します。(改変TvCastは、edcb.FindFile()による名前付きパイプの処理やエラー処理をコメントアウトして、現存する名前付きパイプ名を直指定するという乱暴なものです）

(5)Chromeに戻り(動画用ポップアップが開いていれば閉じ)、再びいずれかの放送のTVアイコンをクリックします。この状態で私の環境では正常に視聴ができました。チャンネル変更もOK。ただし、地デジをBSやCSに切り替えるとEpgDataCap_Bonが再起動されるのか、数字(プロセスID)が変わりますので、再度(2)と(4)による直指定部分の書き換えが必要です。よって常用できるような解決策にはなっていません。

私のWin7環境は、ほぼスッピン+WindowsUpdate済みで、所定のC++ランタイムや.NETフレームワークなども入れてあるので、以上の調査と検証から、Win7ではedcb.FindFile()が名前付きパイプをうまく処理できないという可能性はあるのかなぁと感じています。（もしやXPでも動作するようなビルドならばどうかと試したこともあるのですがだめでした）

よろしければamkzkuさんも上記をお試しいただき結果を教えていただけるとうれしいです。かといって解決のためのプログラミングなど私の力量では及びもつかないのですが。

よろしくお願いします。長文失礼しました。

5ym commented 5 years ago

これは完全な推測なのですがwin7とwin10ではWOW64(x86のエミュレート機能)に厳密には違いがあるのですがそこが原因だったりしないでしょうかedcbのソリューションファイルには64bitビルドもあるので試してみては如何でしょうか

amkzku commented 5 years ago

16dyuiさん、お返事ありがとうございます。 一応x64バージョン入れてみましたが、BondriverとWinSCardの連携が難航していて、まだ模索中です。

corftonさん、調査・検証ありがとうございます＆お疲れ様でした！ corftonさんの検証結果と同じ、こちらのtest.luaもnilが返され、PID指定の改変TvCastで正常に視聴できました！またこちらは地デジのみの環境ですので、チューナー一つをリモート視聴専用にすれば一応解決できた状態とも言えるでしょう。 根本的な解決はやはりEDCBさんの方へ問い合わせしたほうがいいですかね。 ご迷惑でなければ、corftonさんもx64バージョンを試してみてはいかがでしょうか？

5ym commented 5 years ago

spinel利用でしたらspinel側bondriverは32bitでspinel bondriverは64bitで設定してみてください。 またwinscardの方はうろ覚えですがspinel側に処理させる方法があった気がします。 またこちら完動品の状態(自分用に作ったので環境依存ファイルや無駄なファイルが多いですが必要な部分のみ抜いてご利用ください)であげてますのでよかったらご参考ください。 https://github.com/16dyui/PT3-soft

amkzku commented 5 years ago

16dyuiさん、こちらはもともとSpinelを導入していないので、色々模索しながらなんとかSpinel側でWinSCardが使えるようになって、一応x64視聴環境が整えました。（x64EDCB+x86Spinelの感じですが） しかし、リモート視聴はx64でもダメでした。 corftonさんのtest.luaで試した結果、同じくnamed pipe exist or not, checked by edcb.FindFile()= nilでした。

5ym commented 5 years ago

念の為確認なのですがEDCBと表記がありますがepgtimer srvの方からluaを利用してるのでepgtimer srvは64bitでしょうか

amkzku commented 5 years ago

16dyuiさん、そうです、ソースコードでx64をビルドして作った環境です。

5ym commented 5 years ago

検証の方ありがとうございますでは関係なさそうですねこちらでも少し検証してみます

corfton commented 5 years ago

16dyuiさん、ご助言ありがとうございました。 なるほどWOW64の機能差ですか!? ありそうですね。6月頃に5chでWin7でも動作しているという投稿がありましたので、何かが違うのだろうと私もずっと思っていました。 私の64bit化ですが、ほとんどのDTVアプリを32bit版で構成してしまい、いまいまこれで安定稼働しているので、まだ踏ん切りがついていません。すみません。

amkzkuさん、ツールで検証していただきありがとうございます。 私だけの現象でないことがわかり少し心強い?です。64bit対応等は検証途上と思いますが、拙い技で暫定対策版を作ってみましたのでUPします。私の64bitWin7+32bitEDCB+EMWUIでこれを使うと、Win10と同じ操作性でリモート視聴が機能します。都度エディタで値を書き換える等の操作は必要ありません。私のテストも未だ不十分ですが、よろしければamkzkuさんの環境でも検証してみてください。

概要 (1)改造TvCastが下記(2)のバッチファイルを起動 (2)pipelist.exeが名前付きパイプ一覧を出力→findとsedがSendTSTCP_0_xxxxを抽出→テキストファイルに出力 (3)改造TvCastがこのテキストファイルを読んで正しい名前付きパイプ名を得る

導入は下記のファイルを解凍して得られる4つのファイルを所定の場所に配置するだけです。 zantei.zip

(ア) \EDCB\Tools に配置 get_pipename.bat ←上記(2)のバッチファイル pipelist.exe　← https://docs.microsoft.com/en-us/sysinternals/downloads/pipelist からDL(検証時と同じもの) sed.exe ← http://gnuwin32.sourceforge.net/packages/sed.htm からDL

(イ) \EDCB\HttpPublic\api に配置 TvCast ←改造TvCast(オリジナルをバックアップの後、差し替えて利用します。バグ含みの可能性があります)

操作方法は、普通にChromeでEMWUIを開き、放送中→地デジ→いずれかの放送のTVアイコンをクリック。砂嵐10〜15秒後に映像が出るはずです。チャンネル変更もOK。映像ウィンドウを赤色×で閉じると、EpgDataCap_Bon.exeも数秒後に自動終了します。

なお、バッチファイルを起動しているため砂嵐中にコマンドプロンプトが(1〜数回、一瞬)開きます。開かない方法もいくつか試したのですがうまくいかなかったのでそのままにしています。

動作安定性はまずまずです。ローカルPC(Win7)のChrome、LAN内のUbuntuのChromium(Chrome互換ブラウザ)では今のところエラーなしで視聴が可能。しかし、同じLAN内のAndroid機のChromeではなぜか時々MEDIA_ERR_SRC_NOT_SUPPORTEDエラーが出ます。しかし、同じTVアイコンを再タップすれば視聴できることが多いので、これはクライアント側の問題だろうと思っています。

よろしくお願いします。

amkzku commented 5 years ago

corftonさん、大変お疲れ様でした！ 半ばあきらめたつもりでいたので、まさか暫定と言っても解決策がいただけるんなんて…感激です。

しかし、さっそく導入してみましたが、予想通り稼働してくれませんでした。 エラーメッセージは相変わらずMEDIA_ERR_SRC_NOT_SUPPORTEDで、プログラミングに弱いので大した調査できないのですが、自分なりに調べてみた結果、二つの問題が上がりました。

１）getpipename.batが正しく稼働していません。 　　`pipelist | find "SendTSTCP%1_"の実行の結果がないみたいです。 　　%1を0に変えたら、SendTSTCP_0_5555みたいな結果がpipename.txtに書きだしました。 　　この結果が正しいかどうかは判別できませんでしたので（設計上SendTSTCP_0_5555が出るか5555`だけ出るか。正規表現が苦手なもので）、一応もう一度リモート視聴のアイコンをクリックしてみましたが、問題２が出ました。

２）EMWUIでget_pipename.batを実行すると、pipename.txtに何も書きだせないようです。 　　１）のように改変してみたらまだMEDIA_ERR_SRC_NOT_SUPPORTEDが出るので、改造TvCastのos.remove(dir..'pipename.txt')部分をコメント化してみたら、なぜかpipename.txtが空っぽでした。 　　念のためEpgDataCap_Bonが起動した後pipelistを実行してみたら、ちゃんとSendTSTCP_0_5555がありましたし、自分でget_pipename.batを実行するとちゃんとpipename.txtに書きだせました。 　　なぜEMWUIで実行すると何も出なかったのでしょう？

今はここ↑で詰んじゃいました。 お助けください。

corfton commented 5 years ago

amkzkuさん、お試しいただきありがとうございます。

ローカルPC(Win7)のChromeで検証されていますか? 先にも書きましたがAndroidからだと不安定です。原因はAndroid側ではなくEMWUI側のような感じもしてきたのですが解読は進んでいません。

さて、ローカルのChromeで検証されていることを前提として書きます。

%1はget_pipename.batが改造TvCastから受け取る引数なのでリモート視聴では0だと思います。ならば0固定でも良かったのですが、TvCastのソースを見ると固定で処理されていなかったので、なんか理由があるのかなと思って変数にしておきました。

それと、もしpipelist.exeが出力するリストに完全にマッチするパターンが無い場合、空のファイルが出力されるのがget_pipename.batの仕様です。

EMWUIでget_pipename.batを実行した場合にpipename.txtが空ということは、おそらくget_pipename.batがTvCastから受け取る引数がおかしいのだと思います。

下記のデバッグ用TvCast、get_pipename.batに差し替えてテストしてみてください。コマンドプロンプトに受け取り引数やpipelistの出力などがバ～っと表示され、キー入力待ちになります。お手数おかけしますがよろしくお願いします。 for_debug.zip

corfton commented 5 years ago

もしかして、EpgTimerSrv.exeの設定が不十分ということはないですか? 視聴に使用するBonDriverの設定がないと名前付きパイプは生成されないと思うので、get_pipename.batが正しい引数「0」を受け取っても出力ファイルは空になります。 デバッグ版だと、コマンドプロンプトが5回連続して表示され、その後、例のエラーになります。

amkzku commented 5 years ago

corftonさん、大変うれしいご報告です。こちらにもやっと、やっとリモート視聴ができました！ 結論から言いますと、問題のキーはEpgTimerSrvがLocalServiceとしてインストールしていたことです。 EpgTimerSrvを今ログインしているアカウント（こちらの場合はAdministrator）で実行すれば、暫定対策がうまく稼働しました。

検証の詳細を書きます。

暫定対策はローカルのChromeで検証していました。 corftonさんの言った「コマンドプロンプトが(1〜数回、一瞬)開きます」の現象は全く見えなかったので、ちょっと変だなと思いましたが、深く考えていませんでした。 デバッグ用TvCast、get_pipename.batを差し替えてリモート視聴を実行してみたら、確かに砂嵐が続くし、pipename.txtも出ないので、pauseのようなキー入力待ち状態の気がしますが、コマンドプロンプトがまったく、一瞬たりとも出ていないので、すごく変だと思いました。 とりあえず%1をちゃんと確認したいので、echo %1 >a.txtに変えてみた結果、a.txtの内容にちゃんと0がありました。 続いてpipelistの行ですが、思いっきりpipelist | find "SendTSTCP"にしてみたが、それでもpipename.txtが空っぽですので、これはpipelist.exeがちゃんと実行していないのでは？と思い、タスクマネージャーを調べたら、pipelist.exeが実行しているままでした。終わっているはずpipelist.exeがなぜまだ実行しているのかを考えてみた結果、あることに気づきました。 プロセスにpipelist.exeのユーザー名がLocalServiceであることを。 EpgTimerSrvをLocalServiceとしてインストールしましたことを思い出しました。もしかしてLocalServiceだとpipelist.exeがうまく実行できないのでは？と思って、アンインストールして普通にクリックして実行してみました。 そしたらスムーズにリモート視聴ができました。 デバッグ用ではなく普通の暫定対策の方を差し替えても、リモート視聴ができます。

これでようやくリモート視聴ができます！本当にありがとうございました！

P.S.追加検証を行いました。 １）LAN内のAndroidでアクセスしてみました。Chromeでは問題なく視聴できます。例のエラーはまだ出ていません。Firefoxでは砂嵐のままです。EpgDataCap_Bonが起動されません。 ２）改変前のTvCastも試してみました。例のエラーのままです。

ついでに一つ思うことがあります。 もしかしたら、Administratorアカウントを使っているからリモート視聴できなかったのではないでしょうか？

corfton commented 5 years ago

amkzkuさん、ご報告ありがとうございます。EpgTimerSrv.exeをWindowsサービスとして利用されていたとは盲点でしたが、うまくいって何よりです。コマンドプロンプトの「一瞬窓」の有無が解決のきっかけになったとは私の手抜きの功名?でしょうか。ちなみに、zantei.zipのTvCastの49行目 os.execute を edcb.os.execute に変更したら一瞬窓は開かなくなりました(後からわかりました)。それとAdministratorアカウントは関係ないと私は思います。

32bitEDCBのedcb.FindFile()が、Win7環境において名前付きパイプを対象とした場合に正しい値を返さない現象がamkzkuさんや私以外でも起きるならば、16dyuiさんが指摘されたWindows側の問題かもしれません。しかし、32bitのpipelist.exeが一覧を表示してますから、やりようによってはできそうな気がします。 https://dev.activebasic.com/egtra/2016/01/12/857/ あたりにヒントがありそうですが、私には十分理解できませんでした。

とりあえず、こうすればリモート視聴ができることもある、ということで恒久対策などは高技能の方々にお任せできればと思います。横槍失礼しました。

追伸 私のAndroid(7.0)+Chromeで安定しない件は、FireFoxだと安定することがわかりました。Chrome(70.0.3538.80最新版)だと例の一瞬窓がパッパッと2回連続して開き、改造TvCast→get_pipename.batが連続起動されてしまいます。これが不安定さに繋がっていたようです。FireFox(63.0.2)ならこうしたことはありませんでした。なお、FireFoxは、砂嵐窓の中心のマーク(右向三角であっても下駄足跡であっても)を意図的にタップしないと映像表示を始めないようです。が、Chromeでの不安定さに較べればはるかにマシです。

corfton commented 5 years ago

ご対応ありがとうございます。検証してみましたので報告します。 結論から言うと、TvCastのFIND_BY_OPEN=falseをtrueに書き換えて、正常にリモート視聴ができました。

・環境 本イシューの暫定対策版でリモート視聴ができているWin7 64bit環境に下記を上書き xtne6f EDCB work-plus-s-190127 (32Bit版) EDCB_Material_WebUI 17dc90a

・検証(1) Chromeでリモート視聴を実行 → 視聴できず

「Error:MEDIA_ERROR_SRC_NOT_SUPPORTED 詳細?」 というトーストが表示される。 「詳細?」部分をクリックすると、 http://localhost:5510/api/TvCast?id=-1&onid=XXXXX&tsid=XXXXX&sid=XXXX&quality=288p&audio=1&null=XXX または http://localhost:5510/api/TvCast?id=-1&onid=XXXXX&tsid=XXXXX&sid=XXXX&quality=288p&null=XXX のURLがChromeの新タブで開くが、直後に、 「このページは動作していません localhostから無効な応答が送信されました ERR_INVALID_HTTP_RESPONSE」 が表示される、あるいは、数秒後に

<entry>
<success>EpgDataCap_Bonを起動</success>
<id>XX</id>
</entry>

がChrome上に表示される (注:XXXは不定の数字)

・検証(2) EDCB_Material_WebUI 17dc90aのTvCastの40行目のFIND_BY_OPEN=falseをtrueに書き換えて、リモート視聴を実行 → 視聴OK

・その他 この検証(2)の状態ではリモート視聴の複数同時配信ができるようです。しばらくこれで使ってみます。どうもありがとうございました。

EMWUI commented 5 years ago

ひとまず対処できたようなのでよかったです 自分はxtne6f氏のを反映しただけなのでxtne6f氏に感謝です もう少し様子を見てからFIND_BY_OPENの設定をiniから読み込むようにしたいと思います

ちょっと気になる部分を

「このページは動作していません localhostから無効な応答が送信されました ERR_INVALID_HTTP_RESPONSE」

と表示されたとのことですがどこかでエラーが発生しています firefoxなどではエラーが表示されどこでつまづいたかわかりますがchromeではこの画面に切り替わる仕様のようです もしよければfirefoxなどで開き表示されるエラーを教えていただけたらと

EpgDataCap_Bonを起動・・・

と表示されたのはミスです 本来は「名前付きパイプが…」となるはずでした修正しておきます

corfton commented 5 years ago

EDCBをインストールしているPCにはFireFoxをインストールしていないので、LAN内の別PC(ubuntu14.04)の古いFireFox(バージョン 45.0.2)からリモート視聴してみました。

以下、エラートーストの「詳細?」部分をクリックした後のFireFoxの表示です。やはり2パターンありますが、どうしたらどちらが表示されるかまでは検証できていません。

パターン(1) URL http://XXX.XXX.XXX.XXX:5510/api/TvCast?id=-1&onid=XXXXX&tsid=XXXXX&sid=XXXX&null=XX

C:\DTV\EDCB\HttpPublic/api/TvCast:65: attempt to concatenate global 'pid' (a nil value)
stack traceback:
    [string "mg.write(debug.traceback(), '\n')"]:1: in main chunk
    [C]: in function '__concat'
    C:\DTV\EDCB\HttpPublic/api/TvCast:65: in main chunk

パターン(2) URL http://XXX.XXX.XXX.XXX:5510/api/TvCast?id=-1&onid=XXXXX&tsid=XXXXX&sid=XXXX&audio=1&null=XXX

この XML ファイルにはスタイル情報が関連づけられていないようです。以下にドキュメントツリーを表示します。
-<entry>
  <success>EpgDataCap_Bonを起動</success>
  <id>XXX</id>
</entry>

ご参考になれば幸いです。

EMWUI commented 5 years ago

わざわざありがとうございます おかげさまで原因がわかりましたので修正させていただきました

corfton commented 5 years ago

早速のご対応、ありがとうございます。 ローカルのChromeで動作を確認しました。 エラートーストの「詳細?」部分をクリックした後、数秒後に、Chromeに以下が表示されます。未だ5〜6回程しかテストしていませんが、表示は2パターンではなく、1パターンだけのようです。

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<entry>
<error>名前付きパイプが見つかりまでした</error>
</entry>

なお小事ですが、次回更新時にでも、TvCast 96行目の「見つかりまでした」は「見つかりませんでした」に修正していただけるとありがたいです。よろしくお願いします。

EMWUI commented 5 years ago

お恥ずかしい。。。 次回に修正しておきます 一応狙い通りの動きになったようなので一安心です ありがとうござました。

EMWUI commented 5 years ago

FIND_BY_OPENを設定ファイルから読み込むようにしました 特に問題ないようなので閉じます

n2naokun commented 4 years ago

私のWindows7も上手く動かなかったので、素人ながらソースコードを眺めたり ググりまくったりしてみた結果わかった事なのですが。

原因としてはPathUtil.cppのEnumFindFile内でWindowsAPIのFindFirstFile を呼び出しているがfindDataが取得できずhFindにINVALID_HANDLE_VALUEが返って 来ることが原因なんですよね。

それでいろいろ調べてみたらWindowsの名前付きパイプはNamed Pipe FileSystemという 仕組みによって ¥¥.¥pipe¥ にマウントされるのですがこれがどうもマウントされていないようです。

.netFrameworkで System.IO.Directory.GetFiles を使用しても¥¥.¥pipe¥の一覧を取得できませんし PowerShellで Get-Childitem ¥¥.¥pipe¥ を実行しても一覧を取得できません。

.netFrameworkの方は自分の試し方が悪いのかもしれませんが、 PowerShellの方はWindows8.1で上手く動作して一覧を取得できました。

もしかしたらNamed Pipe FileSystem関連の不具合なのかもしれません。

※ ¥¥.¥pipe¥の部分ですが上手く表示できなかったので環境依存文字の¥を使用しています。

n2naokun commented 4 years ago

素人なりにいろいろ調べてみたらFindFirstFile内部でNtQueryDirectoryFileって関数を呼んでいて、 その関数に直接ワイルドカード付けてパイプを探させましたけど上手く動かなかったので 私のやり方が悪かったか何らかの原因で一部のWindows7のNtQueryDirectoryFileにバグがあるか？ 辺りなんですかね。

パイプ名を指定しなければパイプの一覧が取得できるので、ワイルドカードを処理する 関数を適当に持ってきて、その関数でヒットしたパイプ名をFindFirstFileで検索した時と 同じ形式で返したら上手く動きました。

構造体などの宣言やワイルドカードを処理するところに適当にコピペが多少混ざっているので 公開してもいいか疑わしいので私よりも詳しい方が実装してくれるのを期待してます。 ちなみに弄るのは Common\PathUtil.cpp 内の EnumFindFile 辺りです。 引数patternの値をワイルドカードの関数を使ってパイプの検索かファイル・フォルダの検索かに 振り分けてパイプ以外は今までの処理を行うようにしたらバグは少ないと思います。

以上