Dave Chimny

around the end of the year

I think I can wait this long. ??

You’re both completely right. But even with the smaller filesize the error occurs and I just wanted to know why it happens and how it can be prevented. Maybe it would occur too, when someone uses SSH.

Here’s, what I investigated:

PodBean provides a URL for every MP3 file:
https://[username].podbean.com/[unique-id]/[filename].mp3

When I paste this URL into the Audio File field and save the post, the “Memory exhausted” error pops up after ?5 to 10 seconds. Very frustrating. Even after setting filesize and a filesize_raw manually.

I looked up, where the URL is redirecting to (some CDN thing) and pasted the “deeplink” into the field:
https://[number].podbean.com/pb/[unique-id]/[filename].mp3

The filesize is determined very fast (duration is not, but that’s another story) and no error message appears.

So my walkaround is now, that I use the deeplink URL first. I let the plugin find out the filesize wile saving and then I enter the “correct” URL provided by PodBean. But this brings the error back again.

What I don’t understand:
– Why does the error occur when a file is behind a redirect?
– Is the filesize queried everytime a post is saved?
– Why are there filesize and filesize_raw?

The size displayed on the feed page has another value than filesize and I don’t know where it is used anywhere else, so I don’t see the sense in it. I’d go with filesize_raw only and let the human readable size be calculated where needed.

Maybe this could be changed in a future release for easier use.

iTunes says: Square image. From 1400×1400 to 3000×3000 pixels in size. PNG or JPG in RGB mode.

That’s where most WordPress themes collide, because they don’t have square teaser images.

• This reply was modified 7 years, 1 month ago by Dave Chimny.

Yeah, that came into my mind, too, some minutes ago. Maybe I should stop using the full 320 kbps stereo MP3 files of my 2-hour radio show. ??

Nonetheless the filesize query could be streamlined anyways, maybe.

Could be a cache or proxy thing. If I change something, I go to testuri.org and check what my server really answers to requests. ??

Anyways: Everything works fine here. The URL redirects (301) to https://userdefenders.com/podcast/003/ and then there’s the content with a valid certificate (“UbiquiTLS”).

But I’ve seen another thing: Some of your episodes in the podcast feed have filesize of 0.00 (episode 30 to 35 for example). This could lead to problems in some podcast players.

Works. ??

The most recent version is actually 1.15.2. ??

Downloading Version 2.1.0 and overwriting the files in the plugin folder resolved the problem. But then there were many copies of every template that had to be deleted.

By the way: The image URL comes from the Photon module of JetPack. That’s the CDN image hosting service of WordPress.com. ??

Please stop using validators for “normal” feeds. They were never made to read podcast feeds. CastFeedValidator is what you need. This validator says, there’s no error.

Next step is: Go to iTunes Connect and change the URL for your feed to the HTTPS version. It should take about 10 minutes and then you know if it’s okay for iTunes.

The only thing you have to do is to tell your server to redirect every “http” request to its “https” counterpart. Most webhosters have an option for that. Else you can do it with 3 lines in the .htaccess file.

For going deeper, you could read this article on WPBeginner.

• This reply was modified 7 years, 12 months ago by Dave Chimny.
• This reply was modified 7 years, 12 months ago by Dave Chimny.

Found another hint: The URL that PodBean gives me is a 302 redirection to the mp3 file that seems to change its location dynamically (maybe a CDN thing). When I use the target URL of this redirection, the filesize readout works perfectly.

So I think the redirection is a problem here.

I changed to HTTPS some months ago with my podcast and had no problems. The most important thing is to have a 301 redirection from HTTP to HTTPS content after the certificate is installed.

To check how iTunes reacts on the change, you can update the feed URL manually on iTunes Connect (a service for podcasters, Apple just started some months ago).

Time to implement a query if the input starts with http or https – just to prevent this. ??

(I know people who linked images and used ftp://username:[email protected])

I got the same problem: After updating to version 5.12.43 on a multisite WordPress, I’m kicked off the backend. Renaming the plugin folder deactivates it and everything works again.