Oscar Merry

Building Fountain - https://www.fountain.fm

Fountain: https://www.fountain.fm

Public Key

npub1cwmsktup8ewdwx8l92u2lw992r4sg3agq9g0zdwwzxqx5dfj9w8s3zwcs6

NIP-05 Address

merryoscar_at_podcastindex.social@momostr.pink

Profile Code

nprofile1qqsv8dct97qnuhxhrrlj4w90hzj4p6cyg75qz583xh8prqr2x5ezhrcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds6hacq8

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1cwmsktup8ewdwx8l92u2lw992r4sg3agq9g0zdwwzxqx5dfj9w8s3zwcs6

Show more details

Last Notes

2026-07-06 08:25:52 UTC

Is there any reason that still exists today for RSS feeds to have both the <description> and <content:encoded> tags at the item level?
From my experience there is never any difference between the content in these tags.
Does anyone know of apps / services that have a specific use case for different content in each tag?

2026-05-19 13:32:06 UTC

@npub1e88…nva7
Do you have a sense of how many music feeds there are without a corresponding artist publisher feed?
I am working on re-doing some of our music indexing logic and excluding music feeds without publisher remote items would make things much simpler.
From my perspective having an album feed without a publisher feed doesn't really make sense but maybe I'm excluding a lot of music?

2026-05-17 13:47:34 UTC

- reply

the latest spec is merged and is documented here - https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/examples/value/metadata.md

2026-05-14 13:49:40 UTC

- reply

Great thanks Dave! 🙌

2026-05-14 13:48:07 UTC

- reply

aah wait nvm they are there in search results now - https://podcastindex.org/search?q=the%20paisley%20daze
probably just a delay in adding back into search

2026-05-14 13:46:26 UTC

- reply

I just checked the other Paisley Daze feeds in the podcastindex admin dashboard and it looks like for some reason they were marked as "Spam: AI Slop"
I've marked them as legit so they are assessable now:
https://podcastindex.org/podcast/7842989
https://podcastindex.org/podcast/7840216
But they are not displaying in search - https://podcastindex.org/search?q=the%20paisley%20daze
@npub1rcn…dw4h does marking a feed as legit put it back in the search index?

2026-05-11 10:55:45 UTC

- reply

unfortunately we had to remove these reverse show lookups from podcastindex ids because we were getting spammed by crawlers
here's the actual fountain show link - https://fountain.fm/show/bWP7QSMhtM4HDwoE6V2R
I will be work on an api for these lookups - should be available soon

2026-05-05 21:50:54 UTC

- reply

Great! I've deployed the change now so it should work on all app versions.
Sorry about the issue and let me know if there's any other area you think we could improve.

2026-05-05 11:58:45 UTC

- reply

Yep here you go thanks Dave - https://feeds.fountain.fm/fFN6zIBq9v4cUOT8c5rB

2026-05-05 11:40:57 UTC

- reply

ok thanks for the additional info - I will test with Android on that episode.
We are unfortunately a bit behind on Android releases as Google Play Store review has been massively delayed recently - but we're pushing to get a new version out this week and I'll double check value time splits in this version. Will follow up.

2026-05-05 11:36:24 UTC

- reply

I can't see anything wrong with the feed.
@npub1rcn…dw4h any idea what might be causing this feed to fail in the index?

2026-05-05 11:14:57 UTC

- reply

I just tested on 1.5.1 which is the live iOS version and value time splits worked for me
I'll continue to investigate this today - did you experience this issue on iOS or Android?

2026-04-30 19:22:39 UTC

We are LIVE - https://fountain.fm/live/k5BOxyi9isDVDWKtyAM7

2026-04-27 17:35:11 UTC

Fountain 1.5 is now live with a brand new trending feed showcasing which episodes your network find valuable.
The new trending feed combines different signals to rank notes including boost value, reactions, and recency.
We’ve also re-written the backend so feed queries along with comments, threads, and profiles now load faster.
I’d love to hear your feedback on the new trending feed - especially if you think we could give more weight to certain things.
https://fountain.fm/blog/fountain-15---revamped-trending-feed

2026-04-21 10:30:55 UTC

Hi All,
Fountain is hosting a live event next Thursday April 30th in London showcasing how Open RSS can support music hosting, music podcasts, and payment splitting for the currently playing artist.
You can sign up to be notified when the stream goes live here - https://fountain.fm/live
And if you're in London can grab a ticket here - https://luma.com/ysna282n
Please share with anyone you think might be interested and hopefully you can join for the livestream! :)

2026-04-20 09:02:21 UTC

- reply

episode from 18th April is there now

2026-04-17 10:40:36 UTC

- reply

can you send me the transaction reference id and I'll take a look

2026-04-16 21:35:06 UTC

- reply

unfortunately it looks like some kind of bot requesting as many individual show / episode pages as it can - still need to dig through the data to find out more but we've deployed some additional protections so that traffic should drop now from our api key - let me know if you don't see it drop.

2026-04-16 20:41:56 UTC

- reply

I've removed this from our server now so you shouldn't see any more requests from us to that endpoint.
It had been there in our code unchanged for a few years now - but for some reason in the last 48 hours the load on our endpoints has massively increased almost 10x so that's definitely the cause - I'm trying to figure out why this happened. Will follow up once I know more on why.
Sorry for the disruption!

2026-04-16 20:25:46 UTC

- reply

checking this now on our side

2026-04-16 17:24:28 UTC

- reply

thanks so much Dave really appreciate it - let me know if there's anything I can do to help like finding more examples of feeds that haven't updated

2026-04-16 17:12:38 UTC

@npub1rcn…dw4h have you noticed any issues with the index over the past few days - have had a few reports of feeds not updating.
A couple of examples:
https://podcastindex.org/podcast/869672
https://podcastindex.org/podcast/1000839

2026-03-17 12:40:39 UTC

All lightning payments on Fountain will be temporarily down between 13:00 - 17:00 UTC today while we perform some maintenance work.
Apologies for any disruption. We will let you know when the work has been completed.
https://x.com/fountain_app/status/2033876690363928903

2026-03-14 10:35:36 UTC

- reply

I believe this is an issue with livestream streaming sats not passing in the guids to the keysend TLV - I will fix and get back to you here when resolved.

2026-03-04 19:05:24 UTC

- reply

great thanks!

2026-03-04 16:45:39 UTC

- reply

no we don't

2026-03-04 15:42:45 UTC

@npub1rcn…dw4h quick question on the API - this feed displays only 4 episodes - https://podcastindex.org/podcast/310504
But the API returns many more - which I think are old ones that are no longer in the feed.
Is there some hidden 'deleted' field that you have in the database but not returned in the API response - if so would it be possible to add this to the API response? (/episodes/byfeedid)

2026-02-27 12:56:46 UTC

- reply

can you please share the link for the show / episode you are seeing this error with?

2026-02-24 21:32:04 UTC

- reply

yeah something like this could definitely work - the only downside is that for people self-hosting they would have to host the service that does this
for example - if you self-host your feed and use Strike to receive boosts and streams - this wouldn't work
my thinking with the current rss::payment spec was that even though it's a bit more of a lift for apps - it works with any wallet

2026-02-24 21:23:16 UTC

- reply

we could - there's just the question of how to avoid fake data if anyone can post payment metadata to a public API endpoint
with the rss::payment spec the url to fetch the metadata originates in the payment comment - so there is a direct tie to the actual payment and since apps host the full metadata on a url their reputation is at stake if they fake data
I am open to exploring solutions to this where apps don't have to host the payment urls - and promise I won't mention nostr 😅

2026-02-24 21:19:06 UTC

- reply

yep exactly! let me know if I can help with anything else and good luck with the re-write!

2026-02-24 21:17:40 UTC

- reply

yep - we fetch it from the 'x-rss-payment' header that is returned in the URL - https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/examples/value/metadata.md#implementation

2026-02-24 21:16:24 UTC

- reply

I would ignore the "method" attribute on the value block and use the "type" attribute on each value recipient - as there could be multiple recipients with both type="lnaddress" and type="node" (keysend)

2026-02-24 21:13:24 UTC

- reply

If an app implements the rss::payment metadata spec like Fountain and Castamatic do it works:
https://podcastindex.social/@merryoscar/116120033419028522

2026-02-24 21:08:21 UTC

- reply

Personally I would rather trust metadata hosted by an app than metadata sent to an open API in the feed - but happy to look at any proposals people have and try and work together to solve this for apps that don't want to host payment metadata.

2026-02-24 21:07:50 UTC

- reply

Fountain does this for our hosting customers - we accept payments from any app - either Keysend or Lightning Address - and aggregate payment stats and metadata in our dashboard - https://fountain.fm/podcasters
This is why I have been advocating for the rss::payment metadata spec because it's simple to implement and we can read the metadata from the x-rss-payment header and use this for our stats.

2026-02-24 19:18:14 UTC

- reply

Congrats Franco - great to see the NWC + BoostBox metadata integrations!
https://cdn.masto.host/podcastindexsocial/media_attachments/files/116/127/212/933/222/291/original/dbb588faf87beadb.jpg

2026-02-23 09:56:33 UTC

- reply

thank you! 🙏

2026-02-23 08:55:04 UTC

- reply

"Theoretically, though, this does mean that the same HLS feed should work if you were to put it into an alternateEnclosure for other podcast apps, and should also work just fine on Android or other devices. There’s nothing proprietary here - just a carefully constructed HLS master playlist. And that’s good news for all of us."
Great to hear!
At Fountain we have many podcasters publishing HLS video with every episode. @npub13cg…ck4q any thoughts on the best way to contact Apple?

2026-02-19 09:12:13 UTC

- reply

Totally agree James - this <metaBoost> spec has been around since 2024 and no-one has implemented it because it's overly complex.
The rss::payment metadata spec is simple and we have 2 apps that have implemented and 2 more that are working on it.
We need to all align on this if we want to re-energise open podcast payments.

2026-02-13 11:34:07 UTC

https://primal.net/e/nevent1qqs8zq3na8a3d3syp6v9mm27rjsmksqff3ru658njr9j8c9nnda78vq5w7t0h

2026-02-02 13:31:14 UTC

- reply

@npub10lz…tuwr I know it's probably annoying but would it be a massive amount of work for you guys to switch to the same spec Fountain and Castamatic are using?
https://github.com/Podcastindex-org/podcast-namespace/pull/734
I think we would really turn a corner if we could all align here!

2026-02-02 10:30:04 UTC

- reply

I've enabled CORS for these payment urls - let me know if that works for you

2026-01-11 11:24:35 UTC

- reply

aah yes you're right we were only submitting the album feeds not the publisher feed - I've done that now and it's all working - https://alpha.podverse.fm/artist/zp7I1ZDtz9

2026-01-09 15:19:34 UTC

- reply

also fyi @npub1p7v…qql0 I tried searching for these guys on the new podverse web alpha - found their album feeds - but then I couldn't find a way to get to their artist page - not sure if that's still in the works but thought I'd let you know

2026-01-09 15:05:02 UTC

New French Symphonic Metal band Hartlight now available on Fountain and any supporting Podcasting 2.0 music player.
Check out their music and give them a welcome boost!
https://fountain.fm/artist/BHQT3YDR59zGumqz9RVO
https://podcastindex.org/podcast/7648720

2025-12-31 11:07:51 UTC

FYI @npub1fmx…wp74 we are seeing LNURL payment failures to the main No Agenda Show split: no_agenda_show@strike.me
{
"status": "ERROR",
"reason": "Invalid amount, minimum is 100 and maximum is 16000000"
}
What's strange is the other strike lnaddress splits are all working despite them having lower splits:
clip_custodian@strike.me
rubblizer@strike.me
Maybe caused by a setting in Strike? Is your "Receive currency" set to Bitcoin in settings? Maybe the minimum only applies when receiving USD?

2025-12-30 16:01:53 UTC

- reply

yep that makes sense 👍

2025-12-30 15:57:49 UTC

- reply

yeah there is definitely a trade-off between keeping full split records + amount of data - ultimately if streaming payments per minute with splits grows 1000x in volume we might have to figure something else out - but for now I think this approach best preserves all the data we had in the keysend TLVs

2025-12-30 15:51:18 UTC

- reply

currently we create a different payment record for each split - but link them with a "group" id which is also in the metadata

2025-12-23 15:40:27 UTC

Fountain 1.4.4 is now live 📲
We've made some major improvements to CarPlay and Android Auto - just in time for your drive home for Christmas.
You can now play podcasts or music saved to your library, or explore recommendations from people you follow on Nostr, all without touching your phone.
https://primal.net/e/nevent1qqsfkksx0ydjrs8t30s3jwkvwf5jkw3s696c4wg88e4f0lrp5zje57qzv4ahk
https://blog.fountain.fm/p/1-4-4

2025-12-20 23:03:29 UTC

If anyone here listens to podcasts mostly in the car - we would love some help testing our new CarPlay / AndroidAuto experience that’s now available in beta with Fountain 1.4.4.
The new Fountain experience in the car much better than previous versions - but we really need help testing it before general release.
Beta links are available in our telegram group - https://t.me/+ZMnGthLREYQ3N2Rk
Please do jump in and give it a quick test in the car if you have a spare 5 mins this weekend! 🙏

2025-12-19 14:40:17 UTC

Fountain 1.4.2 is now live 📲
Based on your feedback, we made a couple of improvements to the library.
You can now see a grid view of your shows and get to the filtered episode list in one tap.
https://x.com/fountain_app/status/2002024723345969565
https://primal.net/e/nevent1qqspezfm7tsyspzrcrdv6c8x7d3aaspal3etnd6aj6xrha6z3mnqupc0j9apq

2025-12-15 18:12:31 UTC

@npub137c…y0lh
Is there a way to generate pod.link episode links via some kind of url param or API?

2025-12-15 09:54:25 UTC

- reply

great to hear! thanks again for the bug report!

2025-12-14 14:42:40 UTC

- reply

we have a new version 1.4.1 which is now live - although we weren't able to replicate the issue - we've made an update to the layout logic this screen which we believe will fix the issue - can you let me know if you're still experiencing it on 1.4.1?

2025-12-13 13:23:00 UTC

- reply

Thanks for the bug report - I'm just testing now on an iPhone16 simulator and I can't seem to replicate this.
Is it a regular iPhone16 or Plus / Pro / Pro Max?

2025-12-12 18:01:37 UTC

- reply

no not currently - we only support incoming NWC connections - so you can use an external wallet in Fountain
we hope this showcases to other podcast apps that NWC is a great option for letting users choose what wallet they want to use

2025-12-12 17:38:34 UTC

Fountain 1.4 is now live, and we've completely redesigned the Fountain wallet, made UX improvements to payments across the app and added some highly-requested features:
💜 Nostr Wallet Connect
⚡️ Pay Lightning Address
⬆️ Withdraw to Strike
💳 Choose Payment Method
https://x.com/fountain_app/status/1999529230527316390
https://primal.net/e/nevent1qqst57g7829mur9phklus5zd7gffy8f49h6m5s3l4sy668qvm2sgyscgpkpvs
https://blog.fountain.fm/p/1-4

2025-12-08 20:23:49 UTC

- reply

would love to see a short video walkthrough of how you are working with the model in your IDE!

2025-12-05 17:15:57 UTC

- reply

We only automatically display / play the video on web - in the app we default to audio and let people switch if they like

2025-12-04 22:50:17 UTC

We published a blog post on video podcasts using the new <podcast:alternateEnclosure> tag - https://blog.fountain.fm/p/video-podcasts
Would appreciate some shares and also feedback on our new web video experience (works with any video alternate enclosure feed) - https://fountain.fm/episode/bb3MURtHHVbPFkvvDpTc
X - https://x.com/fountain_app/status/1996712018779283599
Nostr - https://primal.net/e/nevent1qqsqs0c0hft3474phgkejj7vk68ly4cyln4xlm50rvx5c2wkdajdkmqdptxnf

2025-12-03 17:22:32 UTC

- reply

what nostr spec are you using for favourites?

2025-11-14 13:13:04 UTC

- reply

It looks like the lnaddress for this episode item split is invalid:
podcastindex.getalby.com
should be podcastindex@getalby.com rather than a . between handle and domain

2025-11-13 10:54:07 UTC

- reply

we don't unfortunately - we discontinued Fountain Radio - the infrastructure was slightly messy - hoping to re-build in the future!

2025-11-07 18:08:02 UTC

- reply

yes you could do this easily

2025-11-07 18:07:42 UTC

- reply

you wouldn't need step 4 because there is no verification of the payment with this proposal - you're just implicitly trusting whoever is hosting the url (app or service)

2025-11-07 18:06:32 UTC

- reply

you could have a relay that only a certain set of app pubkeys could publish to

2025-11-07 17:57:26 UTC

- reply

yes the easiest way to implement this is that the apps host the metadata via their own content urls - just like we are doing here - https://fountain.fm/episode/JCIzq3VyFKQVkEzVNA8v?payment=5XIAt66P29Iv6rjSTZUB
and I believe @npub1qvx…hseu were experimenting with
however - for apps that don't have a server - this proposal still caters for them because any third party service could generate the url for the app to use when sending the payment

2025-11-07 17:54:29 UTC

- reply

I didn't say wallets should "host" metadata - I said they should have the option to parse it from the description field in the payment which is what my proposal outlines

2025-11-07 17:49:40 UTC

- reply

private metadata that is only visible to the podcaster is a whole other problem that is much harder - and if we try and solve it at the same time as getting the basics working - it's doubtful we'll get anywhere
but we can always come back to this

2025-11-07 17:48:24 UTC

- reply

I think Podcasters fit into 2 categories:
- those that will never get into the tech layer themselves - they will use a service like Fountain / Alby / their hosting company - and these companies will handle indexing podcast related nostr notes from all relays (this is what we do)
- those that are self-hosting / interested in the tech - and they would be able to figure out how to query multiple relays - and put an additional tag in their feed signposting which relay to use

2025-11-07 17:45:02 UTC

- reply

the assumption is that other payment protocols will also have some kind of short description field - enough for the rss::payment prefix + url
so this would be extensible to any protocol

2025-11-07 17:38:50 UTC

- reply

yes they could - but it is much harder to host a custom http server compared with parsing data that already exists within your database
so for anyone running LND, LDK, Core Lightning, or other - it's easy to parse the data that is already there

2025-11-07 17:31:37 UTC

- reply

yes - but importantly by using nostr there is the benefit that everything still works if there is no explicit url in the feed

2025-11-07 17:28:24 UTC

- reply

Steven yes this is exactly right.

2025-11-07 17:27:19 UTC

- reply

this could easily be added to the feed:
<podcast:nostr npub="..." relays="...">
But in reality right now because it's early we can just pick a set of relays that we all agree to publish to. The events can always be re-synced to other relays later.

2025-11-07 17:23:16 UTC

- reply

The wallet needs at least the option to parse the full metadata - so that people hosting their own wallets can access all the data.

2025-11-07 17:15:12 UTC

Also - what's funny about all of this is that nostr literally solves every problem that has been brought up because there are no servers required and it has built in signing of events. It also has the added benefit of cross-app comments, likes, replies etc.
The community here has clearly rejected nostr which is why I have proposed this alternative.
But if you want to take a look at my previous proposal it is here - https://primal.net/merryoscar/open-podcast-payments-with-bitcoin-and-nostr

2025-11-07 16:49:59 UTC

- reply

Yep just sent you a test payment - this is what it looks like receiving to my Primal wallet - which shows the link as clickable which is nice:
https://cdn.masto.host/podcastindexsocial/media_attachments/files/115/509/440/403/290/527/original/4569ab6694fbc041.jpg

2025-11-07 16:45:28 UTC

- reply

I don't think there's any problem with hosts signalling via the feed how to get the payment URL.
It's just that for receiving wallets - they're not going to be parsing RSS feeds - so the 200 character BOLT11 field needs to contain enough info to parse the metadata.

2025-11-07 16:43:16 UTC

- reply

I agree the metadata should be payment protocol agnostic.
I also think there could definitely be something in the feed that signals how to get the metadata URL - I just also think we need a way for apps to start doing this now without relying on hosts to make changes.

2025-11-07 16:40:51 UTC

- reply

Strike / Cash App are not going to host podcast payment metadata on public URLs - no chance of that.
Sending apps need a URL to insert into the BOLT11 description field.
Any apps that already have web URLs and a database can do this.
For others we need a service - like @npub1g2v…achf was suggesting he might do.

2025-11-07 16:37:34 UTC

- reply

ok great - yeah that would be really useful - and also a great addition to OP3 analytics perhaps?

2025-11-07 16:36:30 UTC

- reply

I would love Alby to support this - in fact by looking at their Alby Hub code - I don't think it would be difficult.
If they see the rss::payment prefix in an incoming BOLT11 invoice - they could just parse the full metadata from the headers and insert it into their existing Metadata field - https://github.com/getAlby/hub/blob/eec8328f6cecf1b322053b0aadbe7b91b4e6574a/db/models.go#L85

2025-11-07 16:34:46 UTC

- reply

That would be amazing John - we'd also be happy to offer this service - but I think it makes it feel slightly weird if one app is hosting the payments for all the others.
The cool thing about this proposal is that if an app includes a URL in the BOLT11 invoice like:
rss::payment:boost op3.dev/payment/123
Anyone can parse the metadata and do whatever they want with it.
I do think services like this should have either an API key or signature to prevent spam

2025-11-07 16:31:49 UTC

- reply

I think the biggest challenge with all of this is deciding who is going to store the payment metadata.
Apps, Hosting Companies, or Wallet Services?
The reason we opted for putting the data in a URL (+ headers for easy parsing) - is that receiving wallets can see the data without knowing anything about this.
Whether the data is signed by the app or not - I think having it accessible from just the payment is important.

2025-11-07 15:31:20 UTC

- reply

Also if the API is in the feed - how do you validate that the payment actually happened?
The good thing about the app generating these URLs is that they know at the time of sending that the payment actually happened.
Fountain / others could still create an API for apps to use - but they would need to have an API key that is trusted.

2025-11-07 15:28:37 UTC

- reply

I think the problem with relying on the host feed having an API in it is that people that are self-hosting need to run a server and database.
I think it's much easier for an app to do this than someone self-hosting a feed.
Fountain / others could provide a service like this - but in my view it should be the sending app that uses this service to generate a URL for the payment description

2025-11-07 15:21:05 UTC

- reply

- if the app chooses to store the metadata they can serve it via their own url
- if the app doesn't want to save the metadata in their own database - other services can do this - wallets or analytics services that provide some kind of API that returns a URL
If neither the app or wallet service wants to store podcast payment metadata - then we're kind of stuck no matter what the spec is

2025-11-07 15:05:04 UTC

- reply

Because this approach is just a prefix + URL - really anyone can provide the URL to the sending app.
Podcasters can choose which wallet they want to use to receive - and wallets can programatically parse the metadata and store a copy of it.
So there are multiple options:
- app could store metadata and serve url
- sending wallet service api could provide url for app to use

2025-11-07 14:55:29 UTC

- reply

Yes apps or wallet services will need to serve these links - Fountain might provide an API for this as a stop-gap

2025-11-07 14:53:22 UTC

- reply

Here's an example payment link - https://fountain.fm/episode/JCIzq3VyFKQVkEzVNA8v?payment=5XIAt66P29Iv6rjSTZUB
And here's how you can query the JSON programatically via curl:
curl -I -s -o /dev/null -w '%header{x-rss-payment}' 'https://fountain.fm/episode/JCIzq3VyFKQVkEzVNA8v?payment=5XIAt66P29Iv6rjSTZUB'
(note this is URI encoded JSON string)

2025-11-07 14:51:24 UTC

I know my previous nostr-based payment metadata solution didn't really get adoption from other PC20 apps - so me and @npub1gfn…mk8j have come up with a much simpler solution for LNAddress payment metadata:
https://github.com/Podcastindex-org/podcast-namespace/pull/734
TLDR - we use the BOLT11 invoice description field to add a rss::payment prefix along with a URL that returns the full metadata in a x-rss-payment header.
From today all LNAddress payments sent from Fountain will use this metadata approach - so feel free to start testing!

2025-11-05 08:59:53 UTC

- reply

yes

2025-11-04 18:47:03 UTC

- reply

yes - any fountain lightning address

2025-10-30 12:22:21 UTC

- reply

testing on a wifi router with dns ad-blocking

2025-10-30 12:04:51 UTC

- reply

This episode also doesn't play in the overcast mobile app if you have an ad-blocker enabled - https://overcast.fm/+AAIwMffebR0
@npub13cg…ck4q are you able to play this in overcast with an ad-blocker?
I don't see any error messages it just has an infinite spinner.

2025-10-30 11:55:03 UTC

- reply

Also this overcast link for the other Glenn Beck feed doesn't play in brave - https://overcast.fm/+AAIwMffebR0
seems to be verifi.podscribe.com that is blocking

2025-10-30 11:50:00 UTC

- reply

ok great thanks - I'll look into updating our playback error handling to give a contextual error message
this is the example glenn beck show on pocketcasts - https://pocketcasts.com/podcast/the-glenn-beck-podcast/0b49bf90-b88c-0138-e6e2-0acc26574db2
(doesn't play in brave)