前書き込みいくつかはここから >>159654

>NicoCache26 >8
>>159670
>フォルダまでは作られるけど、同じく再生は出来ず。
この症状は再現出来ないのだけれども、品質モードを「自動」にしていると再生出来ないことに気付いたので、そっちを先になんとかします。
「自動」でも再生出来るはずだったけれど、動かないということはコーディングに何か考慮漏れがありそうなので。
（生放送も考慮に入れてないけど後回し）

>NicoCache26 >9
>最初のロード「no cache found: smxxxx」の後に「通信中断/.../Ranged request: video/01.cmfv...」が表示され、
>キャッシュは「nltmp_smxxxx/video/01.cmfv」だけがない状態になる。
こっちだとranged requestとnot modifiedが第1セグメントに対してよく起きる。
でも正常通信も来るから第1セグメントのキャッシュファイルが出来てる。

onTransferEndイベントの時にcompleted引数にfalseが来た時に「通信中断」と表示してました。
completedじゃなくて応答ボディの長さを数えてそれで通信中断したかどうかという判定に変えてみます。(dmc/hls処理はそう書いてあったし)

>>159671
>とりあえず、16の倍数にならないのは01.cmfvの場合がほとんどのようなので、初期の通信が混ざってないかとか検証しようと思ってました。
>しかし、通信が並行しているときの振り分け方とかがどうなっているのかが、全然わからない感じです。
NicoCacheのコードは全体的にイベントドリブンに処理が書いてあります。

Processor継承クラスのonRequestにブラウザからの要求(ブラウザはニコ動に要求しているつもり)がnicocacheに来ます。
だからCmafUseCacheProcessor.javaの動作の開始点はonRequestだけです。
一つのURLにつき一回onRequestが呼び出される感じ。

各Processorを登録しているのはServer.javaのregisterProcessorあたりで、実際にonRequestを呼び出しているのはConnectionManager.javaのentry.getProcessor().onRequest(requestHeader, browser);のあたり。

nicocacheの上流は一つの通信に一つのスレッドを割り当てています。
だから複数の処理が同時に流れてる。
こういう設計だから通信処理1と通信処理2で値を共有したい場合にちょっと回りくどいことをしないといけないです。
この値共有のために作ったのがNLShared.INSTANCE.getDomandCVIManagerという共有オブジェクトとDomandCVIEntry。

onRequestから入ってきた要求を条件分岐してそれが動画セグメントならば、addTransferListenerというコンテンツ受信時に処理を呼び出す機能にCmafUseCacheProcessor内で定義したChunkListenerのインスタンスを登録しています。
以降はその通信でコンテンツを受信したり受信完了した時に登録したcmaf/ChunkListener内のそれぞれの処理が呼び出されます。

cmfvやcmfaに対しては、ひとつの通信につき、ひとつのcmaf/ChunkListenerのインスタンスが割り当てられています。
コンストラクタでdecrypterは初期化されています。

セグメント受信時点でdecryptに必要な情報が揃っていない場合は、情報が揃ってから実行するようにmovieInfo(DomandCVIEntry)に登録しています。
上流がデータを受信し、イベントを発火させ、登録されたイベント処理へ渡します。
cmaf/ChunkListener側はonTransferringでデータの部分を受信して、decrypterに渡します。
転送終了(onTransferEnd)時にdecrypterの終了処理もします。
この時点で渡したデータの量が16の倍数じゃないとエラーします。

つまりは……むずかしいね。
（本当はデバッガーを使った方がよかったんだろうけど）自分はLogger.infoをあっちこっちに仕込んで動作させつつコードを読みました。

>>159674
解説ありがとうございます。なんとなくイメージが掴めてきました。
しかし、Logger.infoの出力を見ながらソースを読んでいると、肝心の動画をながら見してしまうという弊害が。
あと、やはり01.cmfvがこけなければほぼキャッシュができるみたいなので、そこを軸にソースを読んでいこうかなと思ってます。

まとまってないので次バージョンはまだです。

次バージョン用
- 動画品質モードの"360p-lowest"に対応. 内部的にはdmcLowとして扱う.

- 動画品質「自動」で再生出来ない問題を修正. 誤った復号鍵キャッシュを返していた.
NicoCacheを導入すると再生すら出来ないと言っていた人の環境がこれで直るといいな、と。

- 以前の動画もdms(domand)で配信されるようになったっぽい.
dms(domand)対応のついでに追加した、dmc/hlsのキャッシュを利用する機能は開発者の環境では上手く動作しています.


事例:

〜ログ前略〜
-- 応答ボディok: audio/01.cmfa(length:85424)
復号完了前に通信中断: video/01.cmfv. content-length[1023232%16=0] input-count[526684%16=12]
<206 partial content> was responded: video/01.cmfv([bytes 510300-1023231/1023232]), Content-Length:512932
〜ログ後略〜

サイズ(1023232)のうち、最初から526684まで受信した後に、510300から最後までを受信している(bytes rangeは開区間表記).
重複部分はあるがブラウザは全体を取得出来ている.
これを扱えれば通信中断と206でもキャッシュファイルを作れる.

>>159676
シークするとセグメントのダウンロードが中断される(既知)
→レジューム再生をオンにしていると1.cmfvのぶった切りが起きやすくなる
と推測してます。
レジューム再生オフでも206や304が頻発するのはなぜかは分からないけど、
上記事例に対応出来れば1.cmfv(とcmfa)のキャッシュ失敗は減るんじゃないかと考えてます

>肝心の動画をながら見してしまうという弊害が。
そこはほら興味がない短い動画を選ぶだよ
10秒前後のオンラインカジノの動作を検証していると思しき動画とか沢山ある

<NicoCache26-10
<作者さんはExtensions消したいということでしたが。
そうじゃないのです。
NicoCacheの機能を削るにあたってExtensionへの影響を知りたい、という趣旨でした。
例えばニコニコ動画のサーバーはもうswfやflvを送信してこないけれど、NicoCacheの本体にはそれらをハンドルするコードが残っています。
これらを削除すると現役のExtensionが動かなくなってしまうかも知れない。
私自身はnlMovieFetcherが動かなかったこともあってExtensionを使っていないので、状況を教えて欲しいという意味でした。

<nlMovieFetcherは普通に動いてますね。
<あとnlMediaInfoもExtension使っていますね
情報ありがと。
本体の方が落ち着いたら中身見ます。

開発途中版5を出しました。

<- 動画品質「自動」で再生出来ない問題を修正. 誤った復号鍵キャッシュを返していた.
<
<- 動画セグメントが分割されて送信されてくる通信に部分的に対応した. これで「通信中断」で1.cmfvが作られない問題が解決するはず.
これのためにコードを随分変えたのでコーディングミスがあるかも知れません。
一通り動作チェックはしたけどね。

<- 動画品質モードの"360p-lowest"に対応. 内部的にはdmcLowとして扱う.
dcmLowは、economyモードを示すlowとは違い、動画モードの差を表すものです。
dmcLowがtrueである360pは、dcmLowがfalseである360pよりも低画質である。という判定に使われています。

<- キャッシュどころか再生出来ない問題のために復号情報関係(key,iv)のログを出力するようにした. 表示過剰なので開発版の間だけ.
<
<- NicoCacheを使っていると再生開始が遅い重い. 要検証.
復号のハンドリングに何か誤りがある気がするが、あまり複雑なことをしていなくて見当なし。

<- 第一セグメントで問題が起きやすいようなので、第一に対してだけステータスメッセージを増やしました.
<
<- 復号情報取得時の復号処理を別スレッドで実行するように変更.
本当に別スレッドで動いているかどうかは要検証.

<- 昔の動画もdms(domand)で配信されるようになったっぽい.
< dmc/hlsのキャッシュを利用した再生は開発者の環境では上手く動作しています.

<- dmc/hls、一つ前の動画仕様を扱うHlsCachingProcessor.javaから発せられる
< メッセージに"(hls)"を付けました。
<
<- 紛らわしかったのでExtensionに関する質問を訂正しました。Extension機能を削除する予定はありません。

>>159680
誤: dcmLow
正: dmcLow

やっぱりレスが消せない。

開発途中版5で完了したけどエラー出てたので貼り付け。
短めだとでないので長めのを選んで（配信アニメだとでた）。

error: chunkavDir==null
+
java.lang.NullPointerException: Cannot invoke "java.io.File.exists()" because "this.chunkavDir" is null
at dareka.processor.impl.CmafCachingProcessor$ChunkListener.<init>(CmafCachingProcessor.java:1034)
at dareka.processor.impl.CmafCachingProcessor.processChunk(CmafCachingProcessor.java:941)
at dareka.processor.impl.CmafCachingProcessor.onRequest(CmafCachingProcessor.java:219)
at dareka.ConnectionManager.processAPairOfMessages(ConnectionManager.java:328)
at dareka.ConnectionManager.run(ConnectionManager.java:66)
at dareka.Server.handleTlsLoopback(Server.java:343)
at dareka.Main.handleTlsLoopback(Main.java:310)
at dareka.processor.MitmResource.transferTo(MitmResource.java:26)
at dareka.ConnectionManager.useResource(ConnectionManager.java:531)
at dareka.ConnectionManager.processAPairOfMessages(ConnectionManager.java:349)
at dareka.ConnectionManager.run(ConnectionManager.java:66)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:857)

+
failed to process: https://asset.domand.nicovideo.jp/65efceef6864fc306f4826f7/audio/1/audio-aac-192kbps/001.cmfa?session=（削除）&Policy=（削除）&Signature=（削除）&Key-Pair-Id=（削除）&nicocachenl_domandcvikey=（削除）
java.lang.NullPointerException: Cannot invoke "java.io.File.exists()" because "this.chunkavDir" is null
at dareka.processor.impl.CmafCachingProcessor$ChunkListener.<init>(CmafCachingProcessor.java:1034)
at dareka.processor.impl.CmafCachingProcessor.processChunk(CmafCachingProcessor.java:941)
at dareka.processor.impl.CmafCachingProcessor.onRequest(CmafCachingProcessor.java:219)
at dareka.ConnectionManager.processAPairOfMessages(ConnectionManager.java:328)
at dareka.ConnectionManager.run(ConnectionManager.java:66)
at dareka.Server.handleTlsLoopback(Server.java:343)
at dareka.Main.handleTlsLoopback(Main.java:310)
at dareka.processor.MitmResource.transferTo(MitmResource.java:26)
at dareka.ConnectionManager.useResource(ConnectionManager.java:531)
at dareka.ConnectionManager.processAPairOfMessages(ConnectionManager.java:349)
at dareka.ConnectionManager.run(ConnectionManager.java:66)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:857)

いまのところaudio側にだけでる。三桁くりかえしたあとcompletedもでないんだけど、自動リピートで最初に戻ったらusing cacheになって、キャッシュが完了してた。

参考までに。

ゴメン、むやみやたらに開いていったらVideoもAudioもでました。
10個ぐらいの平均はA/Vそれぞれ3回で抜ける感じです。
どれもcompletedは出力されないけど完了はしてます。

あと勿論（削除）はこっちで消した部分です。

nullチェックすり抜けを修正しました。
コーディングミスでした。

>>159683
>>159684
自分が書いたのじゃないメソッドの正常返り値にnullが候補があるのだけど、どういう場合にnullが降ってくるのかよく分かっていないです。
これを理由にエラーすると、セグメントをキャッシュする機会を失うことになるから直さねば。

それとそういえば、threadId動画(/watch/以降が数字である動画URL)に対応していないのを思い出しました。
公式配信ってこの形式のURLであることが多いですがキャッシュが動いたということですかね？

さらにそれと、こっちの環境だとwatch/soXXXのURLもNicoCacheが全く反応しなかったです。まだちゃんと調べてない。

<NicoCache26-22
<ニコ生がTS含めてぐるぐるで見れない。
<追記。
<proxy.pac から*.dmc.nicoを無くしたらニコ生は再生されるようになった。
+231111modでも同じ症状は出ますか。
それらURLをNicoCacheのdms(domand)機能はハンドリングしてないからニコ動側で何か仕様変更が入ったかな。
そうなるとdmc/hls仕様領域のコードを追わないと分からない。
ニコ生はdmc.nicoから配信されているものばかりみたい。

こちらではニコニコ生放送の再生は問題ないです。

生放送じゃない動画も仕様変更されたdmc/hlsで受け取っている人がいて、それが原因で再生出来ない、可能性。

>>159685

watch/so435178xxを開いてみましたが、Caching走りますね。
xxは伏せ字。
----
caching so435178xx
+
-- audio iv: ok
-- video iv: ok
-- video key: ok
-- audio key: ok
-- first segment ok: audio/001.cmfa
-- first segment ok: video/001.cmfv
<304 not modified> was responded: video/001.cmfv
----
Browser側のDevToolでみてもちゃんとすぐ
www.nicovideo.jp/local/url_injection_sys.js
が呼ばれてinjectionできてます。
通信先をみるかぎりnico系のサイトは以下の通り
delivery.domand.nicovideo.jp
asset.domand.nicovideo.jp
common-header.nimg.jp
stella.nicovideo.jp
dcdn.cdn.nimg.jp
dcdn.cdn.nicovideo.jp
img.cdn.nimg.jp
public-api.ch.nicovideo.jp
resource.video.nimg.jp
secure-dcdn.cdn.nimg.jp
nv-comment.nicovideo.jp
nvapi.nicovideo.jp
flapi.nicovideo.jp

あとCompletedでないけどリピートで戻るとUsingになる場合、
nvapi.nicovideo.jp/v1/watch/so（削除）/access-rights/hls?actionTrackId=（削除）
がリピート時にプリフライトリクエスト（201）の後のPOSTに400かえってきてますね。
その後
www.nicovideo.jp/api/watch/v3/so（削除）?_frontendId=6&_frontendVersion=0&actionTrackId=（削除）&skips=harmful&additionals=pcWatchPage%2Cexternal%2Cmarquee%2Cseries&isContinueWatching=true&i18nLanguage=ja-jp&t=（削除）
リクエストして再度
nvapi.nicovideo.jp/v1/watch/so（削除）/access-rights/hls?actionTrackId=（削除）
でCreated（201）が返ってきて後はlocalのm3u8呼んでCacheからって感じ。

>>159685
ステータス206、対応ありがとうございます。
私の環境では、ほぼ撮り損ねがなくなった感じです。

だんだんコードが読めてきて、206対応はdecryptを後回しにしないとダメそうだなぁと思っていたところでした。

ところで、「}」の後ろに「;」をつけるのは癖ですか？　実害はないと思いますが、普通付けないなと思ったので。

>>159683
うちでも、開発途中版6で出たので調べてみました。
開発途中版3あたりでキャッシュ失敗（1.cmfvだけキャッシュ失敗したやつ）した動画をそのまま再度見ようとしたときにも、起きるようです。
挙動的には、

1. 1.cmfvがうまくキャッシュできる
2. キャッシュが完成したので、ディレクトリ名からnltmp_がなくなる
3. NicoCacheがnltmp_のディレクトリにアクセスしようとして例外が発生している（？）
4. NicoCacheからの応答が止まるので、動画プレイヤーがリトライを行うと、キャッシュ再生に切り替わって続きが再生される

のようです。
ちなみに、

1. 完成したキャッシュのディレクトリ名に「nltmp_」をつける
2. キャッシュディレクトリの「video/1.cmfv」を削除する
3. 該当動画を再生する

で再現してます。

なお、キャッシュとしては完成するようで、その後のキャッシュ再生は成功しています。

>>159688
>ところで、「}」の後ろに「;」をつけるのは癖ですか？　実害はないと思いますが、普通付けないなと思ったので。
到達不能だってlinterに怒られることもあります…
閉じ波括弧の後にelseに絶対続かない、catchにも続かない、他の制御や宣言に続かない。ということが絵的に分かりやすくて好んで付けてます。

>>159687
キャッシュを使うかどうかの判定はマスタープレイリスト(16進数16桁.m3u8)を読んだ時に起きるので、
repeat時にマスタープレイリストの読み直しが発生することがあるんですかね。

コードを"nvapi", "/v1/"でgrepした限りでは該当なし。
"/api/"は該当はあるけど関係ありそうなものはなさそう。

dms(domand)用に追加したコードは、watchページのdata-api-dataのjsonの把握と*.domand.nicovideo.jp通信のハンドリングがメインなので、これだけで取れるページと取れないページがあるのかも知れませんね。

>>159689
それで言われて分かった。
onRequestに同じような(微妙に違う)通信が複数回来るんです。
それで既にコンプリート処理が走った後にChunkListenerを通るcmfv,cmfa通信があるってことですね。
コンプリート処理が走ると一時フォルダがnullになるから、ということ。

この「onRequestに同じような通信が複数回来る」問題。
私が開発し始める前からあったので、もっと低レイヤーな通信部分に原因がありそうなんですよね…
ちょっと前にtlsからhttpを取り出すところを確認したら、その時点でほぼ同じ通信が2回通っていたので見当が付かないです。
curlで要求をするとonRequestを通るのは1回だけだったで、ブラウザとNicoCacheとの間に何かあるとは予想してますが。

<0034
<2024/03/20(水) 17:50:13.09
<開発途中版5，6試した。画質固定(720や360)だとブラウザ上で再生されない。
<-- video iv: ok
<-- audio iv: ok
<を繰り返してる。
ivの取得はサブプレイリスト取得時に起きるので、ニコニコ動画のプレイヤーが失敗を検知して、プレイリストの取得からやり直しているのだと思います。
サブプレイリストにkeyのURLが書かれていて、それを元にブラウザがkey urlへ要求を出し、正常な応答をするとNicoCacheはkeyを取れます。
繰り返していてkey:okが来ないということはkeyの取得が失敗している可能性が高いです。
keyのURLを取れないのかkey要求が失敗しているのかはブラウザの開発者ツール画面を見ないと分からないです。

キーURLが来た時点でそれを表示するようなメッセージを仕込みます。

<画質自動にすると「キャッシュしません」となるけど
<-- video key: ok
<-- audio key: ok
<になって再生できる。
画質自動だと失敗して、画質指定だと成功するというのだったら、まだ想定しているんだけど逆か…

画質固定の時にkeyが取れてないうえにNicoCacheがkeyの取得を妨害してしまっている可能性がある。
(※ivもkeyも復号情報です)
見当が付かない。
keyの取得妨害は一つ直したつもりだったけど、違う原因があるのか。

今の実装は、urlを見て、これはkey urlで、これはaudio用(video用)でという判定をしているので、サブプレイリストに書いてあるkey urlが未知の形式であるのかも。
これが原因なら、サブプレイリスト(オーディオビデオm3u8)をもっと正確に解析すれば回避出来る。
けど、どうしてこっちではそれが起きないのかが分からない。
やっぱりABテストなのかな。

>- urlが 〜/watch/数字の羅列 である動画に対応.
>
>- so動画にあった特殊な応答に対応.
>
>- 扱えるurlを拡張.
反応しないso動画問題は上記2つで解決しました。

>- key urlに関するdebug出力がブラウザ側のページに出ます.
未知のkey形式が要求されているかも知れないので、それをユーザーから私に報告させるための出力です。
watchページの一番下に出るので全く再生されないっていうタイプの人は見てみてください。
https://delivery.domand.nicovideo.jp/hlsbid/1234567890abcdef12345678/keys/audio-aac-192kbps.key?長い文字列
https://delivery.domand.nicovideo.jp/hlsbid/1234567890abcdef12345678/keys/video-h264-720p.key?長い文字列
こういう形式じゃない場合はNicoCacheが非対応している可能性があります。
(そもそも非対応形式は検出するはずだが)

鍵を取得し始めたときにログに以下のような表示も出ます。
​-​- video key: start
​
-​- video key: okも出たら成功です。

>- サブプレイリストの加工速度が遅い可能性がある.
>
>- keyの取得中に黙ってエラーしている可能性がある.


<0035
<2024/03/20(水) 21:16:19.68ID:gmJyp7Lf0
<開発途中版6（231111mod）　Firefox124
<ログに
<<304 not modified> was responded: video/01.cmfv
<<304 not modified> was responded: audio/01.cmfa
<が出るけど、sm も so もイケてる感じ。
304はもう出力しなくてもいいかも。

<長い動画だと再生ボタンを押して再生開始までに数秒ラグが出る。
コードの中の正規表現か処理そのもののどっちかが原因の可能性があります。

<生放送はやっぱり proxy.pac から *.dmc.nico を抜かないと
<ぐるぐるする。
nlFiltersに何かないかな。
そのドメインはもうキャッシュ出来るようなものを配信していないのでデフォで抜いちゃってもいいと思ってます。
まだちゃんと確認してないけど。

<-- video iv: ok
<で止まる so がある。
<so43521554 は止まる
<so43525958 は止まらない
コーディングミスの雰囲気あり。
so関係は今回の開発途中版7で機能を増やしたのでそれで解決するかも知れません。
ただ単に、プレイリストの加工にものすごく時間がかかっているだけの可能性もあります。

<so43525958 も途中で止まった。
<video/115.cmfv: 未完 15771/1844496
これは通信中断メッセージで「video/115.cmfv: 再開 数字-数字」みたいなメッセージも出るなら問題ないです。
「不明なpartial contentです」エラーも出ませんでしたか。

完全にキャッシュしないとキャッシュを利用した再生は出来ませんが、キャッシュの保存は部分的にやっていけるので、
もう1度動画を開いて、同じ画質で、115だから(115-1)×6÷60→11分24秒あたりから再生すると取れるはずです。

開発途中版7にて
<-- video iv: ok
<-- audio iv: ok
をうちも繰り返す動画があります。

720p→自動でキャッシュ出来た動画もあるけど、出来ない動画もある状況。

ブラウザ上のkey形式のdebug出力はなし。(キャッシュできる動画は表示される)
-- video key: startの出力もなく、
-- video iv: ok
-- audio iv: ok
+
-- video iv: ok
と出力が続き、CPU使用率が上がり続けます。

>>159693
とりあえず、コメントのtypoなので実害はないと思いますが、CmafCachingProcessor.javaの117の
shlbid
は
shlsbid
じゃないかと思います。

>>159694
再生出来ない状態のページの一番下にurlは出ていましたか。
出ていたら適当に部分部分を伏せ字にしてここに貼ってください(?以降を全部消してもいいです)。

この問題が解決したら一般向けに出来そうなんだけどな。

良ければどの動画か教えてください。
他の人も動作不良の動画があったら教えてください。

そのまま貼るのが恥ずかしければRSA暗号化ツール作ったので、
これで動画IDを暗号化してから貼ってください。
https://output.jsbin.com/yaperevebi
復号は秘密鍵を持っている#//FjlVだけが出来ます。
暗号文が350文字ぐらいになって格好悪いですが、まあ気にしない。

>>159696
ありがとう直しました。

>- サブプレイリストの加工速度をわずかに改善.
>
>- keyに関するログをさらに.
> プレイリストにkey urlを発見した時点でその形式を検証.
> ウォッチページの一番下への出力も継続.

アップロードコメントに書いたここのURLがhttpsじゃなくてhttpになってるや

>>159697
watchページの下部にURLは出ていません。

再生できない動画をいくつか貼ります。
http://www.nicovideo.jp/watch/sm43553860 [Embed]
http://www.nicovideo.jp/watch/sm43542014 [Embed]
http://www.nicovideo.jp/watch/sm43526993 [Embed]

再生できない動画を見てたら傾向が見えました。
・720p固定で再生できるのは12分弱の動画まで
・解像度自動で再生できるのは17分弱の動画まで
・20分以上の動画で再生できるものは(いまのところ)ない

再生時間、フレーム数、ファイルサイズあたりかな、と。
的外れだったらごめんなさい。

再生できない動画ではないのですが、ログにエラー？警告？っぽいものが出力されていた動画です。

http://www.nicovideo.jp/watch/sm2919788 [Embed]
http://www.nicovideo.jp/watch/sm3123256 [Embed]

・出力されたもの
未知のセグメント拡張子です: '' in [master.m3u8, 1/ts/playlist.m3u8]

>>159699
Q1. ブラウザは何を使ってますか。

こちらの環境では動画3つとも問題なく動作しました。
Q2. 安定して問題が起きるんですよね？（起きたり起きなかったりするわけではなく）

>・720p固定で再生できるのは12分弱の動画まで
>・解像度自動で再生できるのは17分弱の動画まで
>・20分以上の動画で再生できるものは(いまのところ)ない
>
>再生時間、フレーム数、ファイルサイズあたりかな、と。
ありえる。
今ニコニコ動画が使っている動画の中身は3階層になってまして、代表のマスタープレイリスト、そこに書かれている映像用プレイリストURLと音声用プレイリストURL、それぞれの中に書かれている映像断片のリストと音声断片のリスト。
一つの断片で6秒ぐらいです

挙動がおかしい時にiv: okが繰り返されるということは、映像用プレイリストと音声用プレイリストが繰り返し再要求されているということ。
それで、再生時間が長くなるほど、当然に映像用音声用プレイリストが長くなるんです。
長い時に未知の表現や非対応の表現が現れて来る可能性があります。

どうしようかな…
怪しいのが映像用音声用プレイリストだから、その内容をファイルに保存すれば、アップしてもらってこっちで解析が出来るか。

>>159700
再現しました。
空行を無視する処理を忘れてました。

これは壊れた加工プレイリストを作ってしまい再生不能の原因になりうる。
>RFC 8216 HTTP Live Streaming
>Blank lines are ignored.

ところでそれらの動画はdmc/hlsで配信されてるね。新仕様のdms(domand)ではなく。
全部切り替わったわけじゃなかったか。

キャッシュに失敗する動画です。
ページを更新してもエラーは解消しません。
ブラウザは FireFox です。

http://www.nicovideo.jp/watch/nm12478765 [Embed]

・エラー内容
サブプレイリストを検出出来ないためキャッシュしません: nm12478765

CMAF付与情報取得失敗: キー(NG), 値:(NG), smid(nm12478765) (ページ更新で改善しない場合、おそらくインジェクションjavascriptかnlFilterの構成が失敗しています) https://delivery.domand.nicovideo.jp/hlsbid/65f3fc1f0bb63ebe02e90713/playlists/media/audio-aac-192kbps.m3u8

>>159701
Q1
GoogleChromeを使用しています。
edgeも試しましたがNGでした。

Q2
再生できる、出来ないは安定して再現します。

>>159702
"-mid"っていう非対応のsuffixが付いていたせいでした。

キャッシュファイルの仕様がまた複雑になる。

昨日あげてた途中版9 id.192

>- プレイリストの空行の扱いが間違っていたのを修正.
> これは再生不能を引き起こしていた.
再生不可の原因がこれだけなら簡単なのだけど。
このバグを仕込んでしまったのは、たぶん開発途中版8でのことだから解決しない。

再生不可が起きる人でなおかつ詳しい人は、m3u8ファイルの応答ボディを見てみてください。
(ファイル名部分がvideoで始まるものを見てください。)
NicoCacheがそこに不正な行を生成してしまっていると予想しています。

開発途中版8
key urlの検証を追加しました。
>-- video key url: 形式ok
>-- video iv: ok
>-- audio key url: 形式ok
>-- audio iv: ok
非対応のkey url形式の場合にはそれが表示されます。
文字"?"以降を削ってスレに貼ってください。

>0039
>2024/03/21(木) 23:19:26.65
>プレミアム限定動画ですが
>(hls)暗号化ストリーミング動画のためキャッシュしません: so42851420
>再生開始まで
>(cmaf)no cache found: so42851420[1080p,192]_シャングリラ・フロンティア 2「特異なる者」.hls
>-- video iv: ok
>-- audio iv: ok
>が8回ほど出てきました。それまで動画再生はできませんでした。
再生失敗を続けていると前の動画配信仕様を使うようになるんだね。
so動画でも再生不能起きてるのか。

>0038
>2024/03/22(金) 01:10:22.37
>8試しました。再生出来る様になりました。
開発途中版8で直ったとすれば、プレイリスト加工のバグが原因だった可能性が高いです。

>0044
>2024/03/22(金) 20:38:21.16
>大量キャッシュさせると、途中で止まる確率高いかな。
>5個ぐらいが限度って所で、それ以上は、再生が開始されないとか、途中で止まってたりするので、
これはNicoCacheの問題かな？
元々ニコ動にリクエストを大量に送るとForbiddenとだけ書いてある応答が返ってくる確率が上がるので。

>0047
>2024/03/23(土) 00:54:38.81
>中身が複雑になってるから、mp42hlsはちょっと難航しそうな予感。
>前の1/ts形式だと、多分読めないよなぁ・・・。
>って、それ読めないと、キャッシュ全滅っぽ？
いえ。
dms(domand)動画に対応するついでに、動画キャッシュフォルダにmaster.m3u8があれば自由な形式を配信出来るような機能を追加したので、ニコニコ動画側のプレイヤーさえ対応していれば、任意のフォルダ構造で再生出来ます。
この機能が動作したというレスは見ていないけれども私の環境では期待通りに動いています。

dms(domand)で配信されるページでも、dmc時代のhlsキャッシュが使えています。

それとffmpegを使って単一ファイル動画(mp4とかflvとかwebm)をcmafにする方法。
>ffmpeg -i 入力動画 -c:v copy -c:a copy -f hls -hls_time 6 -movflags cmaf -hls_segment_type fmp4 -hls_playlist_type vod -hls_segment_filename "%d.m4s" 'master.m3u8'
>この方法で作ったmaster.m3u8をニコニコ動画のプレイヤーは再生出来る。(webmを入力とする場合も再生出来る)
>昔のmp4キャッシュやflvキャッシュが使える可能性が出来ました。
ts形式でもいいんだけど、これはvp8とかvp9のコンテナになれないからfmp4にしてます。

この機能は当然に、mp4キャッシュを変換して利用するための下準備です。
(セグメントへの分割処理は軽いからffmpeg.wasmとか使っても実現出来そうだし、そうすれ同梱配布が出来てインストール楽かもとか。まだ予定の段階です。)

>>159694
>>159699

ここで報告してた再生できない動画ですが、開発途中版9で再生可能なことを確認しました。

>>159709
再生不可が改善したという報告これで2つ。
よさげ。

- 開発途中版7までのm3u8に関する正規表現が間違っていた可能性が高い。
- 開発途中版8で1行ずつ処理するようにして、シンプルな正規表現に改善して
- 開発途中版9で空行の扱いを修正した

改善しなければ情報インジェクション手法をやめて、NicoCacheの内部でURLとどの動画に関するものかという連想配列を持つ設計に変えようと思ってた。
そっちの方がニコ動側の挙動を変えないから望ましいんだけどね。

>>159707
動画キャッシュ完了後の提供で、場面が指定されているとerrorが出るようです。エラーログが出ているだけで、表示には影響は出てなさそうです。
とりあえず、ログはこんな感じ

cache completed: sm43555540[1080p,192]_【琴葉茜】徒歩キャンプ実況 #9【冬キャン納】.hls
error: chunkavDir==null: 070.cmfv
error: chunkavDir==null: 071.cmfv
+
error: chunkavDir==null: 072.cmfv
error: chunkavDir==null: 073.cmfv
+
error: chunkavDir==null: 074.cmfv
error: chunkavDir==null: 075.cmfv

>>159711
これは一時ファイルを置くためのディレクトリが存在しないというエラーで、
キャッシュコンプリートしているなら問題にする必要ないので、
キャッシュコンプリート時はこのメッセージを出さないようにします。

今の実装だとコンプリートしたキャッシュフォルダに一時ファイルが残る可能性があるな…

id.192

途中版9とほぼ同じ
メインの変更点はutf8化だから挙動は変わらないはず。

>- そろそろ安定版宣言が出来そう.
>
>- 他に開発が続いているNicoCacheは見つからないため、起動時に表示されるバージョン
> をシンプルにします. ChangeLogでは長いバージョンの表記を使います.
> 変更前の最終バージョン.
> "NicoCache_nl+150304mod+231111mod (eR) (based on NicoCache v0.45)"
> 変更後.
> "NicoCache_nl version 2024-03-24"
> まるで来歴を省略してしまうようですが、必要と判断しました. 先人達に感謝を.
> 安定版ごとに日付を更新していくつもり.
>
>- ソースコードやtxtファイルなど全て、Shift-JISだったのをUTF-8へ変換.
> 半角カナなどは維持.
>
>- "360p-mid"や"360p-low"に部分的に対応しました. (部分的というのは"low"と"lowest"
> の順序比較を実装していないという意味.)

書き忘れたけどchunkavDir==nullを無視して良い状況では出力しないようにしました。

>0060
>2024/03/24(日) 11:24:49.87
>10について、
>srcの更新と、autobuild。
>nicocache_nlフォルダ直下のファイル群を更新しNicoCache_nl.jarを起動させると
>それまでできていたキャッシュがログから表示されなくなり動画のフォルダも作成されなくなりました
Q1. 配布のNicoCache_nl.jarを直接使った場合はどうですか(例えば起動時バージョンはどう表示されますか)
Q2. ant cleanやsrc下のclassファイルを削除、NicoCache_nl.jarの削除をした後にant jarするとどうですか

配布したNicoCache_nl.jarを使って最低限の構成で起動してみたけど期待通りに動作しています。
配布したファイルをcleanした上でant jarしてみたけれど期待通りに動作しています。
(そもそもコンパイル済みオブジェクトにあたるclassファイルはsrc下には同梱してないのだけれど)

autobuildってAutoBuild.batですよね？
>cmd /k "color 2E && TITLE AutoBuilder && cd %~dp0 && cd /d %~dp0 && ant extract jar"
使ってないから分からないけど問題なさそうなコマンドに見える。


上に書いた[誤:id.192]じゃなくて[正:id.194]だ。
ところでアップローダーの[id.194 開発途中版10]が3/4ぐらいまでダウンロードしたあたりで失敗する。
再試行しても失敗する。
代わりのファイルを上げておきます。

関係ないけど起動時にjavaのバージョンチェックコードを追加した方がいいな。
java 19では動かない。
java 18では検証してない。
java 11では動く。

id.195 10-2もダウンロード不可

アップロード時に1回エラー後にアップ成功

https://nicocache.jpn.org/
サーバーエラー
jqXHR: {"readyState":0,"responseText":"","status":0,"statusText":"error"}
textSattus: error
errorThrown:

>>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_injection_sys.js
https://delivery.domand.nicovideo.jp/local/url_injection_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/<smid>/{movie,audio} の挙動を変更しました．
>　これまで<smid>にlowがついていない場合は，(非dmcの)通常キャッシュとエコノミー
>　キャッシュから自動で選択して結果を返していましたが，非dmcの通常キャッシュから
>　結果を返すようになりました．
>　dmcキャッシュを含めたキャッシュから自動で選択して結果を返す新しいWebAPIは
>　/cache/<smid>/auto/{movie,auto} です．

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

<>ディレクトリ型動画の存在を想定した仕様ではないため、仕様を一意に決めることが出来ないです。
<すみません、ここどういう意味なのか分かりかねます。
旧仕様は動画が一つのバイナリーコンテンツで表せることを前提としている(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/<smid>.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/<smid>/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/<smid>/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オブジェクトにインジェクション用ラップを追加
の部分がエラーになって止まっているように見えます。

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 "<local2>" 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かな。
こちらでは問題なく処理が通ってます。

ちょっとした不具合報告…
https://nico.ms/sm33304447
この動画では正常にキャッシュされるけど再度動画視聴ページを開き直したりリロードするとキャッシュされたファイルが無視されて再キャッシュされるんだけどなぜ？しかもこの動画だけで起きる（私が確認した範囲では）。

NicoCache_nl version 2024-03-26
Running with Java 17.0.11(amd64) on Windows 11

該当するログ
>(cmaf)no cache found: sm33304447[360p-lowest,128]_マスクと化した大物Youtuber.hls
>caching sm33304447
>+
>-- first segment ok: audio/01.cmfa
>caching sm33304447
>-- first segment ok: video/01.cmfv
>caching sm33304447
>+++++++++++++++++++++++++++++++
>cache completed: sm33304447[360p-lowest,128]_マスクと化した大物Youtuber.hls
(ページをリロードする)
>(cmaf)no cache found: sm33304447[360p-lowest,128]_マスクと化した大物Youtuber.hls
>caching sm33304447
>+
>-- first segment ok: audio/01.cmfa
>caching sm33304447
>-- first segment ok: video/01.cmfv
>caching sm33304447
>+++++++++++++++++++++++++++++++
>cache completed: sm33304447[360p-lowest,128]_マスクと化した大物Youtuber.hls

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

開発版19 2024-05-11:
- "-"を含む動画モード(例えば"360p-lowest")のキャッシュが利用出来ない問題を修正. キャッシュファイル正規表現の動画モード部を\w([a-zA-Z_0-9])でキャプチャしていたため失敗していた.

>src/dareka/processor/impl/CacheManager.java
>- Pattern.compile("^(([a-z]{2}\\d{1,9})(|low|kulow)\\[(\\w+)(?:,(\\d+))?,(\\d+)\\](\\w*?))(?:_(.*))?(\\.(?:flv|mp4|hls))$");
>+ Pattern.compile("^(([a-z]{2}\\d{1,9})(|low|kulow)\\[([\\w-]+)(?:,(\\d+))?,(\\d+)\\](\\w*?))(?:_(.*))?(\\.(?:flv|mp4|hls))$");
(たぶんendchanのmarkdownで変になっちゃう)

>>159782
修正しました。
上記の理由でした。

開発版18と開発版19が同じ日付になってるみたい。

開発版19:
>NicoCache_nl version 2024-04-10
> Running with Java 17.0.11(amd64) on Windows 11

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

2024-05-11
開発版19と同じで、バージョン情報だけが違います。

>>159784
修正しました。ありがとう。

バージョン書き直すの忘れがちだから、ChangeLogとMain.javaを比較するスクリプト書こう…

動画の保存と音声保存は効くようになったけど、コメント保存だけは「安全な接続ができませんでした」と表示されてそれ以上何もできないね。

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

開発版20 2024-05-31:
- WebAPIにhls取得用のURL仕様を追加．
- /cache/file/nicocachenl_refcache=<smid>[<quality>]//<path>
​ <path>は<smid>のhlsキャッシュディレクトリから相対参照するファイルパスです.
- /cache/<smid>[<quality>].hls
​ アクセスすると /cache/file/nicocachenl_refcache=<smid>[<quality>]// へリダイレクトされます．
- 上記2つのURL仕様はどちらも"[<quality>]"部分は省略可．なおかつ現時点の実装では，この部分は純粋に無視され，常に<smid>の最も高品質なhlsキャッシュを応答します．
- 例えば，hls urlを扱える動画プレイヤーにこれらurlを与えることで，動画を再生することが出来ます．
​ 例1: ffplay -http_proxy http://localhost:8080/ -i 'http://www.nicovideo.jp/cache/file/nicocachenl_refcache=sm9[360p,128]//master.m3u8‘
​ 例2: ffplay -http_proxy http://localhost:8080/ -i 'http://www.nicovideo.jp/cache/file/nicocachenl_refcache=sm9//‘
​ 例3: ffplay -http_proxy http://localhost:8080/ -i 'http://www.nicovideo.jp/cache/sm9.hls‘
​ (8080はNicocacheのポート番号に書き換えること)
- hlsキャッシュがあるsmidに対して /cache/<smid>/auto/movie にアクセスした場合の挙動は変更なく，mp4への変換にリダイレクトします．上記URLにリダイレクトするように変更するかどうかは未定．


未定と書いた /cache/<smid>/auto/movie の挙動ですが、変換して単一ファイルのmp4を返す挙動と、hls用URLにリダイレクトしてmaster.m3u8を返すどっちがいいですかね？
test_nlFilters のリンクからすると利用者は単一ファイルを求めてる例の方が多いと思います。
autoが変換挙動へリダイレクトすることを整合性があると見做すかどうかという問題。

>>159793
コメント保存はまだまったく着手してないです。
あれは /cache/ 下の機能だっけ？
コメント取得用通信の仕方は昔と変わってるはず。
ところで、昔は削除された動画のコメントもダウンロード出来たけど今は無理そうですね。

>>91
私はtest_nlFiltersの作者ですが、/cache/<smid>/auto/movieの挙動について、ニコニコ動画のプレイヤーが再生できるのであればどちらでも構いません。

>ところで、昔は削除された動画のコメントもダウンロード出来たけど今は無理そうですね。
https://yyya-nico.co/nv_comment_viewer/sm556
今はただFORBIDDEN reason:DELETED VIDEOが返ってくるだけですね。

レス番号間違えちゃった…
5chと違うんですね
正しくはこうですかね>>159795

>>159797 >>159798
ここはレスが消えると跡形もなくなるから、その方法の通り通し番号引用がいいです。

- /cache/<smid>/auto/movie が変換を通るとffmpegが必須になってしまう
- 変換を通るとするとURLアクセスがあるたびに変換が走ってしまう

hlsキャッシュ限定とは言えこの2つが整合性と言うには重いので、autoはhls取得用URLへリダイレクトする仕様にします。
調整してリリースします。

>https://yyya-nico.co/nv_comment_viewer/sm556
>今はただFORBIDDEN reason:DELETED VIDEOが返ってくるだけですね。
やっぱりコメントスレッドIDを推定する方法がなくなるから難しいんでしょうね。
特に欲しい物があるわけではないけどもったいない。

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

開発版21 2024-06-01:
- WebAPIの仕様変更.
- hls to mp4変換URL /cache/<smid>[<quality>].hls.mp4 の[<quality>]は省略可になりました.
例: http://www.nicovideo.jp/cache/sm9.hls.mp4
- hlsキャッシュに対する /cache/<smid>/auto/movie は以前(2024-03-29〜2024-05-31)は，hls to mp4変換URLにリダイレクトしていましたが，これからは hls のマスタープレイリストを返す内部APIにリダイレクトされます．
例4: ffplay -http_proxy http://localhost:8080/ -i 'http://www.nicovideo.jp/cache/sm9/auto/movie‘
- 単一ファイルが欲しい場合はhls to mp4変換URLを使って下さい(ffmpegが必要です)．

>0328 2024/06/01(土) 04:43:38.88ID:Et4MtKRF0
>/cache/<smid>/auto/movieにアクセスした時、nicocache_nlのGUI上Mainには
>hls to single: cannot convert hls to mp4.
>hls to single: Unrecognized option 'allowed_extensions'.
>hls to single: Error splitting the argument list: Option not found
>と表示されてて、ページ更新のたびに繰り返される
"Error splitting the argument list: Option not found"はffmpegのエラーメッセージだからffmpeg自体は起動しているようです。
allowed_extensionsに対応していないということはffmpegが古い可能性が高いです。
あるいはffmpegビルド時のスイッチが足りていない可能性があります。
ffmpegのバージョン情報( ffmpeg -version )はどうなっていますか。

>0329 2024/06/01(土) 12:29:07.69ID:uBFPNxNE0
>プレミアム会員
>NicoCache_nl version 2024-05-31
>ニコ生のタイムシフト予約について
>番組ページに入り、TS予約ボタンを押すと予約成功
>番組一覧の縦三点リーダーから予約しようとすると
>　システムエラーが発生しました
>　　再度お試しください
>の小窓が出る。
url_injection_sys.js が原因みたいです。
調べます。

ところでプレミアム会員ということですが、こちらでは1080p画質を選んだ場合、約2割の動画がキャッシュコンプリート不発(100%にならない)状態なんですが、そちらでは問題無いですか？
今日からプレミアムに復帰したので以前の状態は分からないです。

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

開発版22 2024-06-01 sub2:
- 縦三点メニューからのタイムシフト予約の挙動を修正
- url_injection_sys.js を/watch/ページでのみ作動させるように変更.
- インジェクションは問題が起きやすい. 廃止を長期的目標とする.

1080pのキャッシュコンプリート不発が再現しなくなった。
わからない。

>>159802
某掲示板328です
ffmpegのバージョンは
ffmpeg version N-115469-g4008a80c1b-20240531 Copyright (c) 2000-2024 the FFmpeg developers
となっています

>>159804
ffmpegは新しい。
引数の分離に失敗してるかな。

全部の動画でそうなりますか。
OSはWindowsですか。
利用しているjavaのバージョンはいくつですか。
コマンドプロンプトかシェルで

ffmpeg -hide_banner "-allowed_extensions" "m3u8,cmfv,cmfa,key,mp4,m4s,m4a,ts,webm,flv" "-protocol_whitelist" "crypto,tcp,tls,https,file"

を実行してみてください。

<Trailing option(s) found in the command: may be ignored.
<Hyper fast Audio and Video encoder
<usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...
<
<Use -h to get full help or, even better, run 'man ffmpeg'

と実行結果が出るなら期待通りですが、なぜ動かないのかは分からないままです。
Unrecognized option 'allowed_extensions' が現れるようなら使っているffmpeg自体がおかしいです。

実装的な話。
ffmpegに間違った引数を渡すことによってallowed_extensionsを解釈するffmpegが、Unrecognized option 'allowed_extensions'を出力する場合があるみたい。
javaのProcessBuilderは文字列配列を受け取るからバグが入り込む余地はなさそうなんだけれど。
過去のjavaバージョンだとエスケープ処理してから渡せ、ダブルクオーテーションして渡すと失敗する、などなど情報が錯綜していてよく分からない。
こちらの環境だとダブルクオート、シングルクオート、バックスラッシュ、半角スペースを含むフォルダ名からmp4に変換することも成功しています。

>>159805
幾つかの動画で試してみましたが全て同じ結果になります
OSはwindowsです

java -versionで、下記のように表示されました

openjdk version "17.0.11" 2024-04-16
OpenJDK Runtime Environment Temurin-17.0.11+9 (build 17.0.11+9)
OpenJDK 64-Bit Server VM Temurin-17.0.11+9 (build 17.0.11+9, mixed mode, sharing)

ffmpegのコマンドでは、下記のように表示されました

Trailing option(s) found in the command: may be ignored.
Universal media converter
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'

>ちなみにffmpegはCドライブ、nicocache_nlはDドライブにあり、cacheフォルダはconfig.propertiesに記入することによりEドライブの任意のフォルダに指定しています
問題なさそう。

> >325のuserpageを利用しての音声保存は上手くいくようで、m4aファイルが落ちてくる
ffmpegが入っているなら、この機能もffmpegを使っているはず。

>>159806
ffmpegは問題なさそう。
javaも特殊じゃない。

設定の問題ではなさそうです。
何かの理由で引数解釈が失敗している。
だから多分、ソースコード側をなんとかしないと無理そうです。
見当がつかないので調べてから。


src/dareka/processor/util/Hls2SingleConverter.java
> private static BufferedReader execCommand
> (String[] args, boolean showError) {
>...
> try {
> ProcessBuilder pb = new ProcessBuilder(args);



ところで、ちょっと難しいんですがNicocacheがやっているhlsからmp4に変換する処理は以下と大体一緒です。

ffmpeg "-hide_banner" "-loglevel" "error" "-allowed_extensions" "m3u8,cmfv,cmfa,key,mp4,m4s,m4a,ts,webm,flv" "-protocol_whitelist" "crypto,tcp,tls,https,file" "-i" "入力動画のmaster.m3u8パス" "-c:v" "copy" "-c:a" "copy" "-id3v2_version" "3" "-metadata" "title=動画タイトル" "-metadata" "comment=動画ID" "-y" "出力先のパス.mp4"

>>159807
> <Hyper fast Audio and Video encoder
の1行が無いのは気にしなくていいですか？

>159806捕捉します、OSはwindows10 proです

そして同レス内での"幾つかの動画"のcacheを使って>159807の最後のコマンドを試したところ「(ファイル名なし).mp4」ファイルが出力され、視聴も問題なくできました
ありがとうございます

あら？某掲示板のノリでアンカ打つと引用文扱いになっちゃうのか
紛らわしくですみません

>0337 329 2024/06/01(土)
>タイムシフト直りました。
>が、いざ見ようとして ▶視聴する を押すと前と同じ
>　システムエラーが発生しました
>　　再度お試しください
>の小窓が出て視聴できないっす。
この「▶視聴する」ボタンはどこにあるものですか。

>>159808
>> <Hyper fast Audio and Video encoder
>の1行が無いのは気にしなくていいですか？
それと"Universal media converter"のどちらもffmpegのキャッチフレーズだから無視していいです。
それに
>そして同レス内での"幾つかの動画"のcacheを使って>159807の最後のコマンドを試したところ「(ファイル名なし).mp4」ファイルが出力され、視聴も問題なくできました
ありがとうございます
これに成功しているということはffmpegの処理機能に問題はないです。

こちらでもWin7環境だけど、nicocache本体とは違うドライブのスペース2つを含むフォルダをキャッシュフォルダに(cacheFolder=A:\cache chache\)してみたのだけれど、問題起きなかったです。

Windowsは実行ファイルの起動時に内部的には一つの文字列引数しか与えることが出来なくて、プログラム側の責任で文字列を解釈分解して文字列リストにします。
これはつまり、ffmpegに埋め込まれている引数解釈ルールと、javaのProcessBuilderが作る引数フォーマットルールが不一致した場合に、ffmpegには意図した引数リストが伝わらないということ。
今のところはこれを疑っているのだけれどもよく分からない。
AudioExtractor(音声抽出)との違いでありそうなのはffmpegにカンマ","を渡そうとしていること。

次のリリースでどういう起動引数リストを渡そうとしているのか表示する機能入れるので、その時にその文字列を教えてください。

あ。ありがとうございますを削るのを忘れてるや。

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

開発版23 2024-06-02:
- hls to mp4変換失敗時にffmpeg起動引数を表示する機能を追加．引数解釈過程を取得する目的でffmpegのloglevelをdebugに．

>>159808
開発版23で変換失敗すると添付ファイルみたいなログが出力されるのでそれを教えてください。
動画に迷うならsm9で。
それと、開発版21で /cache/<smid>/auto/movie の挙動が変わっているので、
https://www.nicovideo.jp/cache/sm9.hls.mp4
で。

ログにはパスも出力されるので、都合の悪いところは上手いこと伏せてください。
そこに原因が含まれている可能性は当然あります。理由が含まれる可能性が高いのは"Unrecognized option"が表示される前あたりです。

>>159813
どこを出すと都合が悪いのかすら分からず例のtxtと見比べて添削しました
変なの書いてあったら目を瞑ってください

hls to single: sm9[360p,128].hls 新・豪血寺一族 -煩悩解放 - レッツゴー！陰陽師.mp4
hls to single: cannot convert hls to mp4.
hls to single: args: "ffmpeg" "-loglevel" "debug" "-hide_banner" "-allowed_extensions" "m3u8,cmfv,cmfa,key,mp4,m4s,m4a,ts,webm,flv" "-protocol_whitelist" "crypto,tcp,tls,https,file" "-i" "..\cache\sm9[360p,128]_新・豪血寺一族 -煩悩解放 - レッツゴー！陰陽師.hls/master.m3u8" "-c:v" "copy" "-c:a" "copy" "-id3v2_version" "3" "-metadata" "title=新・豪血寺一族 -煩悩解放 - レッツゴー！陰陽師" "-metadata" "comment=sm9[360p,128].hls" "-y" "\Temp\nlHls2Mp4_14448354912795671705.mp4"
hls to single: Splitting the commandline.
hls to single: Reading option '-loglevel' ... matched as option 'loglevel' (set logging level) with argument 'debug'.
hls to single: Reading option '-hide_banner' ... matched as option 'hide_banner' (do not show program banner) with argument '1'.
hls to single: Reading option '-allowed_extensions' ...Unrecognized option 'allowed_extensions'.
hls to single: Error splitting the argument list: Option not found

>>この「▶視聴する」ボタンはどこにあるものですか。
>ニコ生視聴ページ https://live.nicovideo.jp/watch/lv??????
>の、ど真ん中にある青バックのやつです。
こっちの環境だとNicocacheを通している場合もそうでない場合でも
- ライブ中のページを開く → 自動的に再生開始
- 生放送が終わったタイムシフト動画を開く → 自動的に再生開始
- 「放送開始までしばらくお待ちください」状態から放送時間を迎える → 自動的に再生開始
全部同じで「視聴する」ボタンが出なくて見つけられないです。
なんか出すための条件があるかな。

開発版22 2024-06-01 sub2の時点でurl_injection_sys.jsは https://live.nicovideo.jp/watch/lv??? のURLでは動かないようになっているので、別の原因の可能性が高いです。
生放送に関係ありそうなNicocacheの仕様で言えば、NicoCacheの起動時に"failed to set workaround for allowing patch method"と出ますか？
※patchメソッド通信が本当に今でも使われてるかどうかはまだ確認していないですが

>>159814
削るか削らないかは恥ずかしいか恥ずかしくないかです。
パス名の中に実名が入っているとかネット上で活動しているニックネームが含まれているとか、こういうことがなければPC内部のフォルダ構造がわかっても実害はないです。
>hls to single: Reading option '-allowed_extensions' ...Unrecognized option 'allowed_extensions'.
おかしいはおかしいんだけど、手動でもってffmpegで変換した時はallowed_extensionsは期待通りに解釈されているからたぶんここじゃない。
ネット上でも入力パスや出力パスがおかしいとその前にある引数スイッチにエラーするらしいし。
というわけで
>"..\cache\sm9[360p,128]_新・豪血寺一族 -煩悩解放 - レッツゴー！陰陽師.hls/master.m3u8"
よければ..のところ教えて貰えますか、あるいは実際に..\cache\にcacheFolderを設定していますか。

あれ…argsの行だとバックスラッシュ(円マーク)はエスケープされた結果2つ並ぶはずなのにそちらの出力だとそうなっていない。

>>159816
そうなんですね、じゃあ問題ないです
では…
"E:\新しいフォルダ\動画\cache\sm9[360p,128]_新・豪血寺一族 -煩悩解放 - レッツゴー！陰陽師.hls/master.m3u8"

>>159817
扱いが難しい文字が含まれていると思ってたけれど入っていなかったです。
こちらでも cacheFolder=E:\\新しいフォルダ\\動画\\cache の設定で動かしてみたけけど、動きました。
だから未だに原因不明。

後で回避策になるかもしれないbatファイルを作るので試してみてください。

あるいは試しにもう一度ffmpegを削除して入れ直してもらうか。
https://www.gyan.dev/ffmpeg/builds/ffmpeg-git-essentials.7z

>>159818
提示いただいたffmpegを入れなおしてやってみましたがダメでした
まずffmpeg -version　から

ffmpeg version 2024-06-03-git-77ad449911-essentials_build-www.gyan.dev Copyright (c) 2000-2024 the FFmpeg developers
built with gcc 13.2.0 (Rev5, Built by MSYS2 project)

次にNicoCache_nlのログです

hls to single: sm9[360p,128].hls 新・豪血寺一族 -煩悩解放 - レッツゴー！陰陽師.mp4
hls to single: cannot convert hls to mp4.
hls to single: args: "ffmpeg" "-loglevel" "debug" "-hide_banner" "-allowed_extensions" "m3u8,cmfv,cmfa,key,mp4,m4s,m4a,ts,webm,flv" "-protocol_whitelist" "crypto,tcp,tls,https,file" "-i" "E:\新しいフォルダ\動画\cache\sm9[360p,128]_新・豪血寺一族 -煩悩解放 - レッツゴー！陰陽師.hls/master.m3u8" "-c:v" "copy" "-c:a" "copy" "-id3v2_version" "3" "-metadata" "title=新・豪血寺一族 -煩悩解放 - レッツゴー！陰陽師" "-metadata" "comment=sm9[360p,128].hls" "-y" "C:\Users\Owner\AppData\Local\Temp\nlHls2Mp4_5513156554792715724.mp4"
hls to single: Splitting the commandline.
hls to single: Reading option '-loglevel' ... matched as option 'loglevel' (set logging level) with argument 'debug'.
hls to single: Reading option '-hide_banner' ... matched as option 'hide_banner' (do not show program banner) with argument '1'.
hls to single: Reading option '-allowed_extensions' ...Unrecognized option 'allowed_extensions'.
hls to single: Error splitting the argument list: Option not found

>>159822
結果に先立って深くお詫び申し上げます
今回の1件、nicocacheフォルダの中に裸で入っていた古いffmpeg.exeが原因だったようです
色々ご再考頂いた上、手間と時間を取らせてしまい申し訳ありません

ここに至った経緯ですが、まず添付されていたbatを置く場所によって結果が違いました
nicocache_nlのフォルダの中に放り込んで実行すると

D:\NicoCache_nl>ffmpeg -loglevel debug -hide_banner -allowed_extensions m3u8,cmfv,cmfa,key,mp4,m4s,m4a,ts,webm,flv -protocol_whitelist crypto,tcp,tls,https,file -i "E:\新しいフォルダ\動画\cache\sm9[360p,128]_新・豪血寺一族 -煩悩解放 - レッ ツゴー！陰陽師.hls/master.m3u8" -c:v copy -c:a copy -id3v2_version 3 -metadata "title=新・豪血寺一族 -煩悩解放 - レッツ ゴー！陰陽師" -metadata "comment=sm9[360p,128].hls" -y "C:\Users\Owner\AppData\Local\Temp\nlHls2Mp4_5513156554792715724.mp4"
Splitting the commandline.
Reading option '-loglevel' ... matched as option 'loglevel' (set logging level) with argument 'debug'.
Reading option '-hide_banner' ... matched as option 'hide_banner' (do not show program banner) with argument '1'.
Reading option '-allowed_extensions' ...Unrecognized option 'allowed_extensions'.
Error splitting the argument list: Option not found

と表記されます

次にダウンロードフォルダ(E:\...\Downloads)で実行するとかなりの量の文字数が出て、添付されたlog.txtのような文が表示されました
"Finished splitting the commandline."の文字列も表示されています
しかしlog.txtの40行目のようにError表記はなく、それ以降もずらずらっとそれは長いこと処理内容のようなものが表示されています

続いてC直下、D直下、E直下それぞれで試しましたが、いずれも成功？し、上記のように短い文で止まってしまったのは
nicocache_nlフォルダ内で実行した場合のみとなりました

と、ここで試しにnicocache_nlフォルダ内にあったffmpeg.exeを消して再度nicocahe_nl内で実行した所、ダウンロードフォルダで実行したものと同じであろう文字列が表示されました

ここにffmpeg.exeが裸で置いてあったのは、古い記憶のままnicocache_nlのインストールの過程でフォルダ内にffmpeg.exeを入れる、を当然の事として行っていたのが原因です(この時持ってきたのは今回nicocacheを入れなおす前のnicocaheで使っていたもの)
今wiki(新)を見直したらそのような表記はありませんでした
更にjava -version等諸々のチェックも上手くいっていた為、手を付けなくてよいと考えていました

その上で>159805あたりからをもう一度やり直しました

>ffmpeg -hide_banner "-allowed_extensions" "m3u8,cmfv,cmfa,key,mp4,m4s,m4a,ts,webm,flv" "-protocol_whitelist" "crypto,tcp,tls,https,file"
の実行は…

Trailing option(s) found in the command: may be ignored.
Universal media converter
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'

となりました

続いて>159813のhttps://www.nicovideo.jp/cache/sm9.hls.mp4へのアクセスは
sm9の動画が再生されました
その際にnicocacheに表示されていたログは

hls to single: sm9[360p,128].hls 新・豪血寺一族 -煩悩解放 - レッツゴー！陰陽師.mp4

でした

事の始まりhttps://www.nicovideo.jp/cache/sm9/auto/movieへのアクセスは
cacheがcomplete状態のときは拡張子も何もついてない英数字が羅列されたファイルの保存場所を聞かれます
cacheが無いときor中途半端な時は404 Not Foundと表示されます
これについてnicocache_nlのログには何も表記されません
開発21で挙動がかわった、との事なので関係ないかもしれませんが…

私もアニメの生放送での見逃しにて視聴開始ボタン（青色）を押すとエラーが発生しています。
今までエラーのためにプロキシ設定を無効にしてから生放送の見逃しを視聴していました。
今現在もそれは変わらないのですが、しかし困ったことが起こりました。
一回視聴して閉じ、再び視聴可能期間内にそれを開くとプロキシ設定を元の有効にした後でも視聴が可能でした。
見逃しでのボタンに何かあるのでしょうか。

>>159821
ok解決。
NicoCache起動時にffmpegのバージョンを表示する機能とかあると確認が簡単かもね。

>>159824
> https://www.nicovideo.jp/cache/sm9/auto/movie
>cacheがcomplete状態のときは拡張子も何もついてない英数字が羅列されたファイルの保存場所を聞かれます
仕様です。
https://www.nicovideo.jp/cache/file/nicocachenl_refcache=sm9//
というURLに転送されるためにブラウザによってはファイル名を決定出来ずに、ランダム生成の文字列がファイル名に選ばれます。
中身は動画キャッシュhlsのマスタープレイリストです。

この仕様を元にフィルタまとめ(test_nlFilters)の人に再生機能を作ってもらおうと思ってます。
ただこの仕様にしたために、nlFiltersのUserPageの「動画を新規ウィンドウに開いてローカル保存」がhlsマスタープレイリストに転送される挙動になっているから、単一ファイルのmp4動画が欲しいユーザーには今の仕様は不便です。
この不便さの解決策は、test_nlFiltersの人にキャッシュがhlsであった場合に、hls to mp4のURLに転送するように仕様を変更してもらおうかなと、こちらでは思ってます。

>>159825
再現性があるかー。
もうちょっと調べます。

PATCHメソッド(http)が使われているからたぶんそれが原因です。
とりあえずの回避策としては、
pacファイルに追記してliveをNicoCache対象外にしてしまうこと。
if ("live.nicovideo.jp" === host) { return "DIRECT";}
if ("live2.nicovideo.jp" === host) { return "DIRECT";}
こちらでは症状再現が出来てないので、本当に上手く動くかはわかりませんが。
それにたぶんlive2.nicovideo.jpだけDIRECTにしておけば回避策として機能します。
添付ファイルに例をのせておきます。

>>159826
ありがとうございます
よろしくお願いいたします

>>159829
回避策としては問題ないけどproxy.pacサンプルが古いままだった。
live2サブドメインだけをDIRECTにするサンプル。

>>159830

タイムシフトがエラーを出さずに視聴することができました
ありがとうございました

最新の開発版23の
https://www.nicovideo.jp/cache/<smid>/auto/movieで動画が再生できなくなった…（ガクゼン）。
これはまだ色々と弄っている途中なのかな…。

HLSのマスタープレイリストだけ配信してビデオプレイリストやオーディオプレイリストに記載されてる.cmafや.cmfvへのパスを案内しなくなったせいだと多分思うんだけど…。

多分localなら普通に再生されるよね。

>>159864
もしmp4として再生したい場合は
http://www.nicovideo.jp/cache/sm9.hls.mp4
こういうURLを使ってください。

>HLSのマスタープレイリストだけ配信してビデオプレイリストやオーディオプレイリストに記載されてる.cmafや.cmfvへのパスを案内しなくなったせいだと多分思うんだけど…。
されない？
リダイレクト過程はこういう順番です。
https://www.nicovideo.jp/cache/sm9/auto/movie
https://www.nicovideo.jp/cache/sm9.hls
https://www.nicovideo.jp/cache/file/nicocachenl_refcache=sm9.hls//
最後のURLはmaster.m3u8が書かれていた場合と一緒のコンテンツを返す。
https://www.nicovideo.jp/cache/file/nicocachenl_refcache=sm9.hls//master.m3u8

動画再生しようとすると、プレイリスト内が相対参照がされてvideo.m3u8などのリソースが参照される。
https://www.nicovideo.jp/cache/file/nicocachenl_refcache=sm9.hls//video.m3u8
https://www.nicovideo.jp/cache/file/nicocachenl_refcache=sm9.hls//video/init01.cmfv
https://www.nicovideo.jp/cache/file/nicocachenl_refcache=sm9.hls//video/01.cmfv

こちらの環境ではこれらは期待通りのコンテンツボディを返します。
例えばffplayを使ったhls動画再生も出来てる。
ffplay -http_proxy http://localhost:8080/ -i 'http://www.nicovideo.jp/cache/sm9/auto/movie‘

>0350◆awd5z.AlOFJq 2024/06/08(土) 01:02:59.37
>開発版23をご使用の場合に、/cache/<smid>/auto/movieで再生できない問題の応急的処置したexpired_sourceChanger.jsをアップロード。
動作が何か期待と違うか。
expired_sourceChanger.jsは動画ページは開けても再生出来ない/watch/soXXXで動く機能だよね。

expired_sourceChanger.js。
初期化:mediaで"省略〜.hls//"の通信が発生しているからそこまでは成功している。
けど、そこから先を読み込まない。

現状ではまだ分からない。
expired_sourceChanger.jsの実装では自動でリダイレクトしないのかも知れない。

/auto/movie/の転送先のURLを指定してしまったほうが楽なのかも

https://www.nicovideo.jp/cache/file/nicocachenl_refcache=<smid>.hls//master.m3u8
をexpired_sourceChanger.jsに直接指定してみたけど404 Not Foundが返ってくる

>>159871
間違えた。今使ってるソースはmp4ソースだから404なのは当たり前だった…訂正。

公式で扱っているプレイリストはどれも.m3u8の拡張子がちゃんと付いているので、こういう原因かも。
/cache/sm9.hlsのリダイレクト先を"〜//"ではなく"〜//master.m3u8"として方がいいかな。
master.m3u8以外がマスタープレイリストにする時が来るかもしれないと思ってこういう仕様にしただけだし。

現状ではVideo要素のsrc attribute内で更に意図的にjavascriptでリダイレクトさせることは出来ないので今の応急処置が限界です。（多分）

大規模なサイバー攻撃に遭ってるみたいですねニコニコ…

> https://prtimes.jp/main/html/rd/p/000014844.000007006.html
>当社グループの複数のサーバーにアクセスできない障害が発生しました。
この表現をしていてなおかつ復旧期間を要してるってことは、認証を弄れるレベルの権限を取られたという前提で動いているみたいですね。
コンテンツのオフラインバックアップは普通はあるはずだけどどうなることやら。

ニコ動・障害、復旧まで１カ月かかる可能性も…再構築に「デスマーチ」心配の声 | ビジネスジャーナル
https://biz-journal.jp/company/post_381590.html
>そして、もし仮にランサムウェアの場合、データのみならずプログラムを含めたシステム全体が暗号され、加えて既存システムにウイルスが潜伏している可能性があるため、新規のハードウェアを調達するなどしてそこに一からシステムを構築する必要が生じるかもしれません。そうなるとバックアップシステムから戻せばよいとはいかず、かなり重い作業となり普及時期のメドもわからないという状況になります
>本番環境で障害起きた場合はバックアップ環境から戻すというのがセオリーだが、それだと、もし再びサイバー攻撃を受けると耐えられないことが分かったため、より高度なセキュリティー対応を施したシステムを構築し直す必要が生じたということではないか。
>ドワンゴの力をもってしても1カ月くらいかかる可能性もある

>キャッシュかわそのまま使えるのか、対応が必要になるのか
本格的にサービス再開されないと仕様がどうなるか分からないけれど
https://www.nicovideo.jp/watch_tmp/sm9
見た感じ動画データを引っ張ってくる通信は以前と同じ方法を使ってる。

8/5からニコニコ動画再開

>>159747の件、再発してます。

・ログ
CMAF付与情報取得失敗: (キー:ng, 値:ng, smid:null, noerror:null) (ページ更新で改善しない場合、おそらくインジェクションjavascriptかnlFilterの構成が失敗しています) https://asset.domand.nicovideo.jp/65361d7a9d4cb59698880bab/audio/1/audio-aac-64kbps/06.cmfa?session=3cbf0e5a2db1a1a9fae429839d02a311bac4c9f5d47c70020000000066b0a913cc4a0ca38c39405e&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9hc3NldC5kb21hbmQubmljb3ZpZGVvL　(長いのでカット)

・環境
(ブラウザ)
FireFox 128.0.3

(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 開発版23
動画ページの一番下にURLは出ていない

そもそもNicoCacheのプロキシ通すと動画視聴ページがエラーになって見れない。
nlFilter全部外しても見れないから、nlFilterが原因でも無い感じ。

直接接続にすると見れる。

動画再生すら出来ない直接の原因はurl_injection_sys.jsでRequestをwrapすると起きる公式側javascriptのエラー。
キャッシュ動作をさせるにはこれ以外にも修正しなければいけないようです。

RequestオブジェクトラップはProxyオブジェクトによる実装でたぶん安定。

動画の検索結果一覧に動画タイトル・動画サムネが表示されないのは nlFilters/10_thumbInfoFilter(ポップアップリンク用).txt が原因。

以前の仕様だと動画ページのHTMLに埋め込まれていたdata-api-dataアトリビュート(WatchVars:画質一覧情報などが入っていたもの)がなくなってる。
探してキャッチするコードを追加する必要あり。

進捗のみ

>2024-08-05 リリース無し:
>- ニコニコ動画がクラッキング被害を受けていた.
>- 2024-08-05にサービスを再開. 動画ページに仕様変更あり.
>- 動画ページHTMLの属性値data-api-data(WatchVars)が属性値server-responseに移動し，json構造も少し変更された.
>- 従来は画質モードごとにマスタープレイリスト(1つのvideo m3u8 URLと1つのaudio m3u8 URLを内容に持つプレイリスト)が提供されていたが，これは廃止されたらしい.
> 従来の自動画質モード用と同じ仕様のプレイリストのみが提供されるようになった.
> (例えば 1080p.m3u8 から 144p.m3u8 の各URLが一つのプレイリストに入っているもの. 音声も複数品質がありえるが，ニコ動にその例はない.)
> NicoCacheは画質モードごとのプレイリストに依存していたため，対応コードを追加する必要がある.
>
>
>開発版24 2024-08-06:
>- キャッシュ済み動画を再生した際に，キャッシュを利用出来るところまで実装.
>- 未キャッシュ動画のキャッシュ保存はまだ.
>- url_injection_sys.js の Request を Proxy による実装にした.
>- 属性値server-responseからWatchVarsを取り出すようにした.
>- 不便そうだから hlsキャッシュに対する /cache/<smid>/auto/movie を，hls to mp4変換URLにリダイレクトするように戻した.
> (ニコニコ動画公式プレイヤーに任意のhlsキャッシュを再生させる作業はまだ着手しない).

開発版25
https://nicocache.jpn.org/download.php?id=239&key=631f904d23f05602d2545b87e65689f8d202289c27b4cb0f5cd670e5b9a49dd6

2024-08-08:
- 選択可能なうちの最高品質を再生していればキャッシュ保存が動作するところまで実装.
例えば一般会員ならば720p, プレミアム会員ならば1080p, あるいはそもそも480pで投稿された動画ならば480pモードで再生している場合にのみキャッシュ保存が動作します.
それ未満の品質を再生してもキャッシュ保存はされません. これは一時的な縮退実装措置です.
- キャッシュ利用時にニコニコ動画のプレイヤーの品質選択表示がおかしくなります.
- nlFilters/10_thumbInfoFilter(ポップアップリンク用).txt で検索結果の表示が崩れる症状を簡易的に修正. あまり検証していない.

>>159960
　対応ありがとうございます。
　ただ、一部の動画は、再生が終わってもnltmpのままです。01.cmfvが欠けている模様です。

　ログはこんな感じです。

CMAF付与情報取得失敗: (キー:ng, 値:ng, smid:sm43888568, noerror:null) video-h264-360p.key
(cmaf)no cache found: sm43889788[1080p,192]_非言及秘密 ／ GUMI（真島ゆろ）.hls
+
caching sm43889788
CMAF付与情報取得失敗: (キー:ng, 値:ng, smid:sm43889788, noerror:null) video-h264-720p.key
caching sm43889788

全部のファイルをキャッシュ保存出来ているのにコンプリート処理(nltmp_smXXXからsmXXXにする処理)が走らないことがある。
NicoCacheを再起動して動画を再生するとコンプリート処理が走る。
ちょっと気になるけど、どうせ本格対応のために挙動を変えるから様子見で。

時間が被った。
>>159961
>CMAF付与情報取得失敗: (キー:ng, 値:ng, smid:sm43888568, noerror:null) video-h264-360p.key
>CMAF付与情報取得失敗: (キー:ng, 値:ng, smid:sm43889788, noerror:null) video-h264-720p.key
1080pでキャッシュを取ろうとしているみたいなので、この2つは問題にはならないです。一時実装のために手が回っていないために出ているエラーです。
ただ、360pのkeyと720pのkeyが通信に上がってきているということは、それらの画質モードを再生しようとしたということ。こちらでも再生中に画質変更があると何故かファイルが欠けやすいです。

今のところ回避策は、NicoCacheを再起動してから動画ページをハード更新(Shift押しながら更新ボタン)で、そうするとコンプリートする場合が多いです。

開発版25　Zenzaつかうとキャッシュできないなぁ

まだ動くZenzaあんのか

>>159963
　画質を自動以外にすると安定するようです。
　とりあえず1080pを指定しておけば、一番いい画質でダウンロードされるのようなので、それで使っています。
　報告まで。

>全体ランキングは表示されるのに個別だけ消えるのなんでやろな
例えばこれか
https://www.nicovideo.jp/ranking/genre/all
>- nlFilters/10_thumbInfoFilter(ポップアップリンク用).txt で検索結果の表示が崩れる症状を簡易的に修正.
修正作業はしてたんですが対応漏れです。
同ファイルの、 Name = ポップアップリンク置換(検索系) の下のURL条件から "ranking|" の8文字を消してください。

>>159966
画質自動だとキャッシュ漏れは高い確率で出ます。
本格的に新仕様に追従するにはしばらくかかるから、とりあえずすぐに実装出来るところまで書いたのが開発版25( >>159960 )で、
>- 選択可能なうちの最高品質を再生していればキャッシュ保存が動作するところまで実装.
というのはつまり、画質が下がるとその部分はキャッシュされないって意味です。
(それにどうも、画質自動の時は720pで再生開始するようになっているっぽい)
1080pで提供されている動画の720pをキャッシュ保存する機能は現時点ではないです。

>>159964
zenzaはずっと前に入れてインライン再生に魅力を感じなかったからそれ以来使ってない。
zenza側でNicoCacheが動いているかどうか判定して(NicoCache_nl変数が定義されているかどうかを判定して)、NicoCacheが求めるパラメーターを追加、例えば sm12345 なら nicocachenl_video_id=12345&nicocachenl_video_type=sm こういうのをm3u8を要求する時のurlの末尾にくっつければ、たぶんキャッシュも動きます。
https://greasyfork.org/ja/scripts/367968-zenzawatch-dev
開発止まってない？

userscript関連だとfavlistの開発引き継ぐ人いないかなあ…
https://kotas.hatenadiary.org/entry/20131025/favlist

>>159967
有志が対応更新続けてる感じなのかな
https://github.com/kphrx/ZenzaWatch
旧仕様だとキャッシュできてたけど公式プレイヤーに慣れるかな

>>159968
技術的な話になるけど、dms仕様になる前のDMC仕様の頃は動画ファイルの要求URLにsmXXXにつなげられる情報が含まれてたんだけど、今の仕様にはないんです。
無くなった情報を要求URLに付与してるのが local/url_injection_sys.js というjsファイル。
このは現在ページのURLを元にsmXXXを得て、動画ファイル要求URLに入れてる。

だからつまり、zenzaのインライン再生をurl_injection_sysに検出させて、そこからsmXXXを得て、動画ファイル要求URLに入れれば出来るかもね。

しかし今は本体の作業優先です。

metaタグにあるserver-responseが取れないんだがなんでだ？
document.getElementsByName("server-response")でもdocument.getElementsByTagName("meta")でも取れないんだけど

>>159973
取れるとしたら
>document.getElementsByTagName("meta")
これの後に絞り込みするか、あるいはこれ document.querySelector('meta[name="server-response"]');

だけど、view-sourceだと存在して、インスペクターだと存在しないから、ページ構築時にserver-response属性を持つmetaタグは削除されているみたい。
遅れて動作するjsで取るならwatchページをfetchしなおすなりXMLHttpRequestしなおすなりするしかなさそう。

うーん、それならどうせ整備されるであろう
NicoCache_nl.watch.apiDataもといNicoCache_nl.watch.serverResponse(nllib_watch.js)が用意されるまで待ったほうがいいのかな。

進捗だけ

開発版26 2024-08-24:
- 各画質をキャッシュ保存するための準備として以下を実装.
- キャッシュ利用時にマスタープレイリストの応答を乗っ取るのではなくサブプレイリストの応答を乗っ取る方法に変更.
- 動画音声チャンク要求をキャッチするまで一時個別キャッシュディレクトリ(nltmp_smXXX[XXXp,XXX]_*.hls)を作らないように変更.

あとはaudioチャンクを別のnltmpに保存するようにして、揃ってから各画質に振り分ける処理を書けたら一旦の区切り。

開発版27 2024-08-31:

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

- nlFilters/10_thumbInfoFilter(ポップアップリンク用).txt でランキング表示が崩れる症状を修正.

- どの品質でもキャッシュ保存出来るように実装変更と追加.

- 従来と違い「画質自動」であってもキャッシュ保存されます(NicoCache側は画質自動であるかどうかを知れないため).

- 音声を他のコンプリート済みキャッシュ(nltmpではないもの)から拾って来る動作にしたため，「この動画は投稿者によって修正されました」の場合に，不整合な動画キャッシュが作られる可能性があります. この場合は一旦当該動画IDのキャッシュを削除してから，キャッシュ保存をしなおして下さい.
　- 要求された音声と同じ品質のキャッシュがある場合，そこから音声を応答するため上記の動作です.

- そもそも「この動画は投稿者によって修正されました」に対応するにはキャッシュファイル名の情報を増やす必要がある. 現時点では全く対応していない.

- キャッシュ保存過程でnltmp_smXX[0p,192]_title.hlsのようなディレクトリが作られます. この中には音声だけが入れられます. 動画側と音声側両方のキャッシュファイルが揃ってから，音声データが動画側hlsに移動されます.

- ニコニコ動画のcmaf動画は1つの音声に複数の動画品質が結び付いているため，キャッシュファイルもそれに合わせて，音声用のキャッシュディレクトリと動画用のキャッシュディレクトリを分けたいところだが，それはキャッシュファイルをローカルで利用する上で不便であるため，従来通り一つのhlsフォルダに音声と動画が入っている形式でキャッシュを保存する.

- 2つ以上の音声が含まれる動画には対応していません(そもそも存在しないはず).

----

- テストはしてあるけどキャッシュ保存処理を多く変えたからバグを仕込んだかも知れません。
- キャッシュ利用時のログが多すぎるのはなんとかしたい。
- javascript側のNicoCache_nl変数に関する作業はこれから。

>>159987

　開発、ありがとうございます。
　うちでは今の所問題なく動いているようです。

>0588 名無しさん＠お腹いっぱい。 (ﾜｯﾁｮｲ 470c-BqIr) 2024/09/01(日) 13:20:53.87
>今までのは使えないと思って
>開発版、そのまま入れてBuild実行してもエラーが出る
エラー内容はなんですか。
今配付しているものはbuild済みだから、buildしなくても(ant extract jarしなくても)動くようにしてあります。

>>159968
zenzawatch。
通信をworkerから行ってるみたいですぐには対応できなさそう。

https://nvapi.nicovideo.jp/v1/watch/sm1234/access-rights/hls?actionTrackId=XXXXXXXXXX_1234567890123
これの応答がマスタープレイリストのURLだから、動画IDとプレイリストURLの紐づけが出来るから、url_injection_sys.jsを廃止出来そう(zenzawatchにも対応出来そう)。

>>159988
good.

>>159989
Debian10+openjdk 11.0.8環境というちょっと古い環境ですが今のところ問題なく動いてます!
過去閲覧キャッシュについても問題なく動いています!
ありがとうございます!

>>159989

どうもjavacが見当たらない様子。
java -versionを試してもjavacの表記がない。
何故だろう

>>159990
自分以外にもlinux環境で使っている人がいるとは驚き。

>>159991
あんまり確認しないで書きます。

「compile-pre-jdk8」が動いている。
java.specification.versionが1.8である場合に動くビルド処理です。
つまり、パスが通っているjdkのバージョンが古いようです。
（本当は古いjdk, jreを検出したらアップデートを促すメッセージを出すべきだけどやっていない。
　antとbuild.xmlをあまり理解してないから。）

環境変数のJAVA_HOMEとPATH、それとjava -versionの値を確認してみてください。
java.exeが新しくてもJAVA_HOMEが古いものを指しているかも知れません。

今のNicocacheはjava11〜java21が動作対象です。

>>159992
返答助かります。

cmd→Java -Verionの結果です

openjdk version "17.0.12" 2024-07-16
OpenJDK Runtime Environment Temurin-17.0.12+7 (build 17.0.12+7)
OpenJDK 64-Bit Server VM Temurin-17.0.12+7 (build 17.0.12+7, mixed mode, sharing)

先に書いた通りJavacの表記はありませんでした。

antの環境変数はちゃんと入ってました。なお一番上に移動してます。

残る可能性として
＠WIKIの「JDK 17(LTS)を選択してください」はもう古いのか？
＠本体を先に入れないとまずいんだろうか？

なお高速インストールを試しても先のコメに張ったテキスト通りのエラーが来ます。

>>159993
ビルドではなくただの実行は動作しますか(NicoCache_nl.batなどの方法で配布のNicoCache_nl.jarを実行)。

>＠本体を先に入れないとまずいんだろうか？
これはどういう意味です？
以前の開発の方(231111modまでの方)は差分配布をしていましたが、その次の配布からはjava以外は全部入りです。

こちらではこれらの環境でビルドテストしてる。
openjdk version "11.0.23" 2024-04-16
OpenJDK Runtime Environment (build 11.0.23+9-post-Ubuntu-1ubuntu123.10.1)
OpenJDK 64-Bit Server VM (build 11.0.23+9-post-Ubuntu-1ubuntu123.10.1, mixed mode, sharing)

openjdk version "17.0.11" 2024-04-16
OpenJDK Runtime Environment (build 17.0.11+9-Ubuntu-123.10.1)
OpenJDK 64-Bit Server VM (build 17.0.11+9-Ubuntu-123.10.1, mixed mode, sharing)

openjdk version "17.0.11" 2024-04-16
OpenJDK Runtime Environment Temurin-17.0.11+9 (build 17.0.11+9)
OpenJDK 64-Bit Server VM Temurin-17.0.11+9 (build 17.0.11+9, mixed mode, sharing)

openjdk version "21.0.3" 2024-04-16
OpenJDK Runtime Environment (build 21.0.3+9-Ubuntu-1ubuntu123.10.1)
OpenJDK 64-Bit Server VM (build 21.0.3+9-Ubuntu-1ubuntu123.10.1, mixed mode, sharing)

>＠WIKIの「JDK 17(LTS)を選択してください」はもう古いのか？
jdk17で正しいです。

>先に書いた通りJavacの表記はありませんでした。
rogu.txtにはjavacが動作している様子があるからスルーしてたんですがjava -versionではjavacに関する表記ってそもそも出ないのでは？

compile-pre-jdk8が動いている原因が分からない。
そちらのバージョンであっても動かないはず。
何かの理由で古いjavaやjdkを参照していそう。
あるいはソースレベルが何かで変更されているとか。
.settings/org.eclipse.jdt.core.prefs ってantは読むっけ？

ちょっと条件は違うのですがこちらではこういうログ。compile-pre-jdk8は空になるはず。
>前略
>detect-jdk-version:
>
>compile-pre-jdk8:
>
>compile-post-jdk9:
> [javac] Compiling 122 source files to /XXX/YYY/src
>
>compile:
>
>jar:
>後略

>パッケージjavax.cryptoは存在しません
これ自体は https://stackoverflow.com/a/14936517 に書かれているように build.xml 26行目にjceに関する表記を足して bootclasspath="${java.home}/lib/rt.jar:${java.home}/lib/jce.jar" にすることで解決するかも知れないです。
あるいは
>This class is only included in the jdk from oracle
と書いてある通り、入れたjdkにjavax.cryptoが含まれていないかも知れない。

でも、こちらが持ってるOpenJDK Runtime Environment Temurin-17となんで違うのかが見当つかない。
compile-pre-jdk8が動いていることと同じ原因でjavax.cryptoが見つからないと思ってます。

開発版28 2024-09-06:

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

- nllib_watch.js: NicoCache_nl.watch, initializedイベント, videoChangedイベントが動作するようにした. spawn系イベントはまだ動作しません.
- 開発者が個人的に使っていたキャッシュ済動画のリンク色変更スクリプトを追加(local/15_cached_link_color.js).
- nlFilterに直書きされていたjavascriptを個別のjsファイルにした(一部).

以下はリリースノートではない開発メモ。
- unknown Content-Encoding: br
- Brotli非対応が伝わっていないことがある(稀に).
- どのurlに出たか不明.

- ブラウザから見てマスタープレイリストが応答しないことがある.
- FirefoxのNetwork Monitor欄にはマスタープレイリストURLに対してだけstatus:blockedが並ぶ.
- uBlock Originは原因ではない.
- nicocache側にエラーは出ていない. 状態不明. timeoutが原因なら表示が出るか不明.
- "unknown Content-Encoding: br"を発していない時もこの症状はある.
- プロキシフレームワークに不具合があるか？
- nicocacheの開発作業中に起きやすい.
- nicocacheの再起動で改善する.

- 安定した再現性ありでキャッシュコンプリートできない動画がある.

お尋ねします
クリーンインストールをいつかしたいと思っていますが、外部の必要なファイルの一覧はありますか？
またかつて使用していて、これは必要のない外部のファイルがわかる方法はありますか？

>>159999
>外部の必要なファイルの一覧はありますか？
java環境以外にユーザーが用意する必要のある外部ファイルはないです。

>かつて使用していて、これは必要のない外部のファイルがわかる方法はありますか？
必要ないとは動作を阻害するとか機能していないという意味？
外部でなく本体同梱ファイルに関しては nlFilters/06_topBarが2段になるのを解消.txt が廃止されてます(空内容で配布に含まれてる)。
それ以外は開発スキルがないと判断難しい。
ファイルが配置されているだけで動作に影響を与えるのはnlFilters直下のtxtファイル, extensions下のclassファイル(それとconfig.properties)だから、それらをチェックすればいいです。

srcフォルダ下に余計なファイルがあるとビルド失敗の原因にはなりますが、動作には影響ないはず。
srcフォルダは削除しても問題ないです（独自改造してる人向けの説明は省略）。

>>とちゃき#//FjlV様
いつも返信・考察くださって感謝を。

開発版28 2024-09-06を導入したところ、ビルド成功。
起動も成功しました。
（GUIでの起動・利用はかなわずbatでの利用になりました）
動画検索画面では所持している動画のキャッシュ表示も確認できました。

ただ、キャッシュの有無に関わらず動画閲覧ページでは
「エラーが発生しました
リロードすることで回復する可能性があります」
の表示がでて再生はできず。リロードも同様。

他には
「カスタムマイリストボタンの設置が失敗しました
TypeError:root is undefained」
が右下に2つポップアップ。

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


failed to process: http://www.smilevideo.jp/view/（動画の数字ID、smが付く場合と数字のみの場合がある）
java.net.ConnectException: Connection timed out: connect

timed outについては同時に下記のメッセージも同じように上がります。
failed to process: http://api.nicodic.jp/page.exist/__fun__/v/(同上）
failed to process: https://tn-skr.smilevideo.jp/smile?i=(同上）
failed to process: http://api.nicodic.jp/page.exist/__fun__/v/s(同上）

動画自体は事件前にfetch、視聴していたものです。
利用ブラウザはfirefox、HTTPS機能の有効化等は済、
adblocK系は全オフでの状況です。

>>160001
- NicoCacheの起動時に表示されるバージョン情報はどうですか。
こういう部分。
>NicoCache_nl version 2024-09-06
> Running with Java 17.0.11(amd64) on Linux
NicoCache_nl起動スクリプトは環境変数NICOCACHE_JAVAやNICOCACHE_OPTSを参照しどのjavaを使うかを上書きする可能性があります。
それが古いjavaを指していませんか。

- 起動ログで起きているエラーのうちで一番最初のものはなんですか。
- 起動ログに「domand動画のための動画情報インジェクター」の文字列はありますか(起動してから25行目あたりに表示されます)。
- https://www.nicovideo.jp/local/url_injection_sys.js にアクセス出来ますか。404 not foundが表示されませんか。
- 最後に動作したNicoCacheバージョンはなんですか。

>「エラーが発生しました
>リロードすることで回復する可能性があります」
>「カスタムマイリストボタンの設置が失敗しました
>TypeError:root is undefained」
- エラーメッセージが曖昧ですがコピー出来ませんか。

smilevideo.jpはドワンゴが持ってるドメインではあるけど今は使われていないんじゃ？
- 例示されたURLはそもそもNicoCacheを使っていない環境でもアクセス出来ないのではないですか。

>CMAF付与情報取得失敗(2): (キー:null, 値:null, smid:smXXX, noerror:null (ページ更新で改善しない場合、おそらくインジェクションjavascriptかnlFilterの構成が失敗しています) https://XXX.XXX/XXX/XXX
このエラーが起きるということは、https証明書関係のセットアップは成功していそうだけど、他のエラーを見ると確信出来ない。
何か根本的なものがおかしいという疑いは継続です。

開発版29 2024-09-08:

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

- キャッシュコンプリート不発を改善.
- コマンド ant version でjavaやantのversionを表示する機能を追加.

既知の不具合:
- 既にtsファイルのhlsキャッシュがある場合に上位動画品質のキャッシュコンプリートが出来ない。
- 360p, 360p-mid, 360p-low, 360p-lowestなどに関して順位付けが実装されていない。
- 大量に動画を通した時のデータの捨て方が変。

>>160003
test_nlFilters.7zや他の拡張機能が入っているようですが、それらを入れずに、NicoCache_nl.7zを展開しただけの状態で動作させた場合はどうですか。
config.propertiesにport番号だけ書いて（あるいは8080で使ってるなら、config.propertiesもなしで）NicoCache_nl.bat を起動させてみてください。

>NicoCache_nl version 2024-09-06
>Running with Java 17.0.12(amd64) on Windows 10
>https://www.nicovideo.jp/local/url_injection_sys.js にアクセスした場合、うｐしたテストファイルのような文字が表示されました。
これらは期待通りで正常でした。

>「エラーが発生しました　リロードすることで回復する可能性があります」
そうか。このエラーはコンソール(dos窓)じゃなくてブラウザのプレイヤーに出てたのか。

動画コントロールの歯車マーク(⚙, 設定)ボタン　→　プレイヤー設定欄の一番下の「システムメッセージを表示」　→　「コピー」　で動画再生に関するログが得られます。
このログにはニコニコ動画のユーザーIDが含まれるので気をつけて下さい。
ここにはどういったエラーがありますか。

>failed to process: http://www.smilevideo.jp/view/(動画ID:数字）
>java.net.ConnectException: Connection timed out: connect
レス文に含まれるこれらのエラーがどれもこれもhttpsじゃなくてhttpで出ていて、これが不可解です。
それに現在のニコ動はsmilevideo.jpを見に行かないはず。
タイムアウトはNicoCache側の原因ではなくサーバーが実際に応答しないためです。

今のニコニコ動画はhttpsが強制されています。
http://www.nicovideo.jp/watch/sm9 [Embed]
例えばこういったhttpのページへアクセスしても、httpsへ強制的に移動させられてしまいます。
このurlを開き、ページが表示された後に、もう一度URLを見てみてください。それはhttpsで始まっていますか？

httpsページからhttpへの通信はブラウザがブロックします。
だから普通の動画ページを開いたり、検索ページを開いたりしただけで、NicoCacheがhttp通信を捕捉するのは不可解です。

- nlFilterかextensionの中に古い拡張が残っている可能性が高いです。
- あるいはhttpに留まるような、リダイレクトを拒否するような、https通信をhttp通信にするような、特殊なブラウザaddonが動いている可能性があります。

>後半は多分タイトル名だとは思いますが……
パーセントエンコーディングというそのままの名前の表現です。
今回は重要じゃない。

>最後に起動したバージョンは事件前の最新version差分です。
>その後全ファイルを消し、再度１からインストール手順をやり直したうえで開発版を入れています。
今年6月のランサムウェアクラッキング。
事件前用NicoCacheと事件後用NicoCacheは動作ロジックを変えただけで外部ライブラリの依存関係を変えたわけではないので、さらに不可解です。
ログにあった「パッケージjavax.cryptoは存在しません」のjavax.cryptoは事件前から参照しています。
手順を追って再インストールしてるならその過程で何か不必要なものが入っているかも知れません。

>ほぼ個別対応になってしまって・・。
こっちの時間が取れなくなったら応答が鈍くなると思います。

>>160005
いつもながら考察に感謝を。リアルの都合でお返事遅れました。

httpsの問題のご指摘をいただき、
こちらの環境上の問題が確認できました。

利用してるプロクシアドオンが
現在のニコ動のアドレス挙動に対応できず、
アドオン起動中は直刺しの接続設定にも影響を与えることがわかりました。
(httpsの問題については、事件前からの仕様と伺っておりますが、
少なくても事件前はアドオン経由で普通に利用できていたので見落としておりました）

アドオンを停止したのち、開発最新版を導入したところ、
GUI.jarこそ起動しませんでしたが、それ以外は無事に起動、
動作も問題なく行える状態になりました。

挙動報告としては、ニコ動の視聴あるいはサイト内検索している裏で、
failed to process: http://www.smilevideo.jp/view/(手持ちの動画の数字ID）
java.net.ConnectException: Connection timed out: connect
と視聴動画以外の手持ちのmp4キャッシュ動画の接続エラー？が出ていました。
(hls動画についてはありませんでした）

これについては何らかの動画を視聴した直後から
ログ内で手持ちのキャッシュ動画の数だけ表示されました。
なお、ブラウザで手持ち動画アドレスに飛ぶとログに
(cmaf|sub)single file cache found. disable cache: 動画ID1.mp4
と表示され、キャッシュ視聴が適応されています。

長らくのお手間をおかけして、申し訳ありませんでした。

■質問用テンプレ
このような質問の仕方でよろしかったでしょうか。お願いいたします。

　≪動作環境≫
　　【OS・Java・本体】NicoCache_nl version 2024-09-08 Running with Java 17.0.12(amd64) on Windows 10
　　openjdk version "17.0.12" 2024-07-16
　　OpenJDK Runtime Environment Temurin-17.0.12+7 (build 17.0.12+7)
　　OpenJDK 64-Bit Server VM Temurin-17.0.12+7 (build 17.0.12+7, mixed mode, sharing)

　　【使用ブラウザとバージョン】firefox 130.0 Chrome 128.0.6613.138（Official Build)

　　【使用プレイヤー】
　≪NicoCache環境≫
　　【extension】なし
　　【nlFilters】なし
　　【プロキシ】
file:///C:/pac/proxy_sample.pac　設定後
トラブルシューティング　7.ネットワーク設定　にて　NicoCache_nl version 2024-09-08　出力
http://127.0.0.1:8080/proxy.pac　設定後　上記出力せず
　　【その他】
　≪質問/障害内容と検証状況≫
　　【事象・質問内容】
OSのクリーンインストール後、NicoCache_nlのフォルダ内は　version 2024-09-08　を使い、
ant設定、java設定、ffmpeg設定（3つはインストールして環境設定設定済）、
証明書（フォルダ内のものを紐付け、）、pac設定したが、
firefoxとGoogle Chromeにて画面の変化が見られない
　　【検証済の内容】プロキシ設定後、NicoCache_nlを終了しても「ローカルプロキシサーバに接続を拒否されました」の画面が出てこない
　≪その他≫
　　【トラブルシューティング試行有無】
　　【特記事項】

追記です
http://127.0.0.1:8080/proxy.pac
でプロキシ設定してトラブルシューティング7を試しましたら、nicocacheのバージョンが出てきました

しかし動画を視聴してもログには全く書き込みがありません

>>160009
>>160011
質問が少ない間は雑に投げてくれてもいいです。
テンプレートを埋めてくれた方が手間が省ける可能性が高まります。

- トラブルシューティング7はこれ？
https://w.atwiki.jp/nicocachenlwiki/pages/18.html#id_854ed257

>nicocacheのバージョンが出てきました
NicoCacheが起動してることは確認出来ました。

- ブラウザ通信がプロキシを通っていない可能性が高いです。
>プロキシ設定して
の部分に不備があるはずですが具体的にはどの方法を使いましたか。

Firefoxの場合は、「設定→ネットワーク設定→自動プロキシー設定スクリプト URL(A)」に読み込み可能なpacを指定する必要があります。
あるいはWindows側に設定した後に「システムのプロキシー設定を利用する」(この方法は私は検証したことがないです)。

pacが読み込み可能かどうかは、例えばURL欄に file:///C:/pac/proxy_sample.pac と入力してダウンロード挙動が起きるかどうかや中身が表示されるかどうかで判断して下さい。

Google Chromeの場合は、addonを使わない場合はシステムプロキシだけを参照します。
(私は https://chromewebstore.google.com/detail/proxy-switchyomega/padekgcemlokbadohgkifijomclgjgif
これ使ってプロキシ設定を切り替えながらテストしてます。
でもどうも近々使えなくなるらしい。)

- ブラウザ通信がプロキシを通っているかどうかは以下で確認出来ます。
1. https://www.nicovideo.jp/cache/log
2. https://delivery.domand.nicovideo.jp/cache/log
3. https://asset.domand.nicovideo.jp/cache/log

それぞれ「NicoCache_nlのログをページから見るには〜」かログ自体が出れば成功です。

1が失敗ならプロキシ設定自体をブラウザが認識していません。pacファイル自体が読み込まれていないか、NicoCacheが用意したものとは別のpacファイルを参照している可能性があります。

1だけ表示されて、2と3が表示されない場合はpacファイルが古いです。3月よりも前のNicoCacheに入っていたpacを参照している可能性が高いです。

>>160008
出ているエラーメッセージは再生出来ない直接の理由ではなかったのでしょう。
>リアルの都合でお返事遅れました。
ネット掲示板は時間が空いてもいい場所だと考えています。
>(cmaf|sub)single file cache found. disable cache: 動画ID1.mp4
この表示は正常だけど、キャッシュ利用はしていないです。
今のニコニコ動画のプレイヤーにキャッシュを利用させるにはhls形式に変換する必要があって、そういう自動変換機能を用意していない。

雑な方法だと
ffmpeg -i 入力動画 -c:v copy -c:a copy -f hls -hls_time 6 -movflags cmaf -hls_segment_type fmp4 -hls_playlist_type vod -hls_segment_filename "%d.m4s" 'master.m3u8'
これの出力結果をNicoCacheのキャッシュ形式の名前のディレクトリに入れてからNicoCacheを再起動すると認識します。
(ただこれ、拡張子が違うし、audioとvideoを分けていないから決定版にはならない)

>>160012
返信ありがとうございます。
正常に起動することができました。

原因はプロキシ設定の
file:///C:/pac/proxy_sample.pac
ではなく
file:///C:/pac/proxy.pac
でした。

初歩的なURL間違いでした。
ご迷惑をおかけしました。

106_PlaybackrateChanger.txtの
nimg:KillOfficialPlaybackrateControllingが効かないんですけど理由分かりますか？
-----

[Replace]
Name = nimg:KillOfficialPlaybackrateControlling
FullURL = https?:\/\/[^\/]+\.nimg\.jp\/[a-z]+\/[a-z]+\/[a-z_]+\/[a-z]+\/[-._a-zA-Z0-9]+\.js
Multi = TRUE
Match<
playbackRate
>
Replace<
pbR_
>
-----

URLは
https://resource.video.nimg.jp/web/scripts/nvpc_next/assets/_web.watch._id._-D8jsqa9y.js
です。

NicoCache_nl Wiki (新）のサイトを見ていたのですが

mp4box.exe,swfextract.exe,libgpac.dll
この３つはNicoCache_nl導入時に他からダウンロードしてNicoCache_nlフォルダ内に入れていましたが、2024/09現在必要ですか？

>>160015
横からすみませんが、今使ってるのはffmpegを主流に使っているはずです。
私は開発者「とちゃき#//FjlV」では無いのですみません。

>>160016

ありがとうございます
不要ならばいらなそうですね

>>160014
証明書生成スクリプト(genCerts.bat, genCerts.sh)とdefaults/30_NicoCache_nl_TLS.propertiesに
*.nimg.jp と *.cdn.nimg.jp はあるけど、 *.video.nimg.jp がなくてプロキシ動作してないからだと思う。

https通信で、なおかつ設定ファイル(propertiesファイル)に書かれていないドメインはpacファイルに書いてもプロキシ動作しない、という仕様だったはず。
(よく考えるとなんでエラーなしで素通り挙動になるか分からないけどdms/domandに対応した時の記憶はこうでした)

次のリリースで *.video.nimg.jp を追加しておきます。

>>160015
>>160016
はい。swfextractとmp4boxよりもffmpegを優先して使うようになってます。
それらやffmpegがなくても基本的な動作はするけど、mp4への変換やmp3への変換などが動かなくなります。

>>160018

言われた通りにやってgenCertsして証明書を入れ直してFirefoxとWindowsに登録し直したら表示されなくなりました
https://i.imgur.com/yWzVf1I.png

https://resource.video.nimg.jp/web/scripts/nvpc_next/assets/_web.watch._id._-D8jsqa9y.js
のエンコードもおかしくなって直らない

https://i.imgur.com/Mdowwdh.png

https://resource.video.nimg.jp/web/scripts/nvpc_next/assets/_web.watch._id._-D8jsqa9y.js
のコンテンツが
unknown Content-Encoding:br
になって文字化けしますねー。

>>160019
>>160020
brotli拒否(要求のAccept-Encodingからbrを削除)が出来ていないみたい。
これはjavaコード側をなんとかするしかないです。

---

https://github.com/hyperxpro/Brotli4j
brotli対応させるには
- ライセンスがMITとApacheだからどっかにビルド済みバイナリを置いておいて必要な時に引っ張るようにする
- javaでダウンロードと展開配置スクリプトを書かなきゃいけない
- 同梱する(配布サイズが大きくなりすぎる)
- ビルドツールをantからmavenに引き上げる
- 一般ユーザーには荷が重い

開発版30 2024-09-17
https://nicocache.jpn.org/download.php?id=249&key=631f904d23f05602d2545b87e65689f8d202289c27b4cb0f5cd670e5b9a49dd6

- キャッシュ保存フラグ変更に関するバグ修正.
- 動画情報の忘却方法を変更.
- 再度コンプリート不発を改善.
- nlFilters処理でAccept-Encodingからbr(brotli圧縮)を除去( >>160019 >>160020 の件).

- ドメイン追加: *.video.nimg.jp
　- certs更新作業の documents/Readme_TLS.txt を行なってください.
　- pacファイルも変更してください. proxy_sample.pacを参考に *.video.nimg.jp も対象になるようにしてください.

　- certs更新作業をせずに使いたい方や作業を遅らせたい方はconfig.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:*
　- 証明書変更作業が済んだらこの記述を削除して下さい.

開発版30ありがとうございます。
ただnimg:KillOfficialPlaybackrateControllingはplaybackRateをpbR_に置き換えても効果なしですね。(空白に置き換えても同じ)新しい再生速度を設定しても強制的に1.00に戻されてしまってどうしようもない。fake premiumも潰されてしまってisPremiumの値を弄ってみても効果がないようです。(server-responseの値を弄っても効果なし)

#効果なし
[Replace]
Name = nimg:KillOfficialPlaybackrateControlling
FullURL = https?:\/\/[^\/]+\.nimg\.jp\/[a-z]+\/[a-z]+\/[a-z_]+\/[a-z]+\/[-._a-zA-Z0-9]+\.js
Multi = TRUE
Match<
playbackRate
>
Replace<
pbR_
>

#効果なし
#[Replace]
Name = nimg:ChangeIsPremium
FullURL = https?:\/\/[^\/]+\.nimg\.jp\/[a-z]+\/[a-z]+\/[a-z_]+\/[a-z]+\/[-._a-zA-Z0-9]+\.js
Multi = TRUE
Match<
isPremium
>
Replace<
true
>

>>160023
そちらのnimg:KillOfficialPlaybackrateControllingはFullURL条件が間違っていませんか。
( この掲示板は修飾が動作して文字が欠落することがあるからそのせいかもしれないけど。
　nlFilter内では/はそのままでいいです)
FullURL = https?://[^/]+\.nimg\.jp/[^/]+/[^/]+/[^/]+/[^/]+/[^/]+\.js
これで置き換えが発生する。

- サブドメインを含めてnimg.jp下のjsファイル全体を対象にplaybackRateを置き換えると期待通りに再生不能になるからやりようはありそうです。
- メインの動画コントローラーと思しきweb.watch._idファイル内のイベントハンドラ用と思しき部分で執拗に再生速度を設定し直すコードが含まれているますがこれが実態コードなのかどうか疑わしい。
- document.createElementやdocumentからnodeを探すコードをwrapして、video tag作成や検索を検出して、それらに対してproxy化したvideoを返す方法も考えられるけど、難易度高め。

>>160025
ありがとうございます。
お陰様でフィルタまとめ#142をリリースできました。

>firefoxで動画ページだけ読み込みがループしてる感じで背景以外表示されないんだけどおま環？
>証明書更新ミスったのかな…
>開発版のこと色々話してた掲示板も404だし困ったもんだ
いつからですか。
開発版30を入れてから表示出来ていたことはありますか。
上手く動作していたことがあるなら動画ページでshiftを押しながら更新を何度か試してください。

pacファイルに以下の記述をすると動画ページスクリプト関係がNicoCacheを通らなくなります。
(function FindProxyForURL(url, host) { の次の行あたりに追加してください)
(記述してからpacファイルを再読み込みさせてください)

if (shExpMatch(host, '*.video.nimg.jp')){ return 'DIRECT'; };

ブラウザから https://resource.video.nimg.jp/ を開いて証明書の発行者がAmazonになっていればNicoCacheを通っていない通信です。
ただこれで治るかどうかは分からない。
この回避策を使うと「フィルタまとめ」の一部が動かなくなります。

>failed to process:java.io.SSLexception～
>resource.video.nimg.jpとかって表示されてループ。
実体サーバーとNicoCacheとのやりとりでエラーが起きてる。
エラー内容詳しく分かりますか。
こちらでは出ない。

>resource.video.nimg.jpにアクセスしたらAccess Deniedって表示。
これはNicoCacheを通していない場合も起きる。
けど自分の環境では再生ページの構築失敗は起きたことがない。
検証してないけどリファラがニコニコじゃないと弾くんだと思う。
必ず弾かれるわけじゃないのがよく分からない。

>>160027
気が付いたのは20日0時ほどです
フィルタまとめ#142を入れて動作チェックしようとしたらループしてた、という感じです

開発版30がロダに上がってたその日に入れてその時は問題なく再生できてたと思います

shift更新も試しましたが駄目でした
pacの記述と再読み込みも試しましたが症状は変わらず
そのあと
>ブラウザから https://resource.video.nimg.jp/ を開いて
↑このURLをたたきましたが、「この XML ファイルにはスタイル情報が関連付けられていないようです。以下にドキュメントツリーを表示します。」と英文が色々書いてあるだけのページに飛びました
amazonという記述は見当たりません

>>160029
キャッシュを削除したら動画再生ページが正常に戻りました
ありがとうございます！
pacの記述も削除して試しても問題ありませんでした
firefoxもchromeも元通りなりました

自分はまだ直りません…
ダイレクトモードにしてキャッシュを削除すると正常に再生されますが、NicoCache_nlを通すと表示がループして動画再生画面が表示されません。
一昨日までは正常でした。

…と思ったけど、ダイレクトモードで正常なキャッシュを作ったらプロキシ通したら正常に再生されるようになりました。
…なんだったの？

>>160031
>NicoCache_nl error.txt
>failed to process: resource.video.nimg.jp:443
> javax.net.ssl.SSLException: 確立された接続がホスト コンピューターのソウトウェアによって中止されました。
> Caused by java.io.IOException: 確立された接続がホスト コンピューターのソウトウェアによって中止されました。
ソ[フ]トウェアではなくソ[ウ]トウェア。
https://www.gwtcenter.com/error-code-10053
>結局のところ、このメッセージはWindows側のWinSockのエラーらしい。
こちらはlinuxだから起きないわけか。

- ウィルス・マルウェア対策ソフトの誤爆。
- resource.video.nimg.jpに疑われたことによってreset packetを投げつけられた。不審ならAccess Deniedが出るはずだからこれは確率が低い。
resource.video.nimg.jpに1秒1byteの速度で通信を仕掛けても20分間以上タイムアウトにならずに通信を続けられる。

NicoCacheが原因なのかどうかもよく分からない。
NicoCacheは要求ヘッダを変更するから可能性はあるけど、それならもっと安定して再現するはず(みんなに起きるはず)。

あれから色々と試したけれどpacファイルに>1600027の

if (shExpMatch(host, '*.video.nimg.jp')){ return 'DIRECT'; };

↑これ記述しないと再発しちゃう

こちらでは今のところ再発していないです。

これ多分by ◆awd5z.AlOFJq フィルタまとめ＃142の中にある101_PremiumStatusModificator.txtのせいだと思う
1回1回キャッシュ削除しながらフィルタ1つずつ入れて確かめたけどこれが有効だとループする
因みに自分はプレ垢ではない
使用ブラウザはfirefox

>>160037
こちらでも再現しました。
それが原因のようです。

直すには nlFilters/101_PremiumStatusModificator.txt を外してから、ブラウザのキャッシュ削除が必要でした。

あまり検証していないけど、ある範囲でエラーが起きると動画ページ(http://www.nicovideo.jp/watch/smXXX [Embed])のリロードが公式のjavascriptによって引き起こされているみたい。

久しぶりに覗いたら開発版新版出てた

>>160012
プロクシの利用の件について今後のため記載します。

実は自分、まだHTTPSじゃない時代からですが
firefoxアドオン「FoxyProxy」を使ってまして、
画像にあるような設定をしたうえで
proxy.pacを介さず接続するようにしていました。
(ニコキャッシュの起動中でもそれを介さない接続に即時切替ができるメリットがあったため）

で、HTTPSになってからもfetchやキャッシュ動画の有無は確認できてたので
そのまま利用していたのですが、
現在の仕様になって普通の動画視聴すらできなくなったという感じです。

なお、同一アドオンの設定で
「HTTPの選択肢部分をHTTPSにする」
或いは
「proxy.pac経由の串を別に設定する」
ことも試しましたが
そもそもFoxProxyを経由した時点でうまく動きませんでした。
現在はアドオンを停止して使用しております。

開発版31 2024-10-04

アップローダー( https://nicocache.jpn.org/ )にアクセス出来ないのでとりあえずここに直接置いておきます。

- zenzawatch対応. ( >>159964 )
　- マスタープレイリストURLとsmidの対応を通信からも拾うように変更.
- url_injection_sys.jsを廃止.

>>160052
>FoxyProxy
同じ設定は試していないけれど、HTTPで指定する方法とPACファイルを指定する方法は問題なく動きました。
URLパターン指定が怪しそう。

>(ニコキャッシュの起動中でもそれを介さない接続に即時切替ができるメリットがあったため）
ここでいう即時切替とは手動切り替えですか。
プロキシが利用出来ない時に別のものやDIRECTに切り替えるみたいなオプションは見つけられなかったです。

ニコニ広告しようとすると「安全な接続ができませんでした nicoad.nicovideo.jp への接続中にエラーが発生しました。」って表示されるけど普通？

// アップローダー( https://nicocache.jpn.org/ )にやっぱりアクセス出来ない。

>>160059
どの段階で出ますか。
こちらだと動画ページのニコニコ広告ボタンから広告確定後の福引完了まで、ブラウザ側もNicoCacheのログ側も何もエラー出ないです。

>>160060
こんな感じです。

>>160061
理由が示されない「真正性」エラーって通信が切断されたときに起きたような。
不正であっても証明書が確認できれば「再試行」の横に「詳細へ進む」が出るはずだから。

- その時にNicoCache側のログには何か出ていますか
- NicoCacheを使わない場合は表示出来ますか
- nlFiltersフォルダを空にした状態だとどうですか(原因である可能性は低いと思いますが一応)

>>160062
>- その時にNicoCache側のログには何か出ていますか
添付ファイル
>- NicoCacheを使わない場合は表示出来ますか
表示できません
>- nlFiltersフォルダを空にした状態だとどうですか(原因である可能性は低いと思いますが一応
変わりません（表示できません）

ということはNicoCache関係ない…？

>>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をそのブラウザに設定してみてからもう一度試してみてください

>>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仕様を流用したものです.
　- <cacheFolder>/<smid>.data/comment.0.ja-jp.json に保存されます(ロケール部(ja-jp)はニコニコ動画の動作言語ごとに変わります).
　- json構造を含めた細かい仕様は未定.
- ディレクトリ仕様: cahcedir/<smid>.data/ を追加.
　- このディレクトリには一つの動画に紐付いているとみなせる情報を配置します.
　- プレフィックスで区別出来るようにしてください.

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

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