Jill Katze

Oh hey, source code!

I was insatiably curious so I dug in and took a look, and sure enough, lines 615 and 623 of class-ssp-admin.php call ss_podcasting->get_file_duration and ss_podcasting->get_file_size, respectively, which live next to each other in class-ssp-frontend.php starting at line 475.

Both of these functions call out to the built-in WordPress function wp_read_audio_metadata, and at that point there’s really not much that can be done. The error this is hitting doesn’t get raised as an exception, it’s a full-on fatal error and the script gets killed, or so some cursory googling tells me.

Granted, I’m not a PHP or WordPress dev so maybe there’s a more clever solution possible here, but I wonder if at least the automatic metadata acquisition that’s triggering this error wouldn’t be better off behind some sort of setting that can be toggled off? I assume the majority of users don’t hit this, but it might be useful for those whose installs live on memory-constrained servers to be able to force off, though I do see that the duration value is used to populate an itunes:duration tag in the RSS XML, and I don’t know how picky iTunes is about that being present, so this seems like maybe a deeper rabbithole than I should spend any more time investigating ??

At the very least, the workaround I mentioned in my post above exists for those of us who hit this.

Workaround: Manually set both a duration and a file size in the Podcast Episode Details when creating the post and you’ll dodge this issue.

Okay, I led with the important part, now here’s the backstory.

I hit this same issue and noticed that the failed attempted allocation size looked suspiciously like the size of the media file I was linking. I also noticed that the post did actually go through, and that if I navigated to the page, it would load and the data I had entered was there.

On a hunch, I removed the add_filter( 'ssp_show_episode_details', '__return_false' ); statement from my functions.php which I’d added to suppress the “Download/File Size/Duration” info under the audio player and sure enough, the post page stopped loading with the same error.

What’s happening is the plugin (or something it depends on) is trying to pull the episode file so it can determine its duration and file size, and blowing past the memory limit on certain hosts. I’m on shared hosting, so there’s probably a low hard limit set by my host that I’m running into. Luckily, setting those values manually bypasses the block of code that downloads the file to generate metadata on it, but this does seem like something the plugin might be able to handle more gracefully.

Hope this helps!