Question 1

KapowarrでGetComicsを検索する際のHTTP 403エラーの解決方法

Accepted Answer

GetComicsは、KapowarrのパスベースのページネーションURL（`/page/1?s=query`、`/page/2?s=query`）をHTTP 403で拒否する場合がありますが、ルートクエリURLはHTTP 200を返します。これはPR #394（V1.3.2以降）で、検索エンドポイントをサイトルートに切り替えることで修正されました。ページ1は`/?s=query`を使用し、後続のページは`/?s=query&paged=2`、`&paged=3`などを使用します。PR #394を含むビルドにKapowarrを更新するか、ソースから実行している場合は、`backend/implementations/indexer_clients/ddl/GetComics.py`を編集して、`s`および`paged`クエリパラメータを使用したルートURLを使うようにしてください。結果の解析、マッチング、リクエストのペーシング、RSS処理、レート制限は変更されていません。

Question 2

Kapowarr FlareSolverr の "Timeout after 60.0 seconds" エラー、GetComics の "No links found" エラー、および NoneType `.encode()` クラッシュを修正する方法

Accepted Answer

標準の `mrcas/kapowarr:latest` イメージでは、上流で issue #335 が修正されるまで、これらの障害に対してローカルパッチが必要になる場合があります:

1. **FlareSolverr のタイムアウトを延長する。** すべての FlareSolverr `request.get` ペイロードに `maxTimeout` を追加します。値はミリ秒単位です:
   ```python
   payload["maxTimeout"] = 300000  # 300秒
   ```
   また、HTTP クライアントが FlareSolverr の処理完了前に中断しないように、Kapowarr の FlareSolverr 向け HTTP タイムアウトも 300 秒より少し長い値(310〜320 秒など)に延長します。

2. **GetComics のコレクション/インデックスページを処理する。** マッチしたページが `No links found on webpage that match to volume and are not blocklisted` を返した場合、そのページ内にある GetComics 内部の記事リンクを探し、マッチしたボリューム/タイトルでフィルタリングして、諦める前にそれらの記事ページを再帰的に取得します。ネストされた記事ページに対して通常のホスターリンク抽出を実行します。ループを防ぐために再帰の上限を追加します。

3. **空の FlareSolverr レスポンスへの対策。** `.encode("utf-8")` を呼び出す前に、`None` または空のボディを壊れたリンクとして扱います:
   ```python
   body = fs_result.get("response")
   if not body:
       # この候補を失敗としてマークして続行
       continue
   response._body = body.encode("utf-8")
   ```

4. **壊れたホスターリンクをスキップして続行する。** null/空のボディやダウンロードの失敗では、その候補だけを拒否すべきであり、ダウンロードタスク全体をクラッシュさせてはいけません。

変更を適用した後、パッチを適用した Kapowarr イメージを再ビルドまたは実行し、コンテナを再起動します。例:
```bash
docker restart kapowarr flaresolverr
```
パッチ適用後のフローでは、GetComics ページの解決、ネストされた記事リンクの追跡、動作するホスターの選択、ダウンロード、インポート、ライブラリデータベースの更新が行えるようになります。

Question 3

GetComicsからの429レート制限エラーによりブロックリストに登録されたURLを修正する方法

Accepted Answer

大量の検索を短時間でトリガーしないようにしてください。これにより、429エラーが発生し、誤ってブロックリストに登録される可能性があります。回避策として、手動で検索を行うか、リクエスト間に遅延を入れてください。恒久的な修正（HTTP 429を実際の障害と区別し、レート制限エラーのブロックリストをスキップする）は、このissueで追跡されています。

Question 4

完了したダウンロードのインポート時にKapowarrで発生するSQLiteの'database is locked'エラーの修正方法（DELETE FROM download_queue）？

Accepted Answer

原因: Kapowarr V1.3.2において、`backend/features/download_queue.py`の`DownloadHandler.__prepare_downloads_for_queue()`は、挿入トランザクションを先にコミットせずにキュー行を挿入し、ダウンロードワーカーを開始します。複数のリリースを追加する際、ネットワークを伴うリンク準備がその書き込みトランザクションを開いたまま保持するため、別のダウンロードが完了して`DELETE FROM download_queue`を実行したとき、その行はまだロックされており、SQLiteが'database is locked'を送出します。回避策(ソースパッチ): キュー行の挿入直後、ダウンロードワーカーの準備・開始を行う前に明示的なコミットを追加し、新たに挿入されたキュー行が後続のネットワーク処理の開始前に他の接続から見えるようにします。報告者は、2つの接続を用いたWALモードの再現でこれをローカルに検証しました: 早期コミットがない場合、2番目の接続は行の削除に失敗しますが、コミットがある場合は成功し、その後の一括ダウンロードもロックエラーなしでインポートされました。注意事項: (1) これはissue #389向けのcommit 594defbでポストプロセッシングの各ステージ間に追加された明示的コミットを置き換えるものではなく、補完するものです。(2) プロジェクト既存のコミットヘルパーを使用してください。ただし、接続をコミットすると、その接続上の他の未確定の書き込みもすべてコミットされる点に注意してください。(3) データベースのタイムアウトを延長したりリトライを追加したりして問題を覆い隠さないでください。(4) 報告時点でこの修正はまだ上流にマージされていないため、適用前に最新の開発ブランチを確認してください。

Kapowarr

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト