/librejp/ - librejp end

 >>/159715/
18だと
"failed to set workaround for allowing patch method: java.lang.Class.getDeclaredFields0"
で一部しか動かないっぽいですね。
getDeclaredFieldsのDirtyHackがとうとう塞がれてるみたい。
https://stackoverflow.com/questions/56039341/get-declared-fields-of-java-lang-reflect-fields-in-jdk12

19だとThreadの動作変更で
DirectoryWatcherが動かないんじゃないですかね。

 >>/159715/
18だと
"failed to set workaround for allowing patch method:java.lang.Class.getDeclaredFields0"
でロードは出来るけど正しく動作しないかな。
https://stackoverflow.com/questions/56039341/get-declared-fields-of-java-lang-reflect-fields-in-jdk12
DirtyHackが塞がれたからっぽい。

19は
DirectoryWatcherが上手くいかないのかな。
Threadの動作変更の影響だと思う。

ダブった上に18のは勘違いでした。
17でも
java.lang.NoSuchMethodException:java.lang.Class.getDeclaredFields0
出るけどキャッシュまわりは動きますね。

> 0062
> 2024/03/24(日) 13:35:55.49
> 起動時バージョンはNicoCache_nl version 2024-03-24
> 195で配布されているjarを直接現在使っているファイルに移動、差し替えをしてもキャッシュはできませんでした。
> ant clean 、ant jar、作業後の　NicoCache_nl.jar　もキャッシュはできませんでした 
バージョンは期待通りで正しい。
エラーも何も出ていないというのが分からない。

Q. [2024-03-24 23:22:04.868] Filters Loading Time: 35ms
  みたいな表示の後に何かでますか。

Q. その状態で動画の再生はされますか。

Q. 確実にキャッシュされていない動画を再生した時に、動画ページの一番下にURLは出ていませんか。
 (あるかないかだけ答えてくれればいいです。
　開発途中版10にはkey urlをデバッグ出力するコードを残しているので、それが動作しているかどうかを質問しています)

Q. 開発途中版10よりも前の、使ったことのある途中版番号覚えていますか。

Q. https://delivery.domand.nicovideo.jp/local/url_injection_sys.js
ここにアクセスして何か表示されますか
（スクリプトっぽい内容なら異常ナシ。Missing Keyと表示されたらconfigかproxy.pacがおかしい）

Q. コマンドプロンプトで動かしていますか。あるいはNicoCacheGUIを使っていますか。
（後者は私は使ったことがない上に動作させれないので分からないのだけれど、エラー出力が別タブになっていたような）

> Running with Java 14.0.1(amd64) on Windows 10
こちらではjava11と17でテストしてます。
14は手に入れるのにひと手間あるから試してないけど、環境が原因ならエラー出力があると思うんだよね。

 >>/159718/
Workaroundコードは、jdk/jreのバージョンが上がれば必要がなくなるはずだからそこは純粋に消しちゃえばいいはず。
今はおっかなびっくりだから残してあるけど。

移行するとしたら、まずはjava17に一本化して、workaroundを削って、それから次のLTS版javaにという感じかな。
java17以外を使っていると、起動時にメッセージと共にN秒待たせてユーザーの環境移行を促すとか。

DirectoryWatcherは必須ではないからちょっと不便状態でちょっとずつ移行していくのも手段候補。
それはともかくThreadは影響範囲が広くて何かあったら検証が難航しそうだな…

 >>/159719/
こちらのopenjdk-17-jdk 17.0.9だとそのエラーは出ないです。

5chのスレ 60,62,63,65,66とは別人ですが、同じ動画がキャッシュできるか試してみました
ログに「CMAF付与情報取得失敗」と出ていますが、動画のキャッシュはできています
キャッシュ完了後、「キャッシュ削除」ボタンからキャッシュを削除した後
ページを更新して再度キャッシュする場合はログに「CMAF付与情報取得失敗」は出力されませんでした

・環境
(ブラウザ)
FireFox 124.0.1

(Java)
openjdk 17.0.8.1 2023-08-24
OpenJDK Runtime Environment Temurin-17.0.8.1+1 (build 17.0.8.1+1)
OpenJDK 64-Bit Server VM Temurin-17.0.8.1+1 (build 17.0.8.1+1, mixed mode, sharing)

(NicoCache)
NicoCache_nl 開発途中版10-2
動画ページの一番下にURLは出ている(key urlのデバッグ出力)

・ログ1
(cmaf)no cache found: so43543401low[720p,192]_(削除).hls
+
-- audio key url: 形式ok
-- audio iv: ok
-- video key url: 形式ok
-- video iv: ok
-- audio key url: 形式ok
-- audio iv: ok
-- video key url: 形式ok
-- video iv: ok
-- video key url: 形式ok
-- video iv: ok
caching so43543401
+
-- video key: ok
-- audio key: ok
-- first segment ok: audio/001.cmfa
caching so43543401
video/001.cmfv: 未完 1572250/2122480
video/001.cmfv: 再開 1555866-2122480
-- first segment ok: video/001.cmfv
caching so43543401
++++++++
CMAF付与情報取得失敗: キー(NG), 値:(NG), smid(nullnull) (ページ更新で改善しない場合、おそらくインジェクションjavascriptかnlFilterの構成が失敗しています) https://delivery.domand.nicovideo.jp/hlsbid/65f8f5e0c1a36e06f2ce74b9/keys/video-h264-720p.key
caching so43543401
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
cache completed: so43543401low[720p,192]_(削除).hls

・ログ2
Remove All Cache: so43543401
(cmaf)no cache found: so43543401low[720p,192]_(削除).hls
+
-- audio key url: 形式ok
-- audio iv: ok
-- video key url: 形式ok
-- video iv: ok
-- video key url: 形式ok
-- video iv: ok
-- audio key url: 形式ok
-- audio iv: ok
-- video key url: 形式ok
-- video iv: ok
caching so43543401
+
-- audio key: ok
-- first segment ok: audio/001.cmfa
-- video key: ok
caching so43543401
video/001.cmfv: 未完 982426/2122480
video/001.cmfv: 再開 966042-2122480
-- first segment ok: video/001.cmfv
caching so43543401
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
cache completed: so43543401low[720p,192]_(削除).hls

< 0066
< 2024/03/25(月) 06:42:26.96
< 動画再生のページにはURLはありません 
< MissingKeyMissing Key-Pair-Id query parameter or cookie value　とでます 
NicoCacheを通らずに通信してる。

可能性2つ。mitmHostPortの設定ミスとプロキシ設定のミス。

config.propertiesにmitmHostPortを設定する項目があったら消してください。
config.properties.defaultにコメント行以外が書き込まれている場合はconfig.properties.defaultファイル自体を削除してください。

defaults/30_NicoCache_nl_TLS.propertiesに
mitmHostPort=*.nicovideo.jp *.ce.nicovideo.jp *.sl.nicovideo.jp *.domand.nicovideo.jp:* *.sv.nicovideo.jp *.nicoad.nicovideo.jp *.seiga.nicovideo.jp *.smilevideo.jp *.nimg.jp *.cdn.nimg.jp *.dmc.nico:*
の行があることを確認してください。
特に"*.domand.nicovideo.jp:*"が無い場合はそれが原因です。
アーカイブの上書きが失敗しています。(でもこれは開発途中版1で既に変更しているから可能性低い)

もう一つがproxy.pacやプロキシ設定のミス。
proxy_sample.pacを使っていれば通信出来るはずです。

ブラウザや環境に設定しているpacファイルが実在するか確認してください。
その内容を確認してください。
よく分からなければ、proxy_sample.pacをそのまま使ってみてください。

https://www.nicovideo.jp/local/url&#95;injection&#95;sys.js
https://delivery.domand.nicovideo.jp/local/url&#95;injection&#95;sys.js
これらにアクセスして両方にスクリプトっぽい内容で、NicoCache_nlという文字列が含まれている必要があります。
文字化けしててもそれは問題ではないです。

 >>/159722/
> CMAF付与情報取得失敗: キー(NG), 値:(NG), smid(nullnull) (ページ更新で改善しない場合、おそらくインジェクションjavascriptかnlFilterの構成が失敗しています)
他に動画ページを開いたままNicoCacheを再起動したりしました？
このエラーが出た後もターゲットの動画は取れてるから多分別のページのものなんだろうけど。

意図的に読み込みエラーを大量に出すとインジェクション失敗が起きることがあるからRequest Object経路を通るパターンが存在するのかな。

 >>/159724/
同じブラウザの別タブで別の動画の再生中に出ました。
再生していた別の動画はキャッシュ済みの物です。
NicoCache_nlの再起動はしていません。

< 0069
< 2024/03/25(月) 19:58:10.98
< 過去のNicoCache_nlを新しいフォルダに、3-24のNicoCache_nlを過去のフォルダとで交換し適度させたところ、
< 3-24の起動時、されたURL２つに文字化けの中にNicoCache_nlという文字列が含まれた画面が出てきました 
じゃあもう動画キャッシュ動作してるんじゃ？

< mitmHostPortが短かったのでペーストして上書き長くしました。 
短かったということは defaults/30_NicoCache_nl_TLS.properties が上書きアップデートがされてない。あるいは古いそのファイルが混入している。
書き込み禁止属性が設定されているから上書き時ダイアログで「上書きしない」を選びませんでしたか。

一度7zファイルの中からdefaultsフォルダをコピーして上書きした方がいいです。

他にも不整合が起きていそうで気になるけれど、動いているならそれでいいです。

pacファイルを元々使っていたものに戻してみて、それでキャッシュ動作するなら原因はmitmHostPortの設定だったということです。

< default部分を削除してconfig.propertiesとして機能させています
< まずかったでしょうか 
アップデート時に配布されるファイルで上書きされることを回避出来ればいいのでそれでいいです。

 >>/159725/
挙動気になる。致命的エラーにはならないけど。

虚しいところから今北産業

リリース
id.196 2024-03-26
> NicoCache_nl+150304mod+231111mod+240326mod
> 
> ・dms(domand)，2023年11月からの動画配信仕様に対応
> ・プロキシ対象のサブドメイン，*.domand.nicovideo.jpが増えました．documents/Readme_TLS.txt の手順をもう一度行なってください(開発途中版を試していた方はそのcertsのコピーでいいです)．pacファイルは変更なしです．
> ・キャッシュ拡張子はdmc時代と同じくhls
> ・個別キャッシュフォルダにmaster.m3u8さえあれば，任意のフォルダ構造をキャッシュとして配信する機能を追加
> ・文字コード変更．ソースコードやtxtファイルなど全て，Shift-JISだったのをUTF-8へ変換．半角カナなどは維持
> ・他に開発が続いているNicoCacheは見つからないため，起動時に表示されるバージョンをシンプルにします. ChangeLogでは長いバージョンの表記を使います．
> ・231111modのワークアラウンドを削除
> ・showCachingオプションを追加．断片キャッシュを受信する度にログします．しばらくはデフォルトtrue．不要な方はconfig.propertiesにshowCaching=falseを追記してください

重大そうな不具合報告が無いので安定版宣言します。

中身は開発途中版10とほぼ同じだからそれで十分な人はアップデートしなくていいです。
同梱ドキュメントが若干整理されています。

TODO:
- javaバージョンの引き上げ
| - まずはjava 17に一本化. java 17以外で起動遅延などで促し
- 不必要なWorkaroundの削除
- インストールとアップデートの簡単化
| - config_env.txt(環境設定スクリプト)の導入
| - 理想的にはconfig.propertiesを移動するだけでアップデート出来るといい
| - ユーザー用nlFiltersディレクトリ，ユーザー用localディレクトリなどを設定出来るように．
|   これがあればNicoCacheフォルダの外にユーザー用それらファイルを配置出来る．アップデート時の上書きを気にしなくてよくなる
- キャッシュ済リンクの色付けをstyle直書きではなくクラスへ
- キャッシュファイルリストの動的再読み込み

< 0075
< 2024/03/27(水) 19:46:59.85ID:ZJngD/12d
< 安定版とのことだが…
< https://www.nicovideo.jp/cache/（適当な動画ID）/auto/movie
< で動画が再生されないバグは直してもらえたのだろうか？（不安） 
そのあたりは全然触ってない。
これってそもそもファイル実体を返す機能（たぶん）だから、
hls動画はプレイヤーをどっかから見繕って来ないと再生出来ないです。
mp4はブラウザが再生に対応しているからそのまま再生出来るけれど。

まあhls.jsかな。

< 0076
< 2024/03/27(水) 23:56:17.48
< 【再生されない】ことは問題でなくて、このリンクでそもそもファイル実体が返ってこない（＝404 Not Found）ので直して欲しいという意味でした。 
そこまでは把握してます。
問題としては難しくないのだけれども、hlsは複数のファイルからなる動画だから、404を直しても無味乾燥な代表プレイリストファイル(master.m3u8)のテキストが返ってくるだけになってしまいます。
ディレクトリ型動画の存在を想定した仕様ではないため、仕様を一意に決めることが出来ないです。

というかこのAPIの目的って一体なんなのだ。
ダウンロードが目的であるならffmpegでmp4に変換してそのmp4を返すという挙動、あるいはhlsフォルダをzipでまとめて返すという挙動が重いが綺麗。
あるいはhls動画の場合は、404じゃなくて「405 Method Not Allowed」を返すというのも綺麗。

ブラウザでキャッシュ動画を再生する目的なのであれば、先の答えの通りhls.jsを使った再生ページを作るということになります(そのための基盤はdms/domandのために組んだし)。

> ./local/CustomFilters/UserPage/up.js
> 動画を新規ウィンドウに開いてローカル保存

> NicoCache_nl+150304mod+170106mod (Patch Release, 人柱版)
> ・WebAPI /cache//{movie,audio} の挙動を変更しました．
> 　これまでにlowがついていない場合は，(非dmcの)通常キャッシュとエコノミー
> 　キャッシュから自動で選択して結果を返していましたが，非dmcの通常キャッシュから
> 　結果を返すようになりました．
> 　dmcキャッシュを含めたキャッシュから自動で選択して結果を返す新しいWebAPIは
> 　/cache//auto/{movie,auto} です．

/cache/下のURL仕様は把握していないけれど、たぶん相対的参照によってファイルリソースを返すような機能がない(master.m3u8からvideo.m3u8を参照出来ないし、そこからさらに動画セグメントを参照出来ない)。
そうなると既存のURL仕様ではhlsに対応出来ないです。

Screenshot png
(292.56 KB, 1339x1128)

<>ディレクトリ型動画の存在を想定した仕様ではないため、仕様を一意に決めることが出来ないです。 
< すみません、ここどういう意味なのか分かりかねます。
旧仕様は動画が一つのバイナリーコンテンツで表せることを前提としている(flv,mp4,swfとか)。
複数のファイルからなる動画キャッシュ(hlsキャッシュ)を求められた時の振る舞いを決められない。
複数のファイルをいっぺんに配信したりダウンロードさせたりする仕様がhttpには無いから、このWebAPIには担わせられない。
といった意味合いでした。
※前提知識。hls動画は1〜3つのm3u8ファイルと複数の動画部分ファイル(ts,cmfv,cmfaなど)からなります。

< ・APIから得られた.m3u8をニコニコ動画プレイヤーに引き渡して再生させる（hlsになる前は実際にフィルタまとめで使用していました。） 
m3u8ファイルだけ渡しても関連ファイルが読めないから、単純な実装だと無理だと思います。

> # ローカルFLVサーバ機能 (true/false)
> #	flvplayer_wrapperのローカルFLVに必要な /cache/ フォルダの動作を行います
> #	/cache/.flv のアクセスに対してキャッシュを返すようになります
> #	trueで有効、falseで無効
> localFlv=true
とても古い。
フラッシュで実装されていた代替プレイヤーももう機能終了(end of life)しているから、仕様は好きに決めていいか。

m3u8を再生する場合は、その中に書かれているファイルにもアクセス出来るようなURL仕様になっている必要があります。
この要求がネックで旧仕様にはhls対応を追加出来ません。
キャッシュしているmaster.m3u8の中身だけ返してもいいけど、これが嬉しいシチュエーションは存在しないです。

例えば http://localhost/cache/sm9.hls がmaster.m3u8の中身を返し、それで動画を再生しようとした場合、中にかかれているパスに相対的にアクセスします。
だから例えば、自動的に次のようなURLへアクセスしようとします
http://localhost/cache/1/ts/playlist.m3u8
あるいは http://localhost/cache/video.m3u8

/cache/以下は既に絡まった仕様が存在するから、hlsをhlsのまま配信する仕様対応はしない。
< だからURLの選択肢で挙動が変わるのが理想的なのかも？ 
これの通り、mp4に変換して返すという処理を追加して、/cache/(smid)/auto/movie はそこへリダイレクトするというのが順当か。
ユーザーが求めるものこれだろうし。
ffmpegは必須。

< 0078
< フィルタまとめのcommon.js146行～169行目では
< https://www.nicovideo.jp/local/CustomCache/（smid）.hls/master.m3u8
< もしくは
< （smid）.mp4
< を返すようにしてニコニコ動画プレイヤーで上手く再生されてるけど何か違うのかな？ 
知らない仕様だ…
添付画像の部分のことだと思うけど、この部分って404判定されるのでは？
それにこのコードってhls動画は再生出来ないような。

順に書いてて気付いたが
> （hlsになる前は実際にフィルタまとめで使用していました。） 
これってそれの話か。

よく分からないからとりあえず考えているものを実装します。

id.197
> 開発版12 2024-03-29:
> - WebAPIを更新．/cache//auto/movie アクセス時に，smidがhlsキャッシュ動画であった場合は，下記のmp4 URLへリダイレクトし，mp4が得られます．
> - /cache/sm9.mp4
>   /cache/sm9.hls.mp4
>   /cache/sm9[360p,128].mp4
>   などにアクセスした場合に、キャッシュがhlsであっても、mp4に変換して返します.
> - ffmpegがインストールされていない場合は失敗します．
> - 開発版11は欠番です.

> - 2024-03-29: hls→mp4仕様を追加. あまり検証していないが従来の仕様とは衝突しないはず. これを実装前はhlsキャッシュに対する要求には404を返していた.
> - /cache//auto/movie アクセス時にhlsキャッシュ動画であった場合は、下記のようなmp4 URLへリダイレクト.
> - https://localhost/cache/sm9.mp4
>   https://localhost/cache/sm9.hls.mp4
>   https://localhost/cache/sm9[360p,128].mp4
>   などにアクセスした場合に、キャッシュがhlsであっても、mp4に変換して返す.
> - webm,mkv,flvへの変換にも対応しているがまだ使い途はない. 動画コンテナがコーデックを扱えない場合は失敗する.

とりあえず。

< 0080
< 2024/03/29(金) 00:28:36.35
< 違います。私が話しているのはこの行です。（しっかり行数指定したはずなのだが…）
< https://i.imgur.com/S1FV6ho.png
たぶんこっちが持っているcommon.jsが古いです。
m3u8への言及がそもそもこちらのソースコード内にない。
あとで更新します。

< この画面は/local/CustomCache/so41635862.hlsを再生しているときのものです。
この仕様も知らなかった。

でも話が見えました。
今回のアップデートは回避策として機能すると思います。

< https://www.nicovideo.jp/cache/(smid)/auto/movie
< がmaster.m3u8を返せば良いという問題でもなくなるのか。 
< という風に読み込もうとするから/local/フォルダでは上手く機能しても
< https://www.nicovideo.jp/cache/(smid)/auto/movie
< では上手く機能しないのか。やっとわかった。 
はい。

hlsキャッシュフォルダのファイルを配信するための機能はNicoCache本体に書いたので、そこへリダイレクトするという手もあります。
（この配信機能を使ってdms動画キャッシュは動いてます）
WebAPI/URL仕様を定めてNicoCache外部からの要求にも答えられるようにすれば、mp4にしなくてもhlsが使える。

まずはhls配信用の独自パス( /eachcache/key1=value1&key2=value2//master.m3u8 )を /cache/each/ とか /cache/smidfiles/ とかにする作業が先。
仕様の不統一感は残さない方が良い。

< 0100
< 2024/03/30(土) 23:53:02.67
< 安定版12使ってるんだけど、4分程度のボカロ系の音源を70個ぐらい同時に開くと、キャッシュに失敗するね
< 「ページを更新してください」ってログに沢山出てきてる 
12は開発版です。というのはおいといて。
「ページを更新してください」エラーは大量リクエストだからと言って出るはずはないから、想定漏れ・設計ミスがやっぱりあるみたいです。
（大量リクエストによるエラーならただ単に再生が止まるか、プレイリストが不正だってエラーになるはず）

ニコ動は利用していないと思っていたRequestコンストラクタ経路もurl_injection_sys.jsの対応に入れてみます。

あるいはインジェクション用スクリプトがheadタグの一番最初に来ないのがいけないかな。
このスクリプトよりも先に挿入されるのはどれもNicoCache関連だから問題無いはずだが。

あ。
連想配列の上限(30個)にひっかかってるんだ。
内部の問題だ。
単に拡張すれば上手く動くようになるはず。
とりあえず300。

dmc時代も似たような処理をやってたから、同じような制限にひっかかってたはずだけど、何で上手くいっていたのだろう。

id.198
開発版13 2024-03-31:
- 内部的な同時キャッシュ上限を動画30個から200個へ
- /cache/ のキャッシュリスト処理が失敗していたのを修正．キャッシュファイルの最終サイズがnullを返す場合があり、それで例外エラーしていた
- 内部で使っていたURLの /eachcache/ を /cache/file/ へ移動
- javascriptのRequestオブジェクトにインジェクション用ラップを追加

 >>/159737/
開発版13だと、ニコニコ動画の画面上部のメニューが表示されなくなります。開発版12に戻すと大丈夫でした。

Firefoxだと
>  - javascriptのRequestオブジェクトにインジェクション用ラップを追加
の部分がエラーになって止まっているように見えます。

url_inject... txt
(5.68 KB, 0x0)

id.199
開発版14 2024-04-02:
- 開発版13で追加したjavascriptのRequestオブジェクトインジェクション用ラップを削除

今回の変更は url_injection_sys.js だけだから、添付ファイルの中身で local/url_injection_sys.js を差し替えることでも対応出来ます。

 >>/159738/
ありがとうその通りみたいです。

< 0125
< 2024/04/02(火) 03:58:42.47
< 開発版13を使っています
< ニコレポの取得に失敗します
< 12の方では機能しておりました 
これも同じ原因でした。

id.203

開発版16 2024-04-07:
- java21で動くように．
　- Workaround.javaの実装を変更(この実装もjava22以降では使えないのだとか)
　- 起動スクリプトNicoCache_nl.{bat,sh}を変更．java起動引数を追加．

開発版15 2024-04-XX:
- "Connection reset by peer"判定に関するWorkaroundを削除(回避すべきバグがjava11で再現しないため)．

変更の大部分は Workaround.java です。

 >>/159742/
21.0.2で動きました。
あと >>/159719/
で出た17.0.10のエラー、JVMがOpenJ9 0.43だったからでした。

 >>/159743/
検証素早い。
> あと >>/159719/
> で出た17.0.10のエラー、JVMがOpenJ9 0.43だったからでした。
実を言うと私java詳しくないのだけれど、openjdk付属のとは別のjava仮想マシンを使ったらエラーしたということ？

旧:
> Method getDeclaredFields0 =
>     Class.class.getDeclaredMethod("getDeclaredFields0", boolean.class);

新:
> for (Method x : classMethods) {
>     if ("getDeclaredFields0".equals(x.getName())) {
>         declaredFieldMethod = x;
>     };
> };

なんでここ違うのかなと思いながら写経してた。汎用性に違いがあるのかな。
もしかすると新実装(java21対応板NicoCache)だと例外出ないかも知れない。

 >>/159744/
そうですね。Adpotium OpenJDKとかのHotspot VMではなくて
OpenJ9 VMが使われてるSemeru JDKで動かしてました。
https://eclipse.dev/openj9/
JDKのバージョンと一対一じゃないので、ドキュメント外の動作は最新版に沿いやすいんですよね。
でも殆どの場合Hotspot VMなので気にしなくて大丈夫です。

開発版16、Semeru 21.0.2（opneJ9 0.43）で動かすと
'failed to set workaround for allowing patch method: Cannot invoke "java.lang.reflect.Method.setAccessible(boolean)" because "" is null'
ってなりますけど本体の動作はします。Extensionはわからない。

 >>/159745/
ダメか。しかも予想外なところがエラーしてる。
あとは手元で検証しないと分からない感じ(重要でないらしいし、なさそうだから今はやらない)。

2010年に追加された機能
> # (実験的機能) HTTPヘッダに非ASCII文字を含めるブラウザでも
> # 動作するように試みる。(true/false)
> useWorkaroundForEncoding=false

2022年に不具合修正された機能
> # JavaのHttpURLConnectionがPATCHメソッドを受け付けるようにする
> #   JavaのHttpURLConnectionはPATCHメソッドのリクエストを送信させようとすると
> #   許可されているメソッドの一覧に含まれていないとして例外を投げるため、
> #   リフレクションを利用してこの許可リストを書き換えることで回避する．
> #   PATCHメソッドはタイムシフト予約などで使用されている．
> useWorkaroundForAllowedMethods=true

この2つのためにリフレクションによる動的書き換えコードがあるだけだから、例外が出ても動きはします。
残りもう1つのdirty workaroundは終了時に接続切断を早めるためのものだし。

ニコニコのトップ画面を開くと毎回こんな感じのログが出ます。
以前はトップ画面で表示される動画はキャッシュしていなかった気がするのですが、勘違いですかね？

・ログ
CMAF付与情報取得失敗: (キー:ng, 値:ng, smid:nullnull) (ページ更新で改善しない場合、おそらくインジェクションjavascriptかnlFilterの構成が失敗しています) https://asset.domand.nicovideo.jp/661224c5b689b8443fc767b2/audio/1/audio-aac-192kbps/36.cmfa　(長いのでカット)

・環境
(ブラウザ)
FireFox 124.0.1

(Java)
openjdk 17.0.8.1 2023-08-24
OpenJDK Runtime Environment Temurin-17.0.8.1+1 (build 17.0.8.1+1)
OpenJDK 64-Bit Server VM Temurin-17.0.8.1+1 (build 17.0.8.1+1, mixed mode, sharing)

(NicoCache)
NicoCache_nl 開発版13
動画ページの一番下にURLは出ていない

(proxy.pac)
サンプルでついてきた proxy_sample.pac を proxy.pac にリネームして使用

 >>/159747/
トップみたいなページの動画では、動画ID(sm123)が取得出来なくて必ずキャッシュ失敗するので、エラー表示が鬱陶しい以外には実害はないはずです。
でもエラー表示が過剰なので後でなんとかしておきます。

> 以前はトップ画面で表示される動画はキャッシュしていなかった気がするのですが、勘違いですかね？
旧仕様がどうやって回避してたかは調べてないです。
dms(domand)仕様でもキャッシュしようという意図はないです。

実装上、動画形式のURLが来ると反応しちゃうのでそれでたくさんエラーが出てます。
黙ってキャッシュ失敗するよりもエラーが出たほうがいいかなってことでエラー出力を優先する実装にしてあります。

トップみたいにキャッシュしない目的のページには抑制を仕込んでおきます。

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

開発版17 2024-04-09:
- 動画ページ以外に配置されている動画で、NicoCache側に大量のエラーが出る問題を修正．

 >>/159747/
修正しました。

解決してない。
ドメイン逃しがあった。

どうもweb worker環境にインジェクターを設置する必要がある。
ちょっと気合が必要そうだから、回避策としてそのエラー自体を出ないようにしようかな。

開発版18 2024-04-10:
- 動画ページ以外の動画で、NicoCache側に大量のエラーが出る問題を修正．

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

embed.nicovideo.jp/watch/以下にもurl_injection_sys.jsを設置。
url_injection_sys.jsとCmafCachingProcessor.javaにエラー抑制を追加。

2024-03-26(安定版1)を使っているんだけど、こいつが生成する.cmfaファイルって.cmafのtypo?
nlMediaInfo噛ませるとInvalid File Extension:braw mov qtって出るんだけど。

https://www.liveinstantly.com/ja/resources/cross-posts/cmaf-format/
> CMAFとは？
> Common Media Application Format (CMAF) は、様々な形式の HTTP ベースのメディアをパッケージ化して配信するためのフォーマット規格で、比較的新しい仕様です。 この規格は、HLS プロトコルと MPEG-DASH プロトコルの両方でデータを統一されたトランスポート コンテナー ファイルにパッケージ化することにより、再生デバイスへのメディアの配信を単純化します。

俺の勘違いかな。でも拡張子が違うって出るのはなんだろう。

 >>/159759/
 >>/159760/
typoではないです。
ニコニコ動画(というかAWS)が投げてくるファイルの拡張子がcmfv(動画)とcmfa(音声)なんです。

ffmpegも引数で抑制しないと一般的な拡張子じゃないというエラーを吐きます(.tsや.mp4は一般的な拡張子)。

nlMediaInfoの中身は確認していないけどそういうエラーだと思う。

でも
> Invalid File Extension:braw mov qt
".braw" , ".mov" , ".qt" はどれもdomand動画では使わないしNicoCacheはこれらを生成しないはず。

---

ところで開発近況です。
hlsキャッシュをユーザーが参照するためのAPI整備はちょっと難航してます。
品質別応答のための内部整理が難しいから、もう諦めて動画のsm idだけを見て、それで最良の品質を返す形式をまず実装する方針です。


開発版18も安定版にマークしたいけど、こういう場合どう運用するのがいいか決めないと。
毎回安定版のつもりでリリースすると確認作業が多くて開発版という装丁で出してるのだけど。

ニコニコのトップ画面を開くと毎回こんな感じのログが出ます。
設定が足りないのでしょうか。

・ログ
CORS configurations are loaded.
failed to set workaround for allowing patch method: Unable to make public java.lang.invoke.MemberName(java.lang.reflect.Field,boolean) accessible: module java.base does not "opens java.lang.invoke" to unnamed module @7c30a502

・環境
(ブラウザ)
125.0.2 (64 ビット)

(Java)
NicoCache_nl version 2024-04-10
    Running with Java 17.0.11(amd64) on Windows 10

(NicoCache)
NicoCache_nl 開発版18
動画ページの一番下にURLは出ていない

(proxy.pac)
サンプルを proxy.pac にリネームして使用

 >>/159764/
> CORS configurations are loaded.
エラーではないです。しかし、トップ画面を開く度に出るのはおかしいです。

> failed to set workaround for allowing patch method: Unable to make public java.lang.invoke.MemberName(java.lang.reflect.Field,boolean) accessible: module java.base does not "opens java.lang.invoke" to unnamed module @7c30a502
エラーです。その上で、トップ画面を開く度に出るのはおかしいです。

どちらもニコニコ動画のページがおかしくなるとか、動画が再生されないとかの症状がなければ無害です。

どちらのメッセージもNicoCacheを起動したあと1回だけ実行されるコードで出る・出る可能性があるのだけど、 https://www.nicovideo.jp/ を開くたびに出ますか？

すいません。トップ画面ではありませんでした。
nlの起動時のログにに出てくるものでした。
申し訳ありませんでした
1回しか出てきませんので、気にしないことにします

ありがとうございます

 >>/159766/
ただ"failed to set workaround for allowing patch method"の方はjava 17では出ないはず(のつもりで組んだ)からちょっと気になります。
"Running with Java 17.0.10(amd64) on Linux"でテストしててこちらではエラーしない。
そちらとはマイクロバージョンが1しか違わないのに。

そのエラーっていつから出始めました？
開発版14(2024-04-02)以前では出てなかったのであれば開発版16(2024-04-07)での実装変更のせいかも。

 >>/159767/
いつからかはわかりませんが、開発版途中から出てき始めたのは覚えています

起動時の「failed to set workaround ～」のメッセージですが
安定版1(NicoCache_nl version 2024-03-26)では出ないのですが
開発版16(NicoCache_nl version 2024-04-07)に変えるとでてきます。

(Java)
openjdk 17.0.8.1 2023-08-24
OpenJDK Runtime Environment Temurin-17.0.8.1+1 (build 17.0.8.1+1)
OpenJDK 64-Bit Server VM Temurin-17.0.8.1+1 (build 17.0.8.1+1, mixed mode, sharing)

 >>/159768/
 >>/159769/
旧実装だとエラーが出ないなら旧実装と新実装の両方を並べる方法取れば可用性が上がるかな。
格好悪いけど。

ところでこのエラー("failed to set workaround for allowing patch method")は、タイムシフト動画で利用される通信に対応するための回避策コードを完了出来なかったという意味です。
だけれど、いまプレミアム会員ではないので動作検証出来ていないです(回避策が完了出来た場合にPATCHメソッドが通ることは確認してるけど)。
そもそもこの回避策が今でも必要なのかどうかも不明です。

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

javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
failed to process: img.cdn.nimg.jp:443

証明書は2031年まで有効の状態です
どのように直せばよろしいでしょうか。

NicoCache_nl version 2024-04-10をつかい
Javaのバージョンは 17.0.11(amd64)です

https://www.nicovideo.jp/cache/info/v2?
に入っているJSONデータの
dmcの判定やreEncoded判定やeconomy判定ももう必要ないですね？エコノミーは撤廃されて一般会員は常に全時間帯720pになったし。

 >>/159773/
よく分からない。

・以前は上手く動作していましたか。
・アップデートのタイミングなどでそうなりましたか。
・全部の通信でそうなりますか。

全部の通信でなるなら、何かの理由でcerts/下の証明書ファイル群が壊れた可能性が高いです。
その場合は、とりあえず documents/Readme_TLS.txt の手順(genCerts)の手順をもう一度やってみてください。
あるいは https://w.atwiki.jp/nicocachenlwiki/pages/24.html の「2. genCerts.batの実行」からやってみてください。


 >>/159774/
それは「キャッシュされたファイルの名前に基づいてその情報を返すAPI」だからまだ必要です。
それらのファイルを持っているユーザーは今もいるから。

今ニコニコ動画側が返す情報にはh264という動画コーデック情報も入っていて、今はただ単に無視してるんだけど、
h265やav1がいずれ実装されるから、そうなるとまたキャッシュファイル名の仕様がまた増えることになる…
その仕様は増え続ける宿命にあります。

 >>/159773/
 >>/159774/
このメッセージ、ブロック系のアドオンのせいじゃないかな？

 >>/159775/
ありがとうございます
firefoxのキャッシュ、cookie並びにお教えいただいた手順を試してみましたが、改善が見られなかったのでこのままにしておきます。

 >>/159777/
エラー出てても使えてるならそれでも良いと思います。

 >>/159776/
可能性はある。
でも広告ブロッカーもセキュリティソフトも全部通信させるか全く通信させないかのどちらかになるはずで、通信量を変えちゃう挙動は見当が付かない。
もし中断させてるなら"Connection Reset"や"Broken Pipe"が出るはずだし。

> Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
> failed to process: img.cdn.nimg.jp:443
img.cdn.nimg.jp に対するhttps通信がおかしいというエラー。
・暗号化キーとペアになっていないキーで復号しようとした
・何かによって通信サイズが変更された
・復号メソッドがおかしい場合(つまりプログラミングエラー)
これらの場合に起きる。

https復号を処理しているNicoCacheのコードは古くて安定しているはずで、バグが入り込む可能性は低いです。

img.cdn.nimg.jp は動画再生前に表示される高画質サムネイルで使われているURLかな。
こちらでは問題なく処理が通ってます。