Question 1

PodFetchがUnraid/Docker上で、永続的な/app/dbボリュームではなく/appにSQLiteデータベースを作成してしまうのをどう修正すればよいですか？

Accepted Answer

PodFetch がマウントされたボリュームを使用するように、DATABASE_URL 環境変数を設定します:

DATABASE_URL=sqlite:///app/db/podcast.db

Unraid Community Apps で、この変数を PodFetch コンテナ設定に追加し、その後コンテナを再作成/適用します。

再作成する前に既存のデータベースを保持するには、実行中/停止中のコンテナからホストボリュームにデータベースファイルをコピーします:

docker cp PodFetch:/app/podcast.db /mnt/docker_pool/appdata/podfetch/db/podcast.db
docker cp PodFetch:/app/podcast.db-shm /mnt/docker_pool/appdata/podfetch/db/podcast.db-shm
docker cp PodFetch:/app/podcast.db-wal /mnt/docker_pool/appdata/podfetch/db/podcast.db-wal

それらのファイルが存在しない場合は、shm/wal のコピーを省略します。コンテナを再作成した後、/app/db に podcast.db が含まれていることを確認します。docker diff PodFetch は /app/podcast.db を新規作成されたファイルとして表示しなくなるはずです。Unraid テンプレートの問題は podfetch-unraid-config のコミット b8dcde23c8b653a4108dba2967fd7087ed259619 で修正されました。

Question 2

PodFetchがupdate_meta_data_mp3で「No such file or directory」panicを起こして同じエピソードを繰り返し再ダウンロードするのをどう修正すればよいですか？

Accepted Answer

これは、PodFetch v5.2.2 および現在の main で、podcast のカバー画像がすでにローカルに保存されている一方、エピソード MP3 に埋め込みアートワークがない場合に影響します。ダウンロードワーカーは、書き込まれなかったエピソードごとの画像を開こうとして panic し、そのため download_time が NULL のままになり、ポーリングのたびにエピソードが再ダウンロードされます。

当面の回避策: image_url がローカライズされた podcast についてリモート画像 URL を復元し、エピソードごとの画像を強制的に書き込ませます:

UPDATE podcasts
SET image_url = original_image_url
WHERE original_image_url LIKE 'http%'
  AND image_url NOT LIKE '%http%';

その後、エピソードのダウンロードを再びトリガーします。download_time が設定され、artwork/chapters が挿入されることを確認します。

コード修正: オプションの画像を致命的として扱わないでください。無条件の unwrap() を失敗可能な open に置き換えます。例えば:

if tag.pictures().count() == 0
    && let Ok(mut image_file) = File::open(&paths.image_filename)
{
    // image_file を埋め込む
}

あるいは、画像読み取り条件を、ファイル書き込み時に使用される条件と同一にします。また、メタデータ処理の前に download_time を記録することを検討してください。そうすれば、メタデータの失敗によって無限の再ダウンロードループが発生することはありません。メンテナーはこの問題を修正済みとして報告しています。可能であれば、修正を含むリリースにアップグレードしてください。

Question 3

Authelia との PodFetch OIDC invalid_grant と redirect_uri の不一致を修正する方法、特に内部ページを更新した後についてどうすればよいですか？

Accepted Answer

PodFetch を、2026-07-08 のイメージより新しい現在の latest/main ビルドにアップグレードしてください。この修正により、redirect_uri を window.location.href から導出することをやめ、認可リクエストとトークン交換の両方でサーバー設定の OIDC redirect URI を使用します。OIDC_REDIRECT_URI を、Authelia に登録されている正確なコールバック（たとえば https://podfetch.example.com/ui/）に設定してから、更新して再起動します: docker compose pull && docker compose up -d。すぐにアップグレードできない場合は、ui/src/main.tsx にパッチを適用して、コールバッククリーンアップ正規表現が scope、error、error_description も削除するようにしてください: redirectUri.replace(/[?&](code|state|iss|session_state|scope|error|error_description)=[^&]*/g, '')。恒久的な修正は、現在のブラウザ URL ではなく設定済みの固定 redirect URI を使用することです。これはまた、/ui/home/view などのルートでのリフレッシュが未登録の redirect_uri を送信するのを防ぎます。

Question 4

Docker 上の PodFetch のシステム情報ページで version と commit が欠落または空白になるのはなぜですか？

Accepted Answer

これは PodFetch Docker イメージ（samuel19982/podfetch:latest で報告、5.2.2 と推定）のバグで、バージョンとコミットデータが /ui/info で利用できなくなる原因でした。最新のイメージで修正されています。コンテナを更新するには docker pull samuel19982/podfetch:latest を実行してから、コンテナを再作成してください。Docker Compose を使用している場合は、docker compose pull && docker compose up -d を実行してください。更新後、システム情報ページをもう一度開き、バージョンとコミットが表示されることを確認してください。

Question 5

RSSクライアントでポッドキャストのエピソードがポッドキャスト名ではなく「Podfetch」と表示されるのをどう修正すればよいですか？

Accepted Answer

Podfetch の汎用統合フィードではなく、各ポッドキャスト番組の専用 RSS フィードエンドポイントを使用してください。Podfetch で番組を開き、その個別フィード URL（podcast ID で識別されるフィード）をコピーし、RSS クライアントでその URL を購読してください。汎用フィードは単一の RSS `Podfetch` を使用するため、クライアントはすべてのエピソードを「Podfetch」として表示します。RSS は 1 つのフィード内で複数の channel タイトルをサポートしておらず、author フィールドを変更するとタイトルが過度に長くなる可能性があります。この議論の時点では、集約フィードで個別のポッドキャスト名を表示させるための修正はありません。複数の番組別フィードを管理することが、サポートされている回避策です。

PodFetch

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト