Hey @adam the reason Podverse loads podcast art in clips instead of the episode art is because we shrink and host all podcast art on our servers, but we don’t do that for episode art (yet) because there could be 1000% more episode images.

If we load art that is not shrunk, then sometimes we run into podcaster hosted images that are 1MB or more, and if we load many of those in *list* views, then we can slow the browser down significantly.


@mitch @adam something we should be doing, at a minimum, is load the episode art on clip pages, so even if the current podcast art loads for a clip in a list view, once you actually play the clip or load it’s page, we should load the podcaster hosted episode artwork.

We actually only added episode artwork support to the mobile apps a few weeks ago, and haven’t added it to the website yet. I’ll take a look this weekend and try to improve the way we’re handling that.

@mitch @adam there could eventually be a need here for a 3rd party image hosting / shrinking solution, to keep us all from reinventing the wheel.

@mitch @adam We’ve tried twice and can’t seem to get it off the ground. One day this will exist. Lol.

@dave @mitch @adam

I built this for myself for pod.link. It was all optimistic URLs based on appleIDs and GUIDs that used serverless function to fetch the image from the feed, resize and generate multiple versions, and cache them. (Would be trivial to rewrite for podcastindex)

After the acquisition, Podsights ripped it out and just used imgix.

@nathan @mitch @adam That would be killer. It’s a constant problem with the html based apps. They get killed with slow load times, mixed content and CORS.

@dave @nathan @mitch @adam

Anyone who built that service would definitely get added to my value block.

@StevenB @dave @mitch @adam

I just know this is going result in me buying another .fm domain isn't it.

@nathan @StevenB @mitch @adam That's one of the lesser known, yet still important, mission statements of Podcasting 2.0.

* Make Nathan buy 12 domains before Christmas


@dave @StevenB @mitch @adam If we're counting renewals, the next one will legitimately be my 12th podcasting-adjacent domain of the year.

· · Web · 1 · 0 · 0

@dave @StevenB @mitch @adam I mean, images.fm is right there for the taking. 😅

To avoid paying for everyone's bandwidth, what about an API that accepts show/episode IDs + dimensions, and provides the resized image as a data URI?

@nathan @StevenB @mitch @adam How big would that be though? Isn't that bigger than the image itself since it's base64?

@dave @StevenB @mitch @adam good point. I was imagining they'd cache the response and not need to request it again, but that's got it's own challenges.

What killed podcastimages.com/ ?

@nathan @StevenB @mitch @adam I think the original developer got tied up with other projects and couldn’t complete it. I’ll return to the idea at some point if nobody picks up the mantle.

It’s one of those problems that aren’t technically hard, but it requires a lot of disk space so it’s not cheap or quick to run.

@dave @nathan @StevenB @mitch @adam + bandwidth $$$ and podcast artwork is (thankfully) produced at a high resolution

@js @nathan @StevenB @mitch @adam Sometimes really high. I've seen people link 150 meg .PSD files as show art. 😉

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!