New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
リモート視聴がエラー:MEDIA_ERR_SRC_NOT_SUPPORTED #10
Comments
端末、ブラウザは何を使用でしょうか? もう一つ考えられる原因といてはEpgDataCap_Bonからのデータの送信が確認できない場合です それとここの設定は特に必要ありませんのでご自身の環境にあった設定をどうぞ |
お返事ありがとうございます。 ちなみにもう一つの発見ですが、出力をmp4にすると、ファイル再生を止める時ffmpegが引き続きCPUを使っているらしいです。ページをリフレッシュすると閉じるらしい。webmなら赤×で視聴を止めるとffmpegも閉じるようです。 |
WindowsでもということなのでおそらくEpgDataCap_Bonからのデータ送信ができてないだと思います
EpgDataCap_Bonからのデータ送信開始前にffmpegを起動してしまうとソースなしということなのかうまくいかないのでEpgDataCap_Bonからのデータ送信が確認できてから起動してるようにしています。 ffmpegが起動したかどうかは'edcb.io.popen'の最後の引数に'true'を指定すれば確認プロンプト画面が表示されるので一時的に追加してみてください。 |
SendTSTCP.dllはちゃんとEpgDataCap_Bonやlua52.dllなどと同じフォルダに置いてあります。EDCBをビルドするとき一緒にビルドした模様です。これは今使っているSendTSTCP.dllです。 リソースマネージャーのネットタブで見てみたら、EpgDataCap_BonのUDPをチェックするとき、16MbpsくらいのI/Oが発生するに対し、TCPのチェックを入れるときネット使用が完全に止まっていました。やはりTCP送信ができていないみたいですが、考えられる原因は何でしょうか? |
そちらのSendTSTCP.dllを使っても問題なくできたのでSendTSTCP.dllの問題ではなさそうですね この機能の元となったLegacy WebUIのview.luaではどのようになるでしょうか? |
legacyのフォルダはビルド後全く触っていませんのでよくわからないです。添付します。 一応 |
ありがとうございます |
長らく付き合わせていただいて本当にありがとうございました。 最後に一つ気になる点がありまして、関係なかったらもうあきらめるつもりです。 |
関係ありそうですね |
msvcr100d.dllエラーの原因がわかりました。 |
WinSCard.dllについては自分で調べてください。 |
事情が事情ですので、WinSCardについては触れないでおきましょう。 |
クローズ寸前?に横から失礼します。 実は(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では、 唯一リモート視聴っぽいことが出来たのは、Android機にアプリMagnezioを入れてWin7のEMWUIにアクセスした場合で、Android機のChromeでリモート視聴のTVアイコンをタップすると、Magnezioが起動して視聴できました。(ただしこれはUDP通信。あらかじめEpgDataCap_BonのUDP送信先にAndroid機のIPアドレスとポート番号の設定が必要でした) 詳しいことはわかっていないのですが、ご参考になれば幸いです。 |
corftonさん、情報提供ありがとうございました。 |
amkzkuさん、お返事ありがとうございます。 未だ解決には至っていませんが、上記のEMWUIさんのご助言を参考に数日間調べたところ、ようやく原因の一角が見えてきた気がしています。以下に私の調査と検証の内容を書きますが、LuaもC++もほとんど知識経験がありませんので、とても乱暴なもの(もしかしたら全く外している)かもしれないことをあらかじめお断りしておきます。 結論から先に書きます。私のWin7環境においては、EDCBの機能のedcb.FindFile()が名前付きパイプを対象とした場合に正しい値を返さないことが原因ではないかと思えます。(Win10環境なら同機能は正常動作) FindFileについてはxtne6fさんのEDCBのDocument/Readme_Mod.txtに記述があります。指定したファイルの存在を検出し、存在する場合はファイルの情報を返し、そうでない場合はnilを返します。私のWin7環境では、通常ファイルを指定した際は正常に機能しますが、名前付きパイプを指定した際はnilが返ってきます。 以下、調査内容を記します。 (ア)名前付きパイプを表示するツール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()が通常ファイルと名前付きパイプでどういう値を返すのかを表示する機能を持たせたつもりです。 (エ)上記の(イ)で表示されたSendTSTCP_0_xxxxのxxxxの数字をメモします。 (オ)エディタなどを使ってtest.luaを開き、15行目「SendTSTCP_0_9999」の「9999」の部分をメモした数字に書き換え、上書き保存します。(3桁の場合は4桁にせず3桁のまま記述します) ====Win7 64bit での実行結果(例) ====Win10 での実行結果(例) 上記を踏まえて以下の通り検証してみました。 内容は、\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はバックアップしておいてください) (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さんも上記をお試しいただき結果を教えていただけるとうれしいです。かといって解決のためのプログラミングなど私の力量では及びもつかないのですが。 よろしくお願いします。長文失礼しました。 |
これは完全な推測なのですがwin7とwin10ではWOW64(x86のエミュレート機能)に厳密には違いがあるのですがそこが原因だったりしないでしょうかedcbのソリューションファイルには64bitビルドもあるので試してみては如何でしょうか |
16dyuiさん、お返事ありがとうございます。 corftonさん、調査・検証ありがとうございます&お疲れ様でした! |
spinel利用でしたらspinel側bondriverは32bitでspinel bondriverは64bitで設定してみてください。 |
16dyuiさん、こちらはもともとSpinelを導入していないので、色々模索しながらなんとかSpinel側でWinSCardが使えるようになって、一応x64視聴環境が整えました。(x64EDCB+x86Spinelの感じですが) |
念の為確認なのですがEDCBと表記がありますがepgtimer srvの方からluaを利用してるのでepgtimer srvは64bitでしょうか |
16dyuiさん、そうです、ソースコードでx64をビルドして作った環境です。 |
検証の方ありがとうございますでは関係なさそうですねこちらでも少し検証してみます |
16dyuiさん、ご助言ありがとうございました。 amkzkuさん、ツールで検証していただきありがとうございます。 概要 導入は下記のファイルを解凍して得られる4つのファイルを所定の場所に配置するだけです。 (ア) \EDCB\Tools に配置 (イ) \EDCB\HttpPublic\api に配置 操作方法は、普通に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アイコンを再タップすれば視聴できることが多いので、これはクライアント側の問題だろうと思っています。 よろしくお願いします。 |
corftonさん、大変お疲れ様でした! しかし、さっそく導入してみましたが、予想通り稼働してくれませんでした。 1)get_pipename.batが正しく稼働していません。 2)EMWUIでget_pipename.batを実行すると、pipename.txtに何も書きだせないようです。 今はここ↑で詰んじゃいました。 |
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の出力などがバ~っと表示され、キー入力待ちになります。お手数おかけしますがよろしくお願いします。 |
もしかして、EpgTimerSrv.exeの設定が不十分ということはないですか? |
corftonさん、大変うれしいご報告です。こちらにもやっと、やっとリモート視聴ができました! 検証の詳細を書きます。 暫定対策はローカルのChromeで検証していました。 これでようやくリモート視聴ができます!本当にありがとうございました! P.S.追加検証を行いました。 ついでに一つ思うことがあります。 |
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/ あたりにヒントがありそうですが、私には十分理解できませんでした。 とりあえず、こうすればリモート視聴ができることもある、ということで恒久対策などは高技能の方々にお任せできればと思います。横槍失礼しました。 追伸 |
現象再現しないのでなんともいえないが、FindFileについて、 先行実装の EMWUI/EDCB_Material_WebUI#10 への対応例も追加
xtne6f/EDCB@798324c 以降が必須 複数対応 Magnezio用ページを改良 xtne6f/EDCB@bcb5d2b を反映#10 NwTV.ps1を非サーポート
ご対応ありがとうございます。検証してみましたので報告します。 ・環境 ・検証(1) 「Error:MEDIA_ERROR_SRC_NOT_SUPPORTED 詳細?」
がChrome上に表示される ・検証(2) ・その他 |
ひとまず対処できたようなのでよかったです ちょっと気になる部分を
と表示されたとのことですがどこかでエラーが発生しています
と表示されたのはミスです |
EDCBをインストールしているPCにはFireFoxをインストールしていないので、LAN内の別PC(ubuntu14.04)の古いFireFox(バージョン 45.0.2)からリモート視聴してみました。 以下、エラートーストの「詳細?」部分をクリックした後のFireFoxの表示です。やはり2パターンありますが、どうしたらどちらが表示されるかまでは検証できていません。 パターン(1)
パターン(2)
ご参考になれば幸いです。 |
わざわざありがとうございます |
早速のご対応、ありがとうございます。
なお小事ですが、次回更新時にでも、TvCast 96行目の「見つかりまでした」は「見つかりませんでした」に修正していただけるとありがたいです。よろしくお願いします。 |
お恥ずかしい。。。 |
FIND_BY_OPENを設定ファイルから呼び込むように #10 iosの場合強制的にmp4で配信するようにした
FIND_BY_OPENを設定ファイルから読み込むようにしました |
xtne6f/EDCB@798324c 以降が必須 複数対応 Magnezio用ページを改良 xtne6f/EDCB@bcb5d2b を反映EMWUI#10 NwTV.ps1を非サーポート
FIND_BY_OPENを設定ファイルから呼び込むように EMWUI#10 iosの場合強制的にmp4で配信するようにした
私のWindows7も上手く動かなかったので、素人ながらソースコードを眺めたり 原因としてはPathUtil.cppのEnumFindFile内でWindowsAPIのFindFirstFile それでいろいろ調べてみたらWindowsの名前付きパイプはNamed Pipe FileSystemという .netFrameworkで .netFrameworkの方は自分の試し方が悪いのかもしれませんが、 もしかしたらNamed Pipe FileSystem関連の不具合なのかもしれません。 ※ ¥¥.¥pipe¥の部分ですが上手く表示できなかったので環境依存文字の¥を使用しています。 |
素人なりにいろいろ調べてみたらFindFirstFile内部でNtQueryDirectoryFileって関数を呼んでいて、 パイプ名を指定しなければパイプの一覧が取得できるので、ワイルドカードを処理する 構造体などの宣言やワイルドカードを処理するところに適当にコピペが多少混ざっているので 以上 |
=問題の様子=
放送中タブで任意のサービスのリモート視聴を押してしばらく砂嵐すると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も一緒に閉じる。
もしかしてどこかで設定を間違っているや忘れているかもしれませんから、色々ご指導いただけたら幸いです。よろしくお願いします。
The text was updated successfully, but these errors were encountered: