huh, it does look like the content in my feed is delayed by about a week. that feed has tags like `<media:content url="https://www.youtube.com/v/2dQ4-VNaG3s?version=3" ...>`. that URL, like you said, isn't an audio file: it's a webpage which includes some json payload `var ytInitialPlayerResponse = ...`. within that payload is several `url` options, classified by quality. you can straight-up `curl` or `wget` those URLs, though they are IP locked.

i guess "reverse engineering Youtube's non-public player API" is that simple for the older videos in the feed? but the newer videos seem to be DRM-encumbered, so if the delayed feed bothers you, that's what yt-dlp is for, right?

FWIW i just gave my podcast client that feed URL and it worked exactly the same as any other RSS feed (except that the entries were delayed): i didn't know it was doing anything special behind the scenes. sure, it's non-standard, but that's not the only non-standard thing podcast apps already have to support. not everyone includes the right `<link rel="feed" ...>` tag on their website, yet for podcasts that do have their own website you can still paste their domain name and your app will magically figure out where the feed is.

gPodder's got an option to use yt-dlp instead of the above method, so i'll toggle that and see how well it works.