【ニコ生】新配信録画ツール（仮、livedl Part9

**名無しさん＠お腹いっぱい。** · 2025/03/28(金) 14:15:45.27

!extend:checked:checked:1000:512:donguri=2/3
!extend:checked:checked:1000:512:donguri=2/3

スレの立ちにくい板なのでスレ立てを優先します

VIPQ2_EXTDAT: checked:checked:1000:512:donguri=2/3: EXT was configured

**504** 警備員[Lv.0][新芽] · 2025/10/31(金) 13:48:57.81

>>525
新規だと直るんですね、使ってるか調べてないけどレジストリやappdataの古い設定のゴミが残ってると悪さするとか？
フォルダ見直しても上書きだけで変になるような部分は見当たらないんですけどね

**nnn-revo2012** 警備員[Lv.4][新芽] · 2025/10/31(金) 17:26:56.56

>>527
>レジストリやappdata

guest_nicoさんのツールはすべてどっちも使ってない(いわゆるポータブル版みたいな位置づけ)

何年か前のバージョンでニコ生放送チェックツール（仮.configの中のkeyがずれて保存されたかkeyが抜けるかしたんじゃないかと思う
それ以降チェックツールが一見動作してるけど謎の不具合が出続けてるのはそれが原因じゃないかと
だから古くからずっと使っててまめにバージョンアップしてる人ほど謎の不具合が出るんじゃないかな？

修正方法はguest_nicoさんの掲示板をさかのぼってみてくれ

**nnn-revo2012** 警備員[Lv.4][新芽] · 2025/10/31(金) 17:46:21.95

ここ１、２日久々にここに書き込みしたけど、自分は情報提供できると思ったから書いたまで
nnn-revo2012なんて見たくもないという人は専ブラなら名前かなんかで見えなくなるようにすればいいです
ここやguest_nicoさん、四八福星間開発さんの掲示板も含めても基本書かないようにしてますんでご心配なく

2025/10/31(金) 21:58:31.28

>>529
各所で見かけております、よく話題に参加してくれて毎回適格な見解ありがとうございます。

2025/11/01(土) 02:13:07.53

文章に特徴があるから名前なくてもわかるけどねw

2025/11/01(土) 02:49:13.32

>>529
おまえがいないとこのスレ過疎るから今後も書き込み頼むわ

2025/11/01(土) 04:33:25.72

>>305これ書いててまだ沸いてこれる厚顔無恥ならお好きにどうぞ

**nnn-revo2012** 警備員[Lv.0][新芽] · 2025/11/01(土) 06:56:14.87

今更だけど録画ツール（仮から外部ツールとしてstreamlink/yt-dlpを起動するのは作者に却下されたけど、
なら現状の今の外部ツール起動（*.m3u8をFFmpegに渡す）する際に例のcookieを渡すように改造すればいいのでは？
これなら動画/コメントのvpos同期以外の問題は解決するのでは？と思った
もちろんこれも作者に却下されると思うけど法律うんぬんより実際この方がサーバーに優しい（無駄なアクセスがない）わけでwin-winじゃないかと思った

**nnn-revo2012** 警備員[Lv.3][新芽] · 2025/11/01(土) 09:55:20.16

もう一つ
リアルタイム録画で録画数が多くてBOT判定されるのはわかるけど、タイムシフト録画のみ（動画＋コメント）でBOT判定されるケースはあるの？
タイムシフトなら動画とコメントのツールの起動時間を数秒から1分ぐらいずらせば引っかからないと思うけど？

2025/11/01(土) 11:10:40.18

そうしたいならお前が作れよ

**nnn-revo2012** 警備員[Lv.0][新芽] · 2025/11/01(土) 22:03:44.27

>>536
作ったとしても僕のアンチがドワンゴに通報しまくって警告が来て公開停止の流れじゃないかね？
例えUA偽装したところでそれ以外の要素からツールかどうか特定できるはずだから無理としか言いようがない

2025/11/03(月) 22:56:56.94

昔はそんなもん無視して作るホンモノだけしか居なかったんだけどな

2025/11/04(火) 09:53:23.65

今は正義マンだらけで無理だな

2025/11/08(土) 01:46:28.28

古いPC(HDD)をwindows11にして
ニコ生放送チェックツール（仮 + streamlinkで
保存したらどれも音声が再生されなくなって
windows10の時と同じようにキャッシュをRAMDISKに設定したら
問題なく記録されるようになりました
streamlinkのオプションは--default-stream bestだけ
ちなみに真空波動研究では
800x450 8Bit AVC/H.264 Main@3.1 1:1 Progressive 30.00fps 3960f 103.43kb/s[2][不明cmfc]
となってました

**nnn-revo2012** 警備員[Lv.4][新芽] · 2025/11/08(土) 18:30:29.36

>>540
それstreamlinkに多分なんらかの原因でFFmpegが起動できないか、FFmpegがない状態とみなされて映像データーだけをダウンロードして終了したんだと思います
その対策の一つはRAMDISKにすることなんだと思います　どんな環境か、同時にどんだけ録画してるか知らんけどDISKIOが足りないんじゃないかと思われ
ニコ生が動画の仕様変更する前は単に動画をDLして結合すればよかったけど、今は映像と音声の２つをDLしてそれをFFmpegで結合しないといけないわけでパソコン側の負担も前よりずっと高くなってる
それで録画できてるんならそれでいいんじゃないですかね？

2025/11/11(火) 22:42:41.88

10月30日ぶり以来、久々に405再発して概要が大体わかってきました。

今回はブラウザで数秒で複数タブを開くような操作はしていません。
直近12時間のニコ生転送量は4配信2GBほどで、転送量は普通でした。

今回の時系列
20:09　自動録画でstreamlink＋仮コメント生録画起動
20:57　TS録画確保、作業開始
20:57-21:06　3.27GB　sl+仮米録画
21:07-21:09　1.18GB　sl+仮米録画
21:07-21:11　自動録画でstreamlink＋仮コメント生録画起動　録画終了
21:11-21:13　700MB　sl+仮米録画

そして700MBの終了確認後すぐ、手動で次の用意してたTS録画実行しようとしたら405、ブラウザで確認したらBOT判定画面
作業中に並行してブラウザで視聴確認範囲指定作業はDLと同時には行っていました。
21:17に405は解除されました。

おそらく問題あったのは、生録画、米生録画中にTSのSL録画、米録画、最大計4タスクを同時に実行したのがBOT判定の原因
もしくは短時間、今回は15分内に5GB以上の転送が原因
もしくは短時間にstreamlink、仮の累計タスク使用総数が多かったのが原因、多いといっても計10個程度ですが

そんなにハードに使っていなくても、この程度で405は出るので参考にして注意してください。

**nnn-revo2012** 警備員[Lv.0][新芽] · 2025/11/12(水) 01:43:03.87

>>542
AWSになってからのタイムシフトは昔と違って最初に取得した*.m3u8にすべてのセグメントが載ってるからツール側でDL速度制限でもしないと爆速でDLしちゃうんでしょうね
仮に仮さんがツール作ってたらその辺に制限かけて従来通り2倍ぐらいのDLにしてたんだろうけど、Streamlinkの作者さんは「DLできるならできるだけ速くするのがベスト」みたいな考えらしいです
Streamlinkにyt-dlpにある帯域制限機能がないのは作者さんのポリシーだとかどっかのスレで見たような気がします
非公開でツール作ってる人がもしタイムシフトで405が頻発するなら、DLにwaitかけた方がいいかもしれません　だから何だと言われてもですが

2025/11/12(水) 05:57:43.39

>>543
実は、ここの過去スレでStreamlinkの帯域制限を発案した者でもあるですが、--ringbuffer-size 16Mがデフォルトであるのを10とか100とか1000とかに変更したら速度制限できるよと書いて以降、こんにちまでずっとTS時は帯域制限してstreamlinkを使用してきました。
ですがここ最近は、この方法ではCPUリソースが食われ電気代節約とやはり速度を追い求めて通常は200と300設定に、6、8Mbps配信の高画質配信で速度を上げたい場合600や1000～1200設定にしてるのですが、
時間帯によってASW側の転送速度は変わるんですが、10～25MB/s、80～200Mbpsほどの速度で現状落としていました。
ほぼ速度制限していない速度と変わらなかったかも知れません。
ringbufferを100前後以下に設定するなら、自由に帯域制限をかける事ができますが何個もあるTSに何時間もかけていられませんしね。

前回も生録画中にTS作業をして405になったので、おそらくですがタスクを同時実行するのが一番の原因だと思います。
短時間に転送量を使っても問題ないはずだと思います。
普通に12時間8Mbps配信1個で25GBを20～30分かかりますが、過去に何度も落としてきて前後に405制限された事は1度もないです。

常時チェック仮、同時タスク、ブラウザ視聴などの複合的要因が重なりBOT判定になってるのかも知れません。

**nnn-revo2012** 警備員[Lv.4][新芽] · 2025/11/12(水) 08:49:21.16

>>544
妥協案としてSlなんとか（またはStreamlink or yt-dlp)と（仮の起動時間を10秒ぐらい（もっと長くでもいいけど）空ければいいんじゃないかと思います
リアルタイムだとコメントが・・・って思うだろうけど、実はメッセージサーバーになってからのコメントは一般アカウントでも過去のコメント取得できるんだよねー

2025/11/12(水) 12:22:41.88

でもこの人以外に405の報告でてないのは不思議

**nnn-revo2012** 警備員[Lv.5][新] · 2025/11/12(水) 12:52:17.36

>>546
SlNicoLiveRecのコメントに2件ぐらいあるから出てる人は出てるんじゃない？
今のところ解除される時間が短いようから気づいてないとか？

2025/11/12(水) 18:39:34.41

>>547
あっち見てなかった
確かに見たらあるな

あっちで、こっちのスレの話題を出してる人いるが
あっちの作者に今回のケースの405の原因を聞いてもさすがにサポート対象外だろう
まずはこっちで聞けばいいのに

**nnn-revo2012** 警備員[Lv.7][新] · 2025/11/12(水) 19:14:50.14

>>548
さすがに405の原因については気づいてるだろ
あっちはミクチャ、インスタ、TickTokのようなもっとアクセスに厳しいサイトも取り扱ってるから大丈夫だと思いますね

2025/11/12(水) 20:29:47.60

ニコニコプレミアム会員（DL対象の配信、動画がより高画質になる）なので
ここで報告されてる以上の速度と容量、頻度で落としてるけど一回も規制された事無いわ
新配信はAWSである事を考慮しても速度と容量を基準にIPをターゲットとした規制では無いと思う
推測できるのは無料会員or非ログインを対象に同時セッション数での規制かな
有料会員でも同時セッション貼りすぎると強制ログアウトさせられるし
所謂botは当然無料会員か非ログインなのでこの規制方法は合理的

2025/11/13(木) 19:32:45.12

>>291
nnn-revo2012さん
今更だけどこれ保存版で残してくれてありがとう
おかげでstreamlink単体でも中断されずに同一アカウントで録画しながらブラウザ視聴もできた

2025/11/13(木) 20:17:18.65

いつのアプデでかしらんけどここ数週以内でブラウザ視聴で画面と音の停止が悪化したな
1Mbps回線の環境で384kbps設定で見るとかそれだけですぐ止まる
要するに4Gフル20Mbpsとかの贅沢な回線でないと理論上の帯域が十分余っていてもすぐ止まるようになった

動画が一瞬でも途切れた後に「放送位置を修正して再生し直す」という動作が効いてないレベル同然になったようだ
無論生配信サイトでこれが正常に機能しないのは論外もいいところ

2025/11/14(金) 23:17:38.46

速度十分でも起こるし復帰しない
ラジオにしにくいから困るんだわ
「映像･音声が止まった際に押して下さい」が役に立たん

2025/11/15(土) 17:19:22.20

？

**nnn-revo2012** 警備員[Lv.0][新芽] · 2025/11/15(土) 18:38:44.36

>>552-553
ブラウザーなら設定→通信モードを安定性重視にすれば多少は安定するのでは
じゃなきゃ、コマンドプロンプトやPowerShellからStreamlinkやyt-dlpを起動してVLCやMPCを直接起動すれば？

例：
>streamlink --default-stream 450p https://live.nicovideo.jp/watch/lv349185615

**nnn-revo2012** 警備員[Lv.0][新芽] · 2025/11/19(水) 21:06:00.86

もう公開停止したlivedl-nですが、メッセージサーバー移行後のバージョンでコメント取得の際にueとshitaが指定されないバグがありました
あとフォント関係でDeFontがされないかもしれません

2025/11/21(金) 03:33:09.18

どうも405連発の人です。

また405、BOT判定が起こり今やっと解除されて、この一連のBOT判定、ツール使用全部不可IP制限(視聴だけできる)の全容がかなりわかってきました。

本日帰宅後すぐ寝てまして22時起床、チェック仮が19:30頃で通知止まってたので、ここでBOT判定が出たのだと推測されます。
23:20頃にそれに気付きBOT判定をブラウザで操作し解除、405解除(IPBAN解除)されたのは24:30か24:40頃です。

今回は405解除されたのは約1時間後、前回は5分後、初じめて405エラーに気付いて解除された時は約8時間後となります。
初回の時に偶然直ったLANケーブル抜き差しは、今回すぐに試してまったく効果なしでしたので、初回の時に8時間後の深夜にも再度405確認後すぐにLAN抜いてテザリングIPに変えた作業後に元のLANのIPに戻った時405解除されてたのは、偶然8時間後頃にIP制限解除されたと今の所そう解釈しています。
8時間は解除まで少し長すぎるような気がして、かなりの疑問な部分が残りますが、確実に5分と1時間で解除された2回の方は正確に確認していますので、制限解除時間は固定時間ではないようです。

2025/11/21(金) 03:33:46.92

長すぎてエラーが出たので続き

あと今回わかった部分は、BOT判定くらった時間は関係なく、ブラウザで操作解除してから時間経過後にIP制限解除されるようです。

あと、今回は11/20、0:00～19:30までの総転送量は深夜早朝に行った3配信600MBのみで、日中操作は何一つしていません、チェック仮の待ち受けのみです。
なので今の自分の考察では、チェック仮の処理だけでBOT判定になる可能性が高いです。
チェック仮常時起動＋短期間のツール呼び出し回数(転送量は一切関係ない)が多くなるほど更にBOT判定になりやすいと思われます。

チェック仮、最新版にしてからもうすでに3回も405エラーが出てるので、関係なくはないと思います。
＞サーバーの負荷軽減のためカテゴリページからの取得、放送中タブの表示、放送中の番組に色をつける機能を廃止。(2025/08/08)
＞番組表から取得する機能が正常に動作できなくなっていた不具合を修正、カテゴリページからの取得・放送中タブの表示・放送中の番組に色をつける機能を再度追加(2025/08/28)
ここあたりの修正で負荷関係で何やらあったみたいですし、ニコ生側も前より厳しくなっている流れだと推測できるので、チェック仮最新版の処理があると現状IP制限になりやすいんだと思います。

2025/11/21(金) 03:45:46.12

＞仰る通り、現在のところ、近くカテゴリーページやプッシュ通知も含めて動作できなくなることが考えられる状況であるかと考えております。

重要なこれが抜けておりました。やはりチェック仮のサーバー負荷が高いのが原因なんですかね？