Closed nnn-revo2012 closed 4 years ago
guest-nico
commented
4 years ago ご指摘をいただきありがとうございます。 プレイリストを取得後に時間を置いてからセグメントファイルを取得するということでしょうか？ 仰るとおり、プレイリストの取得後には時間を空けずにセグメントファイルを取得しておりました。 タイムシフトのプレイリストの取得の間隔につきましては、デバッグ版では5秒に一度の取得に なるように修正しておりました。 どの程度の時間を置くのが適切と考えられるでしょうか？
nnn-revo2012
commented
4 years ago このツールのプレイリスト→セグメントデーター読み込み処理って以下と考えてよろしいですか？
1.プレイリスト読み込み（読み込み間隔は固定） 2.リストの中の未取得のセグメントデーターを読み込み （ここでキューイングとか別プロセスに渡してます？） 3.5秒経ったら1に戻る
2.で読み込むセグメントデーター同士の間隔って取ってます？ここ間隔取らないとアクセス過多になる可能性があるんじゃないですか？というのが、僕の質問の意図です。 倍速ＴＳならプレイリスト読み込み10秒ぐらいにしてセグメントデーターを大体2.5秒ごとに取得とか。 ログを見ててそこのところがどうなのかなと思ったのでIssue立ててみました。
nnn-revo2012
commented
4 years ago すみません。自分の勘違いでした。 改めてブラウザー上でタイムシフトを開発ツールで解析してみましたが、プレイリストは５秒おきに取得してて、 プレイリスト中に未取得のセグメントデーターが複数あっても連続してノーウェイトで取得してるんですね。てっきりウェイト入ってるのかと勘違いしてました。 ドワンゴの仕様がそうなってるんであればアクセス過多の問題はないはずですね。 お騒がせして申し訳ありませんでした。
nnn-revo2012
commented
4 years ago たびたびすみません。1664さんの件と関係あるかわかりませんが 新配信録画ツール（仮ver0.87.85 debug+録画登録ツール（仮ver0.1.3.10.26 でユーザー生放送で3Mbのある放送を3Mbでダウンロードした時だけWebSocketが1～2分で切れて再接続する現象が起こってます。今のところ1664さんと同じ現象は発生しません。 同じ放送を2Mbでダウンロードすると問題なくダウンロードできます。 また、（仮ver0.87.84に戻すと3Mbでも問題なくダウンロードできます。 検証した放送 https://live.nicovideo.jp/watch/lv326107798
guest-nico
commented
4 years ago ご報告をいただきありがとうございます。アクセス頻度につきましてはコード上でも分かりにくく なってしまっており申し訳ありません。 デバッグ版につきましてはプレイリストの取得を5秒間隔にしておりましたが、倍速は有効の ままになっておりました。2.5秒に一つずつ新しいセグメントファイルが取得可能になる中で、 5秒間隔の取得では間に合わなくなり再接続が起こっていたりはしていないでしょうか？
デバッグ版3では倍速再生の録画が原因の可能性もあるかと思い修正してみました。 ただ、リアルタイム録画でも発生するとのことですので原因を掴めないでおります。
nnn-revo2012
commented
4 years ago （仮ver0.87.85 debug の時のログ２つを添付します。 自分でも解析してみたのですが、私の環境だと３MBのセグメントデーター読み込みは時間がかかるために間に合わなくなったり、ファイル書き込み中かロック中にリネームしようとしてエラーになってるみたいです。 ユーザーのネットワーク環境（回線速度や回線機器）、時間（混雑してる／しない）でもデーター読み込み時間は変わってくるわけで、結構やっかいそうです。 1664さんのログを解析すると見えてくるのではないかと思います。
guest-nico
commented
4 years ago 詳しいご報告をいただきありがとうございます。 ご指摘の通り、セグメントの読み込みで問題が起こっているようでした。 必要以上にプレイリストの更新の間隔が長くなりすぎるときがありましたので、 https://github.com/guest-nico/nicoNewStreamRecorderKakkoKari/commit/4dada8607cd0da83d47b0e21544e1e0e4e1ac2fd で修正してみました。 多少改善されるかもしれません。 お手数をおかけしてしまい大変申し訳ないところですが、 仰るとおり、詳しく状況が分かれば原因が分かるかもしれません。
nnn-revo2012
commented
4 years ago https://github.com/guest-nico/nicoNewStreamRecorderKakkoKari/commit/4dada8607cd0da83d47b0e21544e1e0e4e1ac2fd を手元のPCでReleaseでコンパイルしたものを 新配信録画ツール（仮C.exeとしておきます。releaseにある新配信録画ツール（仮ver0.87.85 debug3+録画登録ツール（仮ver0.1.3.10.26 として同じ番組を録画した結果
A 、C ・・・ 録画中のエラーなし B ・・・ 上のログと同じ。 ただし、Bでリアルタイム録画した場合はエラーなし でした。ログや設定などについて必要なら送ります。パソコンはデスクトップwindows10 64bit、書き出しているドライブ(D)は内蔵SATAのHDD(1TB)でパーティション切って容量80GB中30GB空いてます。 追記ですが、Bおよび0.87.85 debugも映像やコメントは正常に録画できています。ログやデバッグ用の通信ログを見てないと気付かないはずです。Bの時だけネットワーク負荷が高くなるようなこともしていません。
guest-nico
commented
4 years ago 詳しいご報告をいただきありがとうございます。 Aでは2倍速を無効にしておりました。そのため、ファイルの取得や書き込みのペースが緩やかになっており問題が起こらなくなっていたのではないかと思います。 また、Cについては読み込みの間隔が修正されたために改善されているのではないかと思います。 ログや設定の情報につきましては、十分に詳しい情報をいただいており修正することができたのではないかと思います。 お手数をおかけしてしまい申し訳ありません。ご協力をいただき感謝いたします。 ver0.87.86ではこちらの修正も反映いたしました。
nnn-revo2012
commented
4 years ago ver0.87.86の方で確認してみますので、こっちは閉じさせていただきます。
録画中にsegment(XXX.ts)を取得する際に待ち時間取ってますか？ 例えばＴＳでデーターを取得する場合、２倍速だと2.5秒に1回segmentを取り続けることになりますが、このプログラムの場合ウェイトなしでsegment取得してませんか？ウェイトがないんで結果的にplaylistも早いタイミング(4～7秒ぐらい?)で取得することになってます。 livedlはＴＳで倍速使うと結構サーバーに負荷をかける仕様だったんでlivedlを常用するアカウント(ＩＰ）はニコ生的にマークされててアクセス条件厳しいとかそれでかもしれません。
話を戻すと、segment取得後に適切なウェイトかける処理をつけてみたらどうでしょうか？ ユーザーネットワーク環境によってはセグメントが抜けるというクレームが殺到するかも？とは思いますが、それは個別に対応してくしかないと思います。