不具合報告スレ - 1511245701 - したらば掲示板

1：作者★：2017/11/21(火) 15:28:21 ID:???: 不具合と思われた挙動をした時はこちらに書き込んでください。

報告用テンプレ
-----------------------------------------
Narou.rb のバージョン：

OS のバージョン：

その他環境情報（任意）：

何が起きたのか：

再現方法（何をやったら起こったのか詳細に）：

-----------------------------------------
エラーメッセージは再現方法に併記。
その際は --backtrace オプションをつけること。
748：名無しさん：2024/01/28(日) 12:21:49 ID:???: >>739
local_setting.yamlに書かれるタイプの設定が一番いいと思います。

小説個別の設定が標準だと確実に設定忘れが発生します。

あと表示を出す場合も挿絵取得時のような、どの小説を更新してるか判る形でないと手動更新時に面倒です。

変換負荷の大小で作品のUpdate頻度を変えてる人もいる上、Web UIの場合、表示履歴の削除 /api/clear_history をするとエラーで止まってしまう処理(挿絵取得後の[AozoraEpub3でEPUBに変換しています....]表示中等)も有るので…
749：名無しさん：2024/01/28(日) 14:38:57 ID:LuP0KNjs: >>745
一旦、その作品のデータを削除して（登録データとフォルダデータを削除）
再作成してみてはいかがですか
もしかしたら個別で作成するときには問題が出ず、一括で処理するときだけ問題が出る
ということも考えられますが、ものは試しです。
それと、ファイルの作成日時、更新日時は新しいですか
失礼ながら、古いプログラムで作った古いファイルが残っていただけ、
ということはありませんか
750：704：2024/01/28(日) 22:03:16 ID:???: なろうの方、5ページ以上取得の場合はプログレスバーをつけてみました。
github.com/rogenobl/narou/releases/download/p0.2/pagination.zip

>>748
これにあわせて最大ループ数はwebnovelの方で取得するようにしました。
全ページ数が取得できないサイトは今のところ固定値かなと。
ただ、その場合は今のプログレスバーは良くない気もしますが、そこは追々考えようと思ってます。
751：696：2024/01/29(月) 01:39:14 ID:BrX0xn36: >>699
古いバージョンの改造版AozoraEpub3で再設定できました。
異常なく動作するようになりました。
ありがとうございました。
752：名無しさん：2024/01/29(月) 02:03:20 ID:8E4gEG7E: 古いバージョンの改造版AozoraEpub3だと目次がこわれるみたいだけど
753：名無しさん：2024/01/29(月) 17:53:18 ID:tsAzfRoI: OS のバージョン：
Windows 10 Pro 21H2

その他環境情報（任意）：
Narou.rb Version 3.8.2

何が起きたのか：
なろうの話数が最大100話になってしまう。

再現方法（何をやったら起こったのか詳細に）：
カクヨムの話数0件Errorを掲示板の >>659 に合わせて修正した。
その後更新をかけたら100話以上のものが全て100話になる。
754：名無しさん：2024/01/29(月) 19:06:42 ID:???: >>753
>>690のあたりから読んでみると良いかと思います。
755：名無しさん：2024/01/29(月) 23:59:45 ID:Nr5DLans: >>752
古いバージョンだと極一部のカクヨム作品の目次ナビゲーションがおかしくなります
とはいえ本文は読めますから古いバージョンで間に合えばそれでいいと思います
756：714：2024/01/30(火) 07:57:53 ID:jIwiqLqA: 714です。
未だにnarou uコマンドが完了せず、途中で終了してしまっております。

100話に切り上げられてしまった作品の再ダウンロードが起こる訳ですが、
どうも不規則ながら通信エラーが頻繁に発生します。

C:/Tool/Ruby32-x64/lib/ruby/3.2.0/net/http.rb:1271:in `initialize': Failed to open TCP connection to ncode.syosetu.com:443 (Blocking operation timed out!) (IO::TimeoutError)
from C:/Tool/Ruby32-x64/lib/ruby/3.2.0/net/http.rb:1271:in `open'
from C:/Tool/Ruby32-x64/lib/ruby/3.2.0/net/http.rb:1271:in `block in connect'

・話数の多い作品の再ダウンロード時に、途中で発生する場合
　－＞数回試して駄目なら一時的にfreezeして後回しに
・どれかの作品のチェック中と思われる場合
　－＞ある作品のepub化終了後、次に作品に差し掛かったと思われるところで発生

このエラーが頻発するため、未だにnarou uコマンドが完了しません。
narou lコマンドからのパイプ処理など、いろいろ試していますが、回避方法、
原因究明ともに行き詰まっています。

他に同様の現象が発生している方はおられませんか？
また調査方法について、どなたか何かアドバイスいただけないでしょうか？
757：736：2024/01/30(火) 09:43:15 ID:???: >>756
なったことあるけど、waitを増やしたら改善したよ
デフォルトより3～4倍時間をかけてる
758：714：2024/01/30(火) 10:32:29 ID:jIwiqLqA: ＞＞757

今回のなろう100話対応が入るまでは生じなかった現象ですから、今回修正が
入った何かが影響しているのだろうとは思います。

waitを増やして改善したとのこと、情報ありがとうございます。
503エラーならwaiで対応するのでしょうが、tcpコネクションのエラーにも
waitは関係しているのでしょうか？
759：名無しさん：2024/01/30(火) 13:10:18 ID:???: >>758
今回から入った目次取得の時にWait処理が行われていないのでは?

目次取得も本文取得同様Wait必須なので…

ログを見るにアクセス過多でブロックされてる。
760：名無しさん：2024/01/30(火) 13:31:12 ID:???: >>750
目次取得も本文取得同様Wait必須な事を考えると1ページから表示出ないとダメでは?

Waitに必要な時間を考えると1ページ取得に最低2秒掛かるので…

あと一定回数以上連続アクセスでブロック(DoS攻撃対策)されてる事を考慮すると目次取得でも本文取得同様10回に1回2.5秒Waitも必要
761：753：2024/01/30(火) 14:28:05 ID:uzALkOI.: ＞754
ありがとうございました。
正常にダウンロード出来ました。
762：名無しさん：2024/01/30(火) 18:59:24 ID:???: >>756-759
実際の挙動を見てても目次取得でのWait処理はきちんと入ってるぽいけど
以前から数千話級の作品をDLしようとするとブロック・アク禁されがちだったから、そもそもデフォルトのWaitでは足りてないんじゃないかなという説
763：名無しさん：2024/01/30(火) 20:38:51 ID:iE/502/o: >>756
>>758

rogenoblさんの修正版を使用してみてください

> ある作品のepub化終了後、次に作品に差し掛かったと思われるところで発生

ということですが、もしかしたら目次取得のところで落ちているかも知れません。
そこの処理部には100話対応のため（既存のダウンロード処理が呼び出しにくかったので）私が自前でダウンロード処理を書いています。waitも入れてるけど他に問題がないともいいきれません。

ややこしいものを公開してしまって、すいません。
拙いものですが、これまでご利用ありがとうございました。

ちなみに rogenoblさん版は既存のダウンロード処理を使っています。私と違い、入力ではなく出力を結合してるので既存処理をそのまま利用できました。

それにしてもHTTPエラーならぬTCPエラーというのは何でしょうね？？
764：名無しさん：2024/01/30(火) 22:13:27 ID:iE/502/o: >>758
連続DLを繰り返すと503エラーだけではなく WEBサーバーの応答時間が遅くなる場合があります
そのとき TCP connection エラーが出るようです

>>760
5～6秒以内に11回アクセスをしたら規制がかかるようです
でも、30分に1000回もアク禁とか条件が複数あるかもしれません
連続DLを繰り返すと、もっと条件が厳しくなったりするかもしれません
765：751：2024/01/30(火) 23:01:40 ID:s5JIpX3s: >>752
カクヨムではなくハーメルンでの不具合でしたので大丈夫です
多分こっちのPC内での不具合だったんだと思います
766：704：2024/01/30(火) 23:26:31 ID:???: 元々の処理に加えてページ取得する前にウェイト入れたので、基本的には問題ないと思ってたけど、
元々の処理に微妙な部分があったので一応直した。
happynowさんに感謝。
github.com/rogenobl/narou/releases/download/p0.3/pagination.zip

>>756
>>763
まだ確認してないけど、rubyのバージョンでexceptionが変わったかもしれません。
本来スキップして次の更新に移るはずが、例外が拾えてない気がします。
767：名無しさん：2024/01/31(水) 02:07:54 ID:1KdvXbWo: blog.syosetu.com/article/view/article_id/4646/
外部サービスについては厳しく対応を行っております。
768：名無しさん：2024/01/31(水) 02:25:39 ID:Gj.E3/l6: 公式に聞く奴がおるか
769：714：2024/01/31(水) 03:17:37 ID:mV6EnoGo: ＞＞763

アドバイスに従い、rogenoblさんの修正版0.3＋sitesettinghandlerに入れ替えてみることに
しました。これからテストに入ります。

目次ページ取得中のプログレスバーはいいですね。
これで仮にエラーが発生しても、発生箇所の特定が容易になりそうです。

ひとつ気になったのは、なろうで更新済みのタイトルが、あらすじ変更と検出されるものが
多いこと。あらすじの検出に差が出る変更箇所があったのでしょうか？
770：714：2024/01/31(水) 03:23:34 ID:mV6EnoGo: >>769

あらすじ更新が検出されているのはカクヨムだったようです。
769の記述だとなろうサイトのあらすじだと言っていますが、誤りでした。
771：名無しさん：2024/01/31(水) 07:45:10 ID:ueKA8n9Y: >>766
お役に立てて何よりです
772：名無しさん：2024/01/31(水) 17:52:09 ID:???: >>766
sitesettinghandlerがPull Requestsに反映されてないからこのまま新Verが出たらまたカクヨム対応が面倒になるのでは?
773：704：2024/02/01(木) 00:13:31 ID:???: 度々ですが更新しました。
github.com/rogenobl/narou/releases/download/p0.4/pagination_with_fix.zip
github.com/rogenobl/narou/releases/download/v0.2/sitesettinghandler.zip
なろう対応の方は、IO::TimeoutErrorを、他のネットワーク関係のエラーと同様にスキップするようにしました。
カクヨム対応の方はコードの整理と、エラー発生時に無視せず中断するようにしました。
カクヨムの方はこの版の様子を見てからPull Requestsしたいと思います。
774：名無しさん：2024/02/01(木) 02:18:13 ID:L1.hmzoE: >>773
カクヨムの方はとても興味深い実装ですが Pull Request するなら、もう少し分かりやすく保守しやすいものに改良されてはどうでしょうか
利用者のことを考えて早めにパッケージ化されたいのであればフォークするのも手だと思います
775：名無しさん：2024/02/01(木) 03:00:52 ID:L1.hmzoE: >>773
すいません。それでも、かなりコード整理されたんですね。
あと kakuyomu2.jp.yaml でプログラムの中で一番最初に使われる可能性のある項目に -*code と書かなきゃいけないのが、設定仕様が実装依存な感じで少し扱いづらいと感じました。
例：
title: &title
- *code
subtitles:
- *code
codeの読み出しは明示的に実装したほうがわかりやすいと思います。
言うだけなら簡単なんですけど、たとえば、小説ごとに変換処理を書ける converter.rb のような形式とかどうでしょうか
776：名無しさん：2024/02/01(木) 08:02:01 ID:???: >>775
小説ごとだと仕様変更時にすべて置き換える必要があるのでは?

確実に置き替えミスが発生します。

個別書き換えだと完結済みの作品の物すら書き換える必要があるのでSSDやHDDに余計な負荷もかかりますし…
777：名無しさん：2024/02/01(木) 08:29:18 ID:???: >>776
kakuyomu2.jp.yaml を分かりやすく書きやすくするためには……の指摘だからそんな話してないと思うよ
778：769：2024/02/01(木) 19:16:08 ID:jq3FHzW6: 769です。
現在もnarou uコマンドのテスト中です。

何度かリトライして、それまで引っかかっていた4000話を超える作品の再ダウンロードが終わり
ました。

その時点で773でアップされた更新版に入れ替えました。
そこから再度narou uを走らせたのですが、約12時間経過してまだ処理中です（笑）。

これまでエラーで落ちていた箇所を超えたところ、新たに再ダウンロードになる
3000話、4000話越えの作品が出てきました（笑）。そのため処理は完了していないのですが、
途中で落ちていない点がこれまでとは違います。

なろう100話問題からのリカバリは思いの外、時間が掛かるようです。
779：名無しさん：2024/02/01(木) 20:01:55 ID:???: download.choices-of-digest-options で 2: 更新をキャンセルにしておけばまた同じことがあっても再ダウンロードを避けられる
また日頃からバックアップをとっていれば簡単に復元できる
780：704：2024/02/01(木) 20:15:21 ID:???: >>775
コードの外出しは当初にもあったので、requireするヘルパーメソッド的なものを実装しても良いかもしれませんね。ただ、

＞プログラムの中で一番最初に使われる可能性のある項目に -*code と書かなきゃいけないのが、設定仕様が実装依存な感じで少し扱いづらいと感じました。

元々のコンセプトが、情報を取り出す手段を正規表現マッチ以外にも増やしたいという所にあって、当初の構想はJSONそのものからとか、xpathやjquery的セレクタとかそういうバリエーションの提供だったんです。
端的に言えばrubyコードを書ける様にする予定で無かったけど、カクヨムのが思いの外単純で無くてad hoc的なものになってしまいました。

今のところ、設定ファイルの方は、他のサイトでも前処理が必要とかでなければ、ひとまずad hocで行きたいです。
いくつか実例が出来たならばAPI（Class I/F）的なところを詰めて汎用化にもっていけばいいかなと。

現状、悩みどころなのは、設定ファイルの方よりコードの方が拡張性を意識してるんだけど、今回は現機能に絞ってコンパクトにしようかどうしようかと言う所。無駄に風呂敷を広げてる気がしなくもない。
今後は機能拡張より、細かいバグ潰しとAozoraEpub3周りの整理が優先ではないかと思ったりはしてるので、いつになるか分からない拡張機能はとりあえずいらないんじゃないかなと思い始めてる。
781：名無しさん：2024/02/01(木) 23:21:47 ID:L1.hmzoE: >>780
回答ありがとうございます
・どう動くか分かりづらいコードは、どう直せばいいかも分かりづらい
・テクニカルなコードは保守上のネックになりかねない
・公式のコードは長く保守し続けから、わかりやすいものがよい
・一度、公式に取り込んでリリースしてしまうとなかなか直しづらい
そんな考えで提案させて頂きました。

それと kakuyomu.jp.yaml と kakuyomu2.jp.yaml は２つに分ける必要があるんですか
（Pull Requestするとき、ひとつにするのでしょうか？）

> AozoraEpub3周りの整理
ほんとそれ、という感じです。

>>776
少し分かりづらい書き方でした（人に分かりやすくと言っておきながら私の書きようは分かりづらい）
「小説ごとに」というのは converter.rb の説明であって、カクヨム対応をそうせよというわけではありません。
converter.rb は loadconverter.rb というプログラムのなかで次のように読み出しと実行がしっかり書いてあるんです。

converter_path = File.join(archive_path, "converter.rb")
...
eval(File.read(converter_path, mode: "r:BOM|UTF-8"), binding, converter_path)

でも kakuyomu2.jp.yaml の code はRubyコードなのに、読み出して実行するコードがそれと分るように書かれていないんです。
だから converter.rb を実行するように分かりやすく書いたらどうかという提案でした。
でも sitesettinghandler がどう動いているのか解析するのはなかなか楽しいですよ
782：名無しさん：2024/02/02(金) 01:43:48 ID:???: >>781
ここは不具合報告スレなのであまりにも専門的すぎることはGitHubのIssuesに書いた方がいいです。
ここには、RubyやJavaに詳しくない人も来るので…
783：名無しさん：2024/02/02(金) 04:04:38 ID:3tKk8pzM: Narou.rb のバージョン：3.8.2(rogenoblさんのsitesettinghandlerV2+PaginationV4適用)

OS のバージョン：Windows 10

その他環境情報（任意）：ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mingw-ucrt]

何が起きたのか：n5521cs リバース・スラスターズ変換時にフリーズ。
AozoraEpub3に渡す前の、前処理変換の段階でフリーズしているようです。
34%、99％など途中で固まってしまいます。
削除→再DL、挿絵無効化などしましたが変わりません。
他の作品は正常に利用できています。

再現方法（何をやったら起こったのか詳細に）：narou d n5521cs
エラーメッセージは表示されません。
784：781：2024/02/02(金) 06:23:58 ID:6XI/JUaM: >>782
確かにそうです。申し訳ありません
785：778：2024/02/02(金) 15:46:54 ID:3TJbmKfA: >>778　です。
現在は以下の修正版をテストしています。
github.com/rogenobl/narou/releases/download/p0.4/pagination_with_fix.zip
github.com/rogenobl/narou/releases/download/v0.2/sitesettinghandler.zip

1月下旬のなろう目次ページ改変以降、さきほどようやく初めてnarou uコマンドが
正常終了しました。これであとは通常更新が続けられれば問題なしと言えそうです。

ただ処理時間はかなり延びたような気がします。これから様子を見ますが、今回は
通常の2～3倍の時間が掛かったようです。凍結対象とする閾値を上げなくてはならない
ようです。

>>779
download.choices-of-digest-optionsは「4,1」を使用しています。
通常は2にしてしまうと、その後の更新はしなくなるように思うのですが、どうでしょうか。

実際にはダウンロード済みの各話データはあるので、更新情報だけ手動で書き換えて、
再ダウンロードしないようにすればいいのでしょうか。その場合は、小説データフォルダの
どこかのファイルをいじるのだろうと予想されますが、簡単に行えるものでしょうか？
786：名無しさん：2024/02/02(金) 16:14:57 ID:???: カクヨムの仕様変更のときに変更したファイルをオリジナルに戻した上で、
rogenoblさんのsitesettinghandlerV2とPaginationV4を入れてみたのですが、
「AozoraEpub3でEPUBに変換しています.」の段で

ERROR ArgumentError: invalid byte sequence in UTF-8\n\tC:/Ruby32-x64/lib/ruby/gems/3.2.0/gems/narou-3.8.2/lib/novelconverter.rb:315:in `convert_txt_to_ebook_file'

のエラーが出て処理が停止してしまいます。
これはどうすればよいでしょうか・・・？
787：786：2024/02/02(金) 16:51:30 ID:???: すみません、解決しました。
OpenJDK 21を使っているので、novelconverter.rbに
github.com/whiteleaf7/narou/issues/399#issuecomment-1875320540
の修正が必要であることを忘れていました。
788：名無しさん：2024/02/02(金) 17:37:21 ID:???: >>785
>通常は2にしてしまうと、その後の更新はしなくなるように思うのですが、どうでしょうか。
現在の話数より増加すれば更新再開されると思います
完結・エタな作品での改稿で、話数が減ってその後増えないと更新されないのはデメリットですね
789：名無しさん：2024/02/02(金) 19:45:40 ID:/wo5ac0A: >>785
>download.choices-of-digest-optionsは「4,1」を使用しています。
それならば、その時にできたバックアップで小説フォルダの全ファイルを上書きすればよいのでは。
790：704：2024/02/02(金) 21:27:07 ID:???: >>783
今日はもう追えないけど、とりあえず分かった部分だけ。
挿絵が大量にあります。機械的に数えたので間違いもあるかもしれないけど、2700程ありそうな気がします。
34%の時点で大量にDLしはじめました。
たしか挿絵無効にしてもDLだけはしたような気がします。
791：名無しさん：2024/02/02(金) 21:54:10 ID:6XI/JUaM: >>783
>>790
暫定対処ですが私は下記の方法を取ることで書籍化できました

(1)「\小説データ\小説家になろう\n5521cs リバース・スラスターズ」フォルダのなかの
converter.rb をテキストエディタで開いて、
7行目と8行目の間に io.string.gsub!(/［＃挿絵（.+?）入る］/, "") を追加します（下記参照）

（修正前）
# 各種変換処理がされる「前」の生データに対しての変換処理を記述
def before(io, text_type)
super
io
end

（修正後）
# 各種変換処理がされる「前」の生データに対しての変換処理を記述
def before(io, text_type)
super
io.string.gsub!(/［＃挿絵（.+?）入る］/, "")
io
end

※ /［＃挿絵（.+?）入る］/ は　/ . + ?　の４文字以外は全角です

(2) 作品データのダウンロードが済んでいそうなら narou c n5521cs コマンドを使って変換します

中途半端で申し訳ありませんが、私の調査はここまでにします
792：名無しさん：2024/02/03(土) 00:50:57 ID:ZZiUbFXQ: >>790 >>791
>>783 です。調査していただきありがとうございました。

小説は、791さんの方法ですぐに変換することができました。
converter.rb を直接編集して挿絵を無効化する方法は知らなかったです。

その後もう一度 narou c n5521cs してみたところ、2時間以上かかって完了しました。
ご推察のとおり、大量の挿絵が原因みたいでした。
convert中は%の進捗がなくても、挿絵フォルダに画像ファイルが増えていたので、
単純に挿絵のDLに時間がかかっていたみたいです。

変換時に挿絵をDLしているのも知らなかったのです。
791さんの方法だと挿絵DLを回避できるみたいです。

この度は不具合だと思い込んでしまいお手数おかけしました。
重ねて感謝いたします。
793：704：2024/02/03(土) 18:57:46 ID:???: >>792
ちょっと挿絵の数が想定外だし、プログレスバーが実態に即していないのは、よくあることではあるんですが、
不具合でないかと言えばそうでも無いし、良い気付きにもなりました。
できればファイルのDLは分離して、こちらはこちらでプログレスバーでも付けれると良い気がします。
794：名無しさん：2024/02/03(土) 20:23:28 ID:98RdJxvQ: >>792
>>793
少し話は変わりますが補足させてください

挿絵を挿入しないなら、画像ダウンロードは必要なさそうですが、そうとも言い切れません。
挿絵機能を無効化していても画像をダウンロードしておけば、
作品がサイトから削除された後でも、挿絵機能を有効化して挿絵を挿入することが出来ます。

あと気になったのは
・サイト側で画像ファイルが差し替えられることはないか、narou.rbは毎回ダウンロードしているのか
・画像ファイルをダウンロードするのにウェイト（待機）が掛かっていなさそう？
という点です
795：704：2024/02/03(土) 22:29:19 ID:???: >>794
＞・サイト側で画像ファイルが差し替えられることはないか、narou.rbは毎回ダウンロードしているのか
挿絵フォルダに画像ファイルが存在すればダウンロードせず、差し替え等のチェックもしてないようです。
ただ、小説家になろうで通常つかわれるみてみんは、軽くググってみたところでは画像の差し替えが出来ないようです。
しかし、pixivとか他のサイトなら差し替え出来るかもしれないし、何かよい手段があると良いですね。

＞・画像ファイルをダウンロードするのにウェイト（待機）が掛かっていなさそう？
かかってないと思いますが、かける必要性は低いと思います。
１ページに何枚も画像がある場合でも、普通のブラウザはウェイトは入れませんし、いくつか平行してのアクセスすらします。
システムとしても、普通のページと違って、画像はそれを前提とした設計がなされますし、なされてきました。
そして挿絵は普通そんなに多くあるものでもありません。
796：名無しさん：2024/02/04(日) 01:23:23 ID:D8GO8xqc: >>795
わざわざ調べて下さってありがとうございました。お陰で理解できました。
それと回答を読んで気がついたのですが、画像の連続DLに規制を書けてしまうと、
数々の作品が一度に表示される検索画面など、みてみんサイト自体の閲覧に問題が出ますね
797：名無しさん：2024/02/13(火) 02:25:59 ID:???: narou.gemspec

44行目のgem.required_ruby_versionが

gem.required_ruby_version = ">=2.3.0"

のままになっている。

依存関係に有るランタイムの仕様上Ruby 2.3だと動かない

activesupportが>=2.7.0、sinatora >=2.7.8 なので…

rubyzipも>=2.4
798：名無しさん：2024/03/07(木) 15:28:15 ID:???: なろう、ノクターンともに更新をかけると403になって目次が取得できなくなってますね
799：名無しさん：2024/03/07(木) 15:34:27 ID:FKjmkJNs: 昼まではできたのですが、今はだめですね。
ip制限とかでもなさそうなんですが。
800：名無しさん：2024/03/07(木) 16:14:19 ID:???: うちは大丈夫
801：名無しさん：2024/03/07(木) 16:30:59 ID:OpjrYjao: ウチも午後駄目ですね。
リンクのボタンからはページは開き、PDFダウンロード等もできるのですが。更新は403ですねぇ。
802：名無しさん：2024/03/07(木) 18:01:10 ID:???: User-Agentをいろいろ試してみたところ、”Ruby” が入っていると 403 Forbidden が返されました。
ちなみにブラウザじゃなくてもcurlとfetchはいけましたが、wgetはダメでした。
海賊版サイト対策ですかねぇ。

APIを使った更新確認ではエラーが出ないので、目次や本文のダウンロード時にUA偽装が必要になった模様です。
803：名無しさん：2024/03/07(木) 18:42:24 ID:???: 古いUAだと弾かれることもあるので、narou s で任意のUAに設定できるのが望ましそうです
804：名無しさん：2024/03/07(木) 18:44:53 ID:???: >>802

↓の影響では?

ttps://jbbs.shitaraba.net/bbs/read.cgi/computer/44668/1534840592/13
805：名無しさん：2024/03/07(木) 18:54:45 ID:???: >>804
その発表は目次ページネーションのときのものですが、まあ厳しくしていくのでしょうね
806：名無しさん：2024/03/07(木) 20:16:00 ID:kIiTkixY: 今日からなろうが更新403でできなくなりました。
試しにカクヨムだとダウンロードできたので、やはり、なろうの方の変更なんですね。
厳しくされていくのはわかりますが、ショックですね。
807：名無しさん：2024/03/07(木) 20:39:13 ID:???: ひとまず3カ所ほど、open_uri_optionsのCookieの前に
"User-Agent" => "ブラウザのUA",
って具合に追記して更新出来た
808：名無しさん：2024/03/07(木) 22:06:35 ID:aqGHsssQ: 自分もnovelinfo.rbとdownloader.rbのopen_uri_optionsに
>>807さんの修正を加えたらひとまずうまくいきました。ありがとうございます。
809：名無しさん：2024/03/07(木) 22:48:07 ID:XvEhg4Sk: 私も807さんと808さんのおかげでなろうを更新できるようになりました
ありがとうございます

後進のために自分が行った簡単な手順を書くと

1.自分のブラウザのUAを調べる
win11の現在のchromeでは
'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36'

2.novelinfo.rbとdownloader.rbを書き換える
自分の場合
C:\Ruby32-x64\lib\ruby\gems\3.2.0\gems\narou-3.8.2\lib
にありました
各ファイルをメモ帳で開きopen_uri_optionsで検索し、その直後の"Cookie"の前に"User-Agent" => "'Mozilla/5.0(略）'",
を書き加えればok

バックアックをとってから書き換えた方が良いと思います
810：名無しさん：2024/03/07(木) 23:06:49 ID:???: UA偽装できました。
UAは正式なモノでなくても、面倒なので"Chrome"と適当な文字列でも更新出来るようです。
811：名無しさん：2024/03/07(木) 23:13:04 ID:???: extension.rb の make_open_uri_options で add.merge するといい
812：名無しさん：2024/03/07(木) 23:32:29 ID:2BWKaZG2: こんな感じ？
```
def make_open_uri_options(add)
ua = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36'
add.merge(ssl_verify_mode: OpenSSL::SSL::VERIFY_NONE)
add.merge("User-Agent" => ua)
end

```
813：名無しさん：2024/03/08(金) 01:07:32 ID:8z8E2d16: >>812

add.mergeする方法でダウンロード再開できました。
UserAgentの問題だ、と切り分けて下さった方、対処方法について情報提供してくださった
方々に感謝いたします。
814：名無しさん：2024/03/08(金) 09:04:08 ID:tZzCSEsE: >>812
これだと一箇所だけ変更で済むんですね
皆さん詳しくていつも大変お世話になっております
ありがとうございます
815：名無しさん：2024/03/08(金) 10:04:06 ID:94QNEzKM: >>812
動きました
THX
816：名無しさん：2024/03/08(金) 11:07:37 ID:I4qzqTbo: 感謝です読み取れ出しました！！
817：名無しさん：2024/03/08(金) 13:22:36 ID:E9uTTjKE: >>812
WindowsでもUbuntuでも動作確認できました、ありがとうございます。
uaはフルじゃなくても'Mozilla/5.0 (Windows NT 10.0; Win64; x64)'ぐらいの簡略でも動作しているのですが
いずれもうちょっと厳しくなるのかって点が怖い感じです
818：名無しさん：2024/03/08(金) 13:55:56 ID:???: UA古いと弾かれるみたいだしファイルの直接書き換えではなくてオプションでUAを自由に変えられた方がいいな
主要ブラウザのEdgeもChromeもFirefoxもオープンソースで更新頻度が非常に多いから最新版のUAもすぐ古くなる。
819：名無しさん：2024/03/08(金) 14:33:26 ID:???: 今はUAのみだがそのうち本文の方はRefererも必要になるかもしれないな
820：名無しさん：2024/03/08(金) 15:44:12 ID:???: 行き着く先はノベルピア
821：名無しさん：2024/03/08(金) 18:10:53 ID:???: command/setting.rbの537行目あたりにUA設定を追加して
"user-agent" => {
type: :string, help: "User-Agent 設定\n未指定時 Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
tab: :detail
},

extension.rbの9行目に
require_relative "inventory"
追加してinventory読ませて

def make_open_uri_options(add)
ua = Inventory.load("local_setting")["user-agent"] || "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
add.merge(ssl_verify_mode: OpenSSL::SSL::VERIFY_NONE)
add.merge("User-Agent" => ua)
end

Cookie前の3カ所直書きはやめてadd.mergeの方で
UA設定は詳細タブの一番下
問題ないかな？
822：名無しさん：2024/03/08(金) 20:51:48 ID:XpjDUOT.: できたよ～。（涙）ありがとうございます。（なんかだんだん難しくなっている）
一時はどうなることかと思っていました。掲示板の皆様に感謝します。

私の場合、
１．ファイル：extension.rb
２．場所：C:\Users\ユーザ名\.gem\ruby\3.2.0\gems\narou-3.8.2\lib

３．変更前：
# open-uri に渡すオプションを生成（必要に応じて extensions/*.rb でオーバーライドする）
def make_open_uri_options(add)
add.merge(ssl_verify_mode: OpenSSL::SSL::VERIFY_NONE)
end

４．変更後：
# open-uri に渡すオプションを生成（必要に応じて extensions/*.rb でオーバーライドする）
def make_open_uri_options(add)
# add.merge(ssl_verify_mode: OpenSSL::SSL::VERIFY_NONE)
ua = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36'
add.merge(ssl_verify_mode: OpenSSL::SSL::VERIFY_NONE)
add.merge("User-Agent" => ua)
end
823：名無しさん：2024/03/08(金) 23:02:49 ID:???: 教えてください。
変換後の小説のタイトルに日付を付加したいです。

default.enable_add_date_to_title 「はい」
default.title_date_align 「タイトルの後」
default.title_date_target 「変換した日」
と入力した後、例えば年を追加しようと
default.title_date_formatに「$Y」、「%Y」、「$%Y」等といくつか試しましたが、何も追加されませんでした。
書き方を間違えていると思うのですが、どういう書式で書けばいいのでしょうか？
824：名無しさん：2024/03/08(金) 23:33:48 ID:???: すみません。タイトルとファイル名を勘違いしてました。
825：名無しさん：2024/03/08(金) 23:44:12 ID:???: UA偽装は本家マージ必須だからバグ無いならとっととプルリクした方がいいな。
カクヨム対応やPaginationのマージすらまだ作者待ちだし…
826：名無しさん：2024/03/09(土) 09:55:28 ID:Clpg/hnw: 感謝です。読み取りできました。
811さんも812さんも、本当にありがとうございました。
掲示板の皆様のお知恵が本当にありがたいです。
extention.rbだと一か所で対応できるのですね。詳しくご自身の書き換えを搔いていただいた皆様もありがとうございました。
827：名無しさん：2024/03/09(土) 13:48:06 ID:XGmEzMo.: >>823
なんとなくですがバグっぽい。
def add_date_to_title(title)の処理で指定した設定で例として「_%Y%m%d」としてみたがこの関数の戻り値は反映されている。
なのでこの後の処理でtxtのファイル名を引き継いでいるような感じに見える。
あとは多分enable_add_end_to_titleの設定も反映されてない。
828：名無しさん：2024/03/09(土) 17:30:15 ID:nbi9wj7o: 目次取得エラーを修正しても全件ダウンロードできず100件までしか取得できないんだけどおま感？
ログは下記のような感じです。
-> % narou download n2377fh
ID:1227　最強出涸らし皇子の暗躍帝位争い～帝位に興味ないですが、死ぬのは嫌なので弟を皇帝にしようと思
います～のDL開始
第1部分　プロローグ　二人の始まり (1/100)
829：名無しさん：2024/03/09(土) 17:32:30 ID:nbi9wj7o: 自己解決。
PR出てたのですね…。
ttps://github.com/whiteleaf7/narou/pull/413