/librejp/ - librejp end

 >>/160063/
> failed to process: delivery.domand.nicovideo.jp:443
> 	javax.net.ssl.SSLException: readHandshakeRecord
> 	Caused by java.io.IOException: 確立された接続がホスト コンピューターのソウトウェアによって中止されました。
> failed to process: delivery.domand.nicovideo.jp:443
> 	javax.net.ssl.SSLException: 確立された接続がホスト コンピューターのソウトウェアによって中止されました。
> 	Caused by java.io.IOException: 確立された接続がホスト コンピューターのソウトウェアによって中止されました。
> failed to process: https://nicoad.nicovideo.jp/video/publish/sm43708803?frontend_id=6&frontend_version=0
> 	java.net.ConnectException: Connection refused: connect
>  >- NicoCacheを使わない場合は表示出来ますか
> 表示できません
NicoCache関係ないと思う。
しかし、これらが何で起きるのかよく分からない。
セキュリティ機能が原因か、あるいはネット回線によってはこういう不安定さにつながる通信があるからそれかな。

- https://nicoad.nicovideo.jp/ は表示出来ますか
- 同じネット回線上で、NicoCacheを使っていないスマホか別PCを使って https://nicoad.nicovideo.jp/video/publish/sm43708803?frontend_id=6&frontend_version=0 ここにアクセス出来ますか

 >>/160064/
> - https://nicoad.nicovideo.jp/ は表示出来ますか
表示できません
- 同じネット回線上で、NicoCacheを使っていないスマホか別PCを使って https://nicoad.nicovideo.jp/video/publish/sm43708803?frontend_id=6&frontend_version=0 ここにアクセス出来ますか
スマホからはアクセスできます

 >>/160065/
回線はok。
- 同じPCでNicoCacheを設定していない別のブラウザではどうでしょう
- もし接続出来る場合は、NicoCacheをそのブラウザに設定してみてからもう一度試してみてください

スクリーンショ... png
(48.57 KB, 716x571)

 >>/160066/
> - 同じPCでNicoCacheを設定していない別のブラウザではどうでしょう
ダメみたいですね(Edge)

 >>/160065/
同じ回線のスマホでアクセス出来て、そのPCだとアクセス出来ないとするとPCの設定かセキュリティソフトの問題ですね・・・

もうNicoCacheの領分ではないけれども、コマンドプロンプトで

nslookup nicoad.nicovideo.jp

の結果はどうですか。
これらに似たアドレスになれば正常。
18.65.168.31
18.65.168.62
18.65.168.77
18.65.168.102

 >>/160068/
サーバー:  UnKnown
Address:  192.168.146.58

名前:    nicoad.nicovideo.jp
Address:  127.0.0.1

 >>/160065/
> 名前: nicoad.nicovideo.jp
> Address: 127.0.0.1
ローカルに飛ばされるってことは何かWindowsレベルのシステムプロキシが設定されてるかhostsがおかしいです。

システムプロキシ
https://support.microsoft.com/ja-jp/windows/03096c53-0554-4ffe-b6ab-8b1deee8dae1

hosts は %WinDir%\System32\Drivers\Etc にその名前のファイルがあるのでメモ帳などで中身を確認出来ます。

 >>/160070/
"C:\Windows\System32\drivers\etc\hosts"を見てみましたが中身は空（コメントアウトがあるのみ）でした

> # Copyright (c) 1993-2009 Microsoft Corp.
> #
> # This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
> #
> # This file contains the mappings of IP addresses to host names. Each
> # entry should be kept on an individual line. The IP address should
> # be placed in the first column followed by the corresponding host name.
> # The IP address and the host name should be separated by at least one
> # space.
> #
> # Additionally, comments (such as these) may be inserted on individual
> # lines or following the machine name denoted by a '#' symbol.
> #
> # For example:
> #
> #      102.54.94.97     rhino.acme.com          # source server
> #       38.25.63.10     x.acme.com              # x client host
> 
> # localhost name resolution is handled within DNS itself.
> #	127.0.0.1       localhost
> #	::1             localhost

プロキシ設定は「設定を自動的に検出する」がオン、「セットアップスクリプト」がオンでhttp://127.0.0.1:8080/proxy.pacになっているので合ってますよね。
「設定を自動的に検出する」は要らないのかな？
そもそもプロキシをオフにしてもnicoad.nicovideo.jpにアクセス出来ない。

 >>/160071/
hostsは空だからok。
> 設定を自動的に検出する
「セットアップスクリプトを使う」「スクリプトのアドレス」もそれでok。

ちょっと調べた感じだと「設定を自動的に検出する」(WPAD, Web Proxy Auto Discovery)がオンだと、どこからか別のpacを拾ってくるみたい。
セットアップスクリプトよりも優先されると書いてあるから、pacの取得は失敗しているはず。
必要ないならオフの方がいいです。

> そもそもプロキシをオフにしてもnicoad.nicovideo.jpにアクセス出来ない。
オフにした状態で nslookup nicoad.nicovideo.jp してみて下さい。

> Address: 192.168.146.58
この値もわずかですが疑わしいです。
普通はルーターの値になるから192.168.146.1みたいなキリの良い数字になるはず。
（家庭用LANセグメントで146という値を使ってるのもだいぶ珍しい。）
このアドレスがどの端末のものか分かりますか(自PC, ルーター, 他PCなど)。
特別に構成されたDNSサーバーに問い合わせに行っている可能性があります。

 >>/160073/
後出しで申し訳ないのですが、今の私のネット環境が少々特殊なのです。これが関係している可能性が大いにあります。
光回線が引けない環境なので、スマートフォンのホット・スポット（アクセスポイント）経由でインターネットに接続しています。
ミニPC⇔スマホ⇔ネット　みたいな感じです。
スマホはルート化済みで、AdAwayが入っているのでそれもブロックの一因になってるかと思い、
https://nicoad.nicovideo.jp/video/publish/sm43708803?frontend_id=6&frontend_version=0
へのアクセスをスマホ経由で試してみましたがAdAwayオンオフに関係なくブロックされたりされなかったりまちまち。
とりあえず許可リストのドメインには入れましたが(nicoad.nicovideo.jp)。

> オフにした状態で nslookup nicoad.nicovideo.jp してみて下さい。
結果は同じです。設定変更の適用に時間がかかるとか無いですよね？
設定変更後の数百ミリ秒後に試しちゃってますが。

> この値もわずかですが疑わしいです。
> 普通はルーターの値になるから192.168.146.1みたいなキリの良い数字になるはず。
> （家庭用LANセグメントで146という値を使ってるのもだいぶ珍しい。）
> このアドレスがどの端末のものか分かりますか(自PC, ルーター, 他PCなど)。
> 特別に構成されたDNSサーバーに問い合わせに行っている可能性があります。
ネットワークにあんまり詳しくないのでDNSサーバとか聞かれてもなんのこっちゃって感じで分からないですが、Windows 11をセットアップしたときにネットワークで弄ったのはホット・スポットに接続するためのWi-Fiのセットアップ(SSIDを見つけてパスワード入力)だけだったはずです。
スマートフォンもネットワークに関係あるのはAdAwayだけのはず。あとはahamoとpovoのデュアルSIMにしているくらいかな。あとは初期設定のままのはず。祖母の家にはWi-Fiも無いので関係ないはず。自分の家の光回線のHGWのWiFiのセットアップもしたけど関係ないよね？

 >>/160074/
だいぶ納得。
それならDNSサーバー(ドメイン名からIPアドレスを返してくれるサーバー, 名前解決してくれるサーバー)の設定も特におかしくないです。
192.168.146.*というセグメントアドレスもスマホなら分かる。
wifi関連の設定は関係ないと思う。

>  >オフにした状態で nslookup nicoad.nicovideo.jp してみて下さい。
> 結果は同じです。設定変更の適用に時間がかかるとか無いですよね？
実行のたびに名前解決をしにいくはずです。

AdAwayはブロック対象のドメインに対して127.0.0.1を返すようだからその動作が原因の可能性は高いです。

> AdAwayオンオフに関係なくブロックされたりされなかったりまちまち。
ドメイン名とIPアドレスの対応はブラウザがキャッシュするからAdAwayをオフにしてもすぐには反映されないはず。
ウェブの説明からするとスマホ側のhostsを書き換えるらしいから、AdAwayが実行されていなくても影響は続きます。
AdAwayの「hosts取得先」のチェックを全部外して「適用」してみては？

あとはAdAwayの「ログの記録」をした状態で問題のURLにアクセスして、 nicoad.nicovideo.jp が含まれているかどうかの確認。スマホ側とPC側の両方。
（通信ログの記録が出来るってことはDNSサーバーとして振る舞ってるっぽい）

モバイル回線だと節約モードって名前の通信介入がある可能性もあるけれども、ahamoとpovoにはこれはなさそう。

> とりあえず許可リストのドメインには入れましたが(nicoad.nicovideo.jp)。
これで治らないかな。

 >>/160075/
>  >とりあえず許可リストのドメインには入れましたが(nicoad.nicovideo.jp)。
これで直ったみたいです。ありがとうございました。

 >>/160076/
good.

動画内のすべてのコメントをテキストに出力、抽出することは可能ですか？

 >>/160081/
https://public.nvcomment.nicovideo.jp/v1/threads
このURLに対するPOST通信の応答がjson形式のコメントデータだからこれを加工すれば可能だけど、どちらの機能も実装されていないです。
過去にはコメントを記録する拡張があったけど多分今は仕様が違うから動かないはず。

まずは nvcomment.nicovideo.jp をNicoCache用の偽装ドメインに追加せねば。

回答ありがとうございました

例えば
http://www.nicovideo.jp/watch/sm39334235 [Embed]
でUserPage経由でコメント保存しようとすると（「保存:コメント」を選ぶ）、
https://www.nicovideo.jp/cache/1631612645.xml
みたいなページに飛ばされて
「ページ読み込みエラー」「安全な接続ができませんでした」みたいな表示っすねー。
本体にもエラー表示は無いので分かりません。

 >>/160086/
以前はコメントはXML形式でした。
今は違うからその機能は動かないです(ソース読んでないけど)。

そんなに難しい問題ではないので作業には入れてます。

ところでgenCertsはca.*を上書きすると思っていたけど間違ってました。
これならconfigに応じて証明書自動生成に繋げられる。
今の方法だと一次配布のドメイン設定とユーザー独自のドメイン設定の混在が難しいし。

開発版34 2024-11-18

https://nicocache.jpn.org/download.php?id=253&key=631f904d23f05602d2545b87e65689f8d202289c27b4cb0f5cd670e5b9a49dd6

- コメント保存機能を仮追加. 保存するだけ. 表示方法なし.
　- autoCacheCommentがtrueである場合に動作します(all,one,[0-9]+もtrueと等価).
　- この設定値はcacheCommentExtension仕様を流用したものです.
　- /.data/comment.0.ja-jp.json に保存されます(ロケール部(ja-jp)はニコニコ動画の動作言語ごとに変わります).
　- json構造を含めた細かい仕様は未定.
- ディレクトリ仕様: cahcedir/.data/ を追加.
　- このディレクトリには一つの動画に紐付いているとみなせる情報を配置します.
　- プレフィックスで区別出来るようにしてください.

仕様がなかなか決まらないので仮実装版リリース。
上記の通り cacheフォルダ/sm1234.data/comment.0.ja-jp.json にコメントjsonが保存されます。
ファイルの中身をjson formatterに通すなり、google chromeで開いてプリティプリントにチェックを入れるなりすると人間でも読めるようになります。

 >>/160097/
コメント取得ありがとうございます。

キャッシュコンプリート時に無限ループするバグがまだある。
- 動画セグメント受信時ではなくprocessMasterPlaylistを通った処理から起きる。
- プレイリストが揃っているにも関わらず何度か再認識させてもmissingありと出る。
- 10個のワーカーで無限ループする。
- DomandCVIEntryにカウンタープロパティを設置することで回避は出来る。

 >>/160108/

　稀に普通に全部再生したはずなのに、nltmpのままというのが起きているんですが、これと同じの可能性はありそうでしょうか？
（感覚的には1%程度の確率）

https://nicocache.jpn.org/download.php?id=257&key=631f904d23f05602d2545b87e65689f8d202289c27b4cb0f5cd670e5b9a49dd6

開発版35 2024-12-02:
- 下位品質のhlsキャッシュがある状態で上位品質をキャッシュコンプリート前処理する際に時々無限ループするバグを修正.
- 下位品質のdmc/hls動画(1/tsフォルダがあるもの)があると上位品質の再生とキャッシュを抑制してしまう問題は未着手(現時点ではキャッシュ削除による回避しか方法なし).

- 今回の変更ファイルはNicoCache_nl.jarだから、このファイルの上書きでの更新が可能です。

例えばsmXXX[720p,128]_title.hlsというキャッシュを持っている状態で、smXXX[1080p,128]_title.hlsをキャッシュしようとした場合に体感だと20回に1回ぐらいの確率で失敗してました。

 >>/160110/
NicoCacheを終了→起動してから、その動画ページを再び開くことでキャッシュコンプリートが成功していた場合はたぶん同じ原因です。
下位品質キャッシュを持っていない場合でも起きる可能性はあったから。

dareka/processor/impl/DomandCVIEntry.javaのsegmentsComplete()よりも先がレースコンディションに耐えられてなかったみたいです。

 >>/160111/

　対応ありがとうございます。テストしてみます。

　ところで、
*compilation*
というログみたいなファイルがjarファイルに含まれているのですが、何でしょうか？
（というか、こんなファイル名が作れるとは知らなかった）

 >>/160111/
上げなおし

https://nicocache.jpn.org/download.php?id=263&key=631f904d23f05602d2545b87e65689f8d202289c27b4cb0f5cd670e5b9a49dd6

 >>/160112/
ぎゃー、やらかした。教えてくれてありがとう。
中身は無害だったからセーフ。

*compilation* はソースコードをビルドして、配布用アーカイブファイルを作って、それを展開・設定・動作させたというログそのものです。
emacsというエディタ上でビルドするとその名前のバッファが作られて、そこにビルドログが出ます。
本来は保存されないはずなんだけど、なにかの間違いで保存されて、そのファイルをant/build.xml/jar条件が拾った。
配布前にgit diffで差分は見てたんだけど、jarファイルの中身までは確認しなかったのが敗因だ。

> （というか、こんなファイル名が作れるとは知らなかった）
こちらはlinuxだから扱えるんだけど、Windowsだとエクスプローラー上でこういう名前をつけようとすると拒否されるから無理だと思ってました。

NicoCache_nlってWebSocket対応してる？
ブラウザとプロキシサーバー間でログのやり取りするのにWebSocketが最適と聞いたんだけど

 >>/160114/
していない。
動画関連で必須にならない限りプロキシーフレームワークにWebSocket対応を組み込む作業は低優先順位です。
ログ送受信のためだけにWebSocketを使うほどの利点はないし。

https://nicocache.jpn.org/download.php?id=275&key=631f904d23f05602d2545b87e65689f8d202289c27b4cb0f5cd670e5b9a49dd6

リリース 2024-12-05
- 無限ループ検出閾値を4から200に

デバッグ用の数値設定のままで、動画ページを4回更新するとエラーしていたのを修正。

 >>/160120/
ありがとうございます。

https://nicocache.jpn.org/download.php?id=292&key=631f904d23f05602d2545b87e65689f8d202289c27b4cb0f5cd670e5b9a49dd6

開発版37 2024-12-11:
- 下位品質の非互換hlsキャッシュが上位品質の再生とキャッシュ保存を抑制してしまう問題を修正.
dmc時代のhls形式のキャッシュ(フォルダ内に1というフォルダを含むようなもの)が存在するとその品質以上の再生とキャッシュ保存が抑制されていた.

例えば360pがキャッシュされていると1080pを選んでいても360pのキャッシュが強制的に利用されていた.

取り逃しに繋がるバグはこれで潰れたはず。

CustomCach... java
(5.19 KB, 0x0)

スクリーンショ... png
(11.5 KB, 747x467)

addTabSampleを参考に拡張機能を開発しているのですがどうしてもログウィンドウのタブが複数個になってしまいます。
確実に防ぐ手立てはありますか？

 >>/160128/
左の"CacheReturn"タブがここ(のメソッド内処理)で追加されているもので
> util = new ExtUtil(this, LOG_PREFIX, PROP_DEBUG);

右の"CacheReturn"タブはここで追加されているものっぽいです。
> NLMain.addTab("CacheReturn", null, scrollPane, "キャッシュ検索結果");

 >>/160129/
直りました、ありがとうございます。

https://www.nicovideo.jp/local/CustomCache/sm43909418.mp4
のようなURL形式だと問題なく再生できるのですが、
https://www.nicovideo.jp/local/CustomCache/sm43909418[720p,192]_【ニコカラ】 モエチャッカファイア 【 On vocal 】.mp4
のように少しでもアルファベットと数字以外の記号や２バイト文字列が含まれていると404 Not Foundになってしまうみたいです。
開発者コンソールのネットワークタブを見ると
https://www.nicovideo.jp/local/CustomCache/sm43909418_%E3%80%90%E3%83%8B%E3%82%B3%E3%82%AB%E3%83%A9%E3%80%91%20%E3%83%A2%E3%82%A8%E3%83%81%E3%83%A3%E3%83%83%E3%82%AB%E3%83%95%E3%82%A1%E3%82%A4%E3%82%A2%20%E3%80%90%20On%20vocal%20%E3%80%91.mp4
こんな感じで読み込まれているんだけど404になっていて不可解です。
これはNicoCache_nlの仕様ですか？ブラウザの仕様ですか？
拡張機能側では何も出来ませんか？

CustomCacheReturner.javaは現状ただCustomCache内のフォルダのファイルパスを返すだけの拡張機能ですが、

これを拡張して
例えば/cache/play?(smid)みたいな形にして内部でファイルとurlをマッピングすれば再生できるかなと思ったのですが仕様なら無理ですかね💦

 >>/160131/
"local/CustomCache"フォルダに"sm43909418[720p,192]_【ニコカラ】 モエチャッカファイア 【 On vocal 】.mp4"という名前のファイルがあるにも関わらず
> https://www.nicovideo.jp/local/CustomCache/sm43909418_%E3%80%90%E3%83%8B%E3%82%B3%E3%82%AB%E3%83%A9%E3%80%91%20%E3%83%A2%E3%82%A8%E3%83%81%E3%83%A3%E3%83%83%E3%82%AB%E3%83%95%E3%82%A1%E3%82%A4%E3%82%A2%20%E3%80%90%20On%20vocal%20%E3%80%91.mp4
これが404 Not Foundになるっていう意味？

それならNicoCache_nlがパーセントエンコーディングのデコードをしていないんだと思う。

この2つのURLは同じ扱いをされるべきだけど、パーセント側は404してしまう。
https://www.nicovideo.jp/cache/log
https://www.nicovideo.jp/cache%2Flog
これは仕様というよりも不具合(未対応)だから直す予定に入れます。

パーセントエンコーディングって(pathを"/"で分割するよりも前の)pathを受けた時点でデコードしていいんだっけ…
そうなるとフレームワーク側のコードを触らなきゃいけない。

 >>/160133/
> "local/CustomCache"フォルダに"sm43909418[720p,192]_【ニコカラ】 モエチャッカファイア 【 On vocal 】.mp4"という名前のファイルがあるにも関わらず
>  >https://www.nicovideo.jp/local/CustomCache/sm43909418_%E3%80%90%E3%83%8B%E3%82%B3%E3%82%AB%E3%83%A9%E3%80%91%20%E3%83%A2%E3%82%A8%E3%83%81%E3%83%A3%E3%83%83%E3%82%AB%E3%83%95%E3%82%A1%E3%82%A4%E3%82%A2%20%E3%80%90%20On%20vocal%20%E3%80%91.mp4
> これが404 Not Foundになるっていう意味？

そうです。そういう意味です。

 >>/160133/
>  この2つのURLは同じ扱いをされるべきだけど、パーセント側は404してしまう。
>  https://www.nicovideo.jp/cache/log
>  https://www.nicovideo.jp/cache%2Flog

　これは別扱いのはずですね。上はcacheディレクトリのlogディレクトリ（またはファイル）になりますが、下は「cache/log」というディレクトリ（ファイルシステム的に「/」が含められるかは置いておいて）になるはずです。
　確か、パーセントエンコーディングは、URIのデリミタとパス名を区別するために作られたものだったはずなので。

>  パーセントエンコーディングって(pathを"/"で分割するよりも前の)pathを受けた時点でデコードしていいんだっけ…

　区別がつかなくなるので、普通はパス分割が先ですね。

 >>/160135/
> 　区別がつかなくなるので、普通はパス分割が先ですね。
多くのwebサイトは/の代わりに%2Fを使ってもそれを/として処理するから、path部はデコードが先だと推測してます。
query部は間違いなくパラメーター分割後にデコード。
この挙動はなにかの規格(たぶんRFC3986)に従っているはずだけどどこに書いてあるかまだ見つけられていません。
> 　確か、パーセントエンコーディングは、URIのデリミタとパス名を区別するために作られたものだったはずなので。
とりあえずはlocal以下は/分割後にデコードっていう仕様にしようか。
この仕様なら"/"をファイル名に含めることだって出来るし(そんなシステム存在しないと思うけど)。上流であるプロキシーフレームワークを実装しているコードを変更するよりも下流の変更の方が下手を踏まなさそうだし。

たぶん他のNicoCache WebAPIにも同じ未対応が存在するけど、とりあえずは諦め。

https://nicocache.jpn.org/download.php?id=304&key=631f904d23f05602d2545b87e65689f8d202289c27b4cb0f5cd670e5b9a49dd6

開発版38 2024-12-17
- ローカルファイルサーバ機能にパーセントエンコーディング対応を追加.
  これにより特殊な字や日本語を含むファイル名にアクセス出来るようになりました.

- パーセントエンコードしていない[]を含むURL、例えば https://www.nicovideo.jp/local/sm123[360p,64].mp4 にアクセスした場合に https://www.nicovideo.jp/local/sm123 に転送される問題は未解決。
- ローカルファイルサーバ機能では、not foundなどのエラーがhttpステータスでのみ示されて、content bodyが空なのも未解決。

 >>/160131/
これで期待通りに動くと思います。

 >>/160137/
ありがとうございます。期待通りです。

 >>/160137/
このページですが、URLで使える文字について参考になりますでしょうか？
https://www.asahi-net.or.jp/~ax2s-kmtn/ref/uric.html

 >>/160140/
どういう質問か分からない。
こっち(  >>/160136/ )とのアンカーミス？

 >>/160142/
横からですが、RFC3986についてとちゃき#//FjlVさんが言及したのでURLの内容がそれに沿った内容になっているので参考資料として提示したのかな、と推測します。名無しなので証拠無いですが >>/160140/と >>/160128/は別人です。

No.160140 (252)です
はい、 >>/160136/ へのアンカーミスです、申し訳ない。
他の方が指摘しているように、参考資料になればと

 >>/160144/
どうもどうも。
でも違うのです。
ここ(  >>/160136/ )とここ(  >>/160133/ )で私が分からないと言っているのはこれです。
> パーセントエンコーディングって(pathを"/"で分割するよりも前の)pathを受けた時点でデコードしていいんだっけ…
%2Fは/を示すため以下の2つは意味上は同じはずです。
http://localhost/abc/123/xyz.txt
http://localhost/abc%2F123%2Fxyz.txt
実例だとこの2つ。
https://ja.wikipedia.org/wiki/CPU
https://ja.wikipedia.org/wiki%2FCPU
他のサイトでも概ね等価に扱われます(でも"/.."を末尾に付加した時の動作は等価とは言えない)。
"/"を含む特殊なサブパスを表すためには使われていないようです。

URLのpath部においてパーセントエンコードされた表現とデコードされた表現を同じ意味として扱うのであれば、httpサーバーとしての処理の上流で、path部をデコードしたものに置き換えた方がいいということになります。そうすると、対応範囲が広がって上のようなURLも扱えるようになる。
ただ、プロキシー動作をする上では都合が悪いから等価だという確信があっても全面採用はしないんですが、WebAPI用のpath(/localや/cache)ではそうした方が良いかなと考えていました。

2024-12-17版では/local/よりも先に限ってのみデコードする動作になってます。
上の説明例は全部レアケースだしこれで事足りるはず。

スクリーンショ... png
(87.67 KB, 1870x717)

もしかして削除済み動画や非公開動画のランディングページってNicoCache_nl内でダイレクト接続になっている？
埋め込まれるはずのjavascriptとかが軒並み無い。
キャッシュを再生できるページを作ろうかなと思ったけど困りました。

ん？ああ、非公開動画のURLをいきなり開くと何も挿入されてなくて
視聴ページから遷移すると挿入されているみたいですね

 >>/160147/
 >>/160146/
遷移だと公式のjsがページを構築するからその関係ですね。
通常ページの時点でlocal/nllib_watch.jsのvideoChangedイベントを仕込んでおいて再生不能動画に反応する実装になると思います。


ところで動画ページの仕様が若干変わったみたい。
全部の品質のチャンクにちょっと要求が飛ぶ。

failed to process: nicovideo.cdn.nimg.jp:443
	javax.net.ssl.SSLException: 確立された接続がホスト コンピューターのソウトウェアによって中止されました。
	Caused by java.io.IOException: 確立された接続がホスト コンピューターのソウトウェアによって中止されました。
+

って出まくって動画が読み込めない症状どうしたらいいんだろう…
本体再起動しても直らんし…テザリングの影響あるのかな？