第三次めでブロ

めでたいブログ
2023-03-04
ラジオ プログラミング

Google Podcastに自動反映されないときの暫定対応

5年近く活動を続けているPodcastのめでラジですが、今年に入ってからなんかシステムの調子が悪いです。

具体的には、エピソード更新後にGoogle Podcastのみ最新回が反映されないという現象が発生しています。

白状すると最近はエピソード公開後に自分であまり確認しておらず (Web上での反映確認のみ) 、リスナーの方にメールで教えていただいて初めて気付くことが多く情けない限りです。

99回続いたらベテランを自負してよいのではないか

待っていてもGoogleだけは一生反映されないみたいなので、ひとまず力ずくで何とかすることにしました。

更新の仕組み

事前知識として、Podcastは一般にPodcast配信サービスに音源やデータをアップロードするのではなく、外部サーバに公開されている情報を配信サービスが読みに来る仕組みです。

めでラジは私が借りているVPS上にサーバを建てて、番組Webサイトとともに公開しています。

  • 最近はAnchorのように音源をアップロードして各配信サービスに公開できるようなサービスも増えています

Podcastを公開する人は、配信サービスに対してRSS形式で情報を公開する必要があります。

RSSというと古のインターネットオタクの方が馴染み深いかもしれませんが、ブログやニュースを購読するときに使っていたアレです。

Google Podcastを除く各配信サービスは定期的にRSSを読みに来て、更新があれば最新エピソードとして公開するという流れとなります。

その際、基本的には音源はサービス側で取得せず配信元のサーバに読みに行かせるので、もしサーバが落ちていたりすると聴けなくなってしまいます。

  • なぜかSpotifyだけは音源を取得してるっぽい挙動をしています

私の知る限り巡回頻度は公に公開されているものではありませんが、自分のサーバで運用している方であればアクセスログから大体分かります。

Amazon Music PodcastやSpotifyはクローラーにより10分に1回程度のスパンで見に来ているようです。

Appleはなんか良く分かりませんでした。基本データや単体エピソードにもアクセスしているようなのでもしかしたら別な方法で確認しているかもしれません。

  • 上記スクショで何かに気づいた方がいるかもしれませんが少しばかりご内密にお願いします

本題に戻ると、Google Podcastはこの巡回にWebSub (旧名: PubSubHubbub)というフィード更新通知システムを使用しています。

このシステムが巡回してRSSの更新を検知すると、同じくこのWebSubを使用してRSSを購読しているサービス (RSSリーダー、SNS等) にも通知されるというハブのような役割で動作します。

このWebSubは、定期的な巡回ではなく配信元からのPUSH通知で更新を検知します。

簡単に言うと、Podcastのエピソード公開のタイミングでWebSubに対して「更新しました！！！」と通知を送ることで初めて読みに来るという仕組みとなります。

実はめでブロのPodcast配信システムは私の自作のスクリプトです。

元々上記のような仕組みを知らず特に何も通知を送る処理をしていませんでしたが今年に入るまでの4年余りの期間はちゃんと更新されていました。

もしかすると最近になってこの仕組みが厳密化された可能性もありそうです。

最初に更新が反映されなかったときに調べたところ上記を知り、慌てて公式サイトに記載されているコードを埋め込みました。

結果として状況が全く改善せず泣いています。今。

  • PHPであればこちらのサイトを参考にすれば一瞬で解決するので以下は蛇足です

手動で反映する方法

Google Podcastへと手動で反映するにはPubSubHubbub Hubからリクエストする必要があります。

ページ情報のPublishの欄にRSSフィードのURLを貼り付けてボタンを押すとリクエストが送信されます。

何を送っても画面は変わらないですが、内部的にはHTTPコード204が返っていれば成功扱いのようです。

リクエストを送った後でページ下方のPublisher Diagnosticsから確認することでクロール状況を確認することが出来ます。

巡回に来てくれた場合にはLast successful fetchおよびLast fetch errorがリクエスト送信時点の時間になっているはずです。

  • もし読まれているがエラーで更新されていないような場合にはLast fetch errorが記録されるのですぐに分かります

暫定の自動更新方法

つまり、上記のリクエストを自動で行えるようにすればすべて解決するのです！

・・・とだけ書くと仕様なんだからそりゃそうだろで終わる話ですが、将来的に現状埋め込んであるコードが奇跡的に動作するようになって全て解決する可能性や私のズボラでデータベースに直接更新をしてシステムが通知を飛ばせないことがあり得ることも考慮し、暫定的にWebサイトとは別処理で飛ばすことにしました。

具体的には、以下のようなコマンドをcronで定期的に実行するように設定しました。 

curl -X POST -d 'hub.mode=publish' -d 'hub.url=https://www.mede-radio.ch/feeds' -H 'Content-Type: application/x-www-form-urlencoded' https://pubsubhubbub.appspot.com/ -s

一応これはハックやクラックではなく合法で、PubSubHubbubの使用方法の記載に則っています。

特に大したことはしておらず、curlでPOSTを送っているだけです。

正式には更新があったタイミングで投げるべきリクエストなので高頻度で投げるべきではなさそうです。

本当は他サービスと同じく5～10分おきに巡回させたいところですが怒られたら嫌なので30分ごとに設定しています。

おまけ: 私のように自前システムでPodcast RSSを組んでいる方へ

多分この記事の需要は私と同じ「急にGoogle Podcastに配信されなくなった！」となっている人にあると思うので有益と思われる情報も載せておきます。

Apple Podcastが今年中にRSSの仕様変更をするようで、以下の更新が入るようです。

  1. 所有者、メールアドレスのタグの廃止 (スパムメール対策？)
  2. エピソードごとにグローバル一意識別子 (GUID) タグ設定の義務化 (これがヤバそう)
  3. ヘッダーの最終更新日情報の取得開始 (更新が無い時の通信量抑制？)
  4. Atomフィードのサポート終了 (これもヤバそうだけど流石に今もう誰も使ってない？)

GUIDとは、「128ビットの整数値からなる、データを一意に識別するために用いられる識別子のこと」です。 [引用元: GUIDとは 「グローバル一意識別子」 ジーユーアイディー, グーイド： - IT用語辞典バイナリ]

おそらくUUIDと同義と見なしてよく、XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXというフォーマットのIDの付与が必須となるようです。

ソースに”Will be required.”とあり、今年中かはともかく将来的にGUIDの無いPodcastは配信停止される可能性も無くはなさそうです。

システムやデータベースにより対応方法が変わってくると思いますが (私はMariaDBのUUID関数で何とかしました) 、過去のエピソードにも振る必要があるので早めに検討したほうが安全な気がします。

  • ラジオがやりたかっただけでサイト運営がしたかった訳じゃないんだがなぁ泣