It appears that 3% of posts with the Seriously Simple player have a fatal error. The overwhelming majority work just fine but for some reason, it targets individual posts with this error:
Fatal error: Out of memory (allocated 1073741824) (tried to allocate 527429960 bytes) in /home/partyfav/public_html/wp-includes/class-requests.php on line 649
I have a backup in these few instances by using the PowerPress plugin for these posts. Still, I prefer SSP. If I remove the mp3 file from SSP and post with just the PowerPress, it works fine on these specific posts.
Like I said, it’s only about 3% of posts because most work just fine.
The page I need help with: [log in to see the link]
It looks like for some reason it takes too much memory to show those pages than your server can provide. It’s hard to say what could lead to the error since the error happens not in our plugin, but in the WordPress core file.
Do you see any difference between that 3% of posts and the other 97%? And for that 3% – do you see the Fatal error always on that pages, or just sometimes? If always, did you try to change anything on the page to get rid of the Fatal error?
I thought about it overnight and went back and looked at the files. It’s a size issue. Some of the episodes were over 3 hours long and encoded at 320 bitrate.
I reencoded those episodes at a lower bitrate this morning and it worked. I have memory uploads on the host end set to 2G so the limit being imposed is on your end.
Regardless, that is the fix. Thanks for the reply.
Cool, I’m glad you managed to fix it!
Also, if you have large files, you can consider using our Castos platform to store them. In addition, you’ll have incredible analytics and many other benefits, like republishing to youtube and many others 🙂
You can also check this video for getting an idea why Castos is great – https://www.youtube.com/watch?v=Y5ISh7ljcC4
Your player seems to be targeting smaller files now with the same error. They work once encoded at a lower bitrate making the file smaller.
As for using your service, I was until you kicked me off because of some stupid generic trademark dispute over the use of ‘dance club’ for one of my categories, which has now been resolved. I’ve been doing this for 16 years and have never had a complaint over anything.
Regardless, this was an issue when I originally imported the feed from my previous provider to Castos. Your support section states there’s a limit on the size of the file but since I’m no longer hosting with you, it shouldn’t matter.
Even then, as mentioned above, it’s selectively random as to what it will allow in size. I’ve never had this issue with any host much less just a plugin player that’s not even hosting the content. It’s weird.
Our player does not store the files, it just plays them to users. All the issues with uploading/storing files are hosting-related. So, if there are some problems with the file size, please ask your hosting support, or maybe change it to something else.
Also, I can see that your content is not a podcast, but just music. Do you have a license for storing and playing it? Maybe Castos didn’t agree to keep your files on their hosting because of the license issue?
I think it’s rich that Castos doesn’t understand how the DJ community works in conjunction with the music labels and DJ promo services to promote artists in the clubs and through DJ mixes. Much like talk and series podcasts (and now video podcasts), Continuous DJ mixes have been an integral part of podcasting from the beginning. You’re confusing what we do with radio and streaming. I’ve only been doing this out in the open for 16 years and was at the forefront of the podcast movement but I digress.
That being said, having used your service, I can assure you the issue is the limit you place on file size whether I host with you or not. You might want to read your own support section about the issue: https://support.castos.com/article/200-what-is-the-maximum-file-size-i-can-upload#:~:text=This%20setting%20can%20range%20from,Did%20this%20answer%20your%20question%3F
Though your support section blames WordPress for the limitation, that’s just not true. I previously hosted with Podbean and the exact same files played just fine using the default WordPress player. After all, these files are not being uploaded into the WordPress media file folder. My current host doesn’t have any issue with uploading the larger file sizes either and it works just fine in their player. I just don’t like their player and prefer yours. Take that last statement as a win.
I’m not trying to be argumentative, but I’ll bet that if you dig into your code — you’ll find there’s a limitation being placed on your end regardless of whether the file is hosted with your service or not.
Ultimately, it’s not that big of an issue because I can re-encode them at a lower bitrate to get them to work. I’m manually moving over 900 episodes and have the benefit of seeing firsthand which ones are playable and which ones are not. The majority of the audio files are playable. It appears to be selectively restricting some files but not others that are the same or in some cases larger.
No one is trying to disparage Castos or your player because both are excellent and like all other hosting platforms have their pluses and minuses. I’m just pointing this issue out as I see it. I’m guessing it’s not that big of a deal on your end unless you have a video podcast where I can see that could be problematic.
From what I’ve seen, most DJs encode at 128 bitrate to save on hosting costs like in Soundcloud even though that’s no longer ideal because of cheaper storage, faster wifi, mobile data transfers, and internet connections.
For the record, publishing my podcast to all the streaming services that I was already on and changing my feed without my permission was a colossal misstep on your part. I can see how this is beneficial for newbies but I wasn’t one of them because I already know how to add my feed to a streaming platform and was able to pick the services that work best for my audience. You might want to consider an opt-in for hosting customers. Thankfully, I’ve gotten all but one fixed, which should be corrected this week.
In fact, pushing it out to Apple Podcasts is what started the whole issue with me leaving Castos in the first place where another DJ (who runs a podcast similar to mine) and who just trademarked ‘Dance Club’ last year after Billboard (who never trademarked the term) dropped the chart. ‘Dance Club’ happened to be one of my categories and when Castos pushed the main feed out, it got reactivated in Apple and iTunes ruffling this other guy’s feathers. We’ve since worked out an agreement where I changed the name of the category because it’s not pertinent to my operations.
Castos would serve itself well to have legal counsel on stand-by to advise in such frivolous matters because this won’t be the first time this issue comes up (and I doubt it was) as opposed to just screwing over your paying customers. That’s on you.
For what it’s worth, I spent several hours cleaning up the Apple Podcast mess you created by having to archive the channel and all of my shows and then recreate them again with my original feed from WordPress. If I had done this for someone else as an independent contractor (which I do), I would’ve charged them over $1,000.
Even though I don’t harbor any bad feelings or ill will against your company, I won’t try to help you improve your service going forward. Like most developers I run across, you don’t take constructive criticism very well unless it comes from within your own community. It would serve you well to show a little humility when people point out an issue with your service so you can improve upon it as opposed to talking down to them. I’m not saying they’re always right because experience has taught me otherwise and granted me the patience to walk them through their issue to correct it.
There’s no need to publish my response.
As you told in the first message, the problem is happening in the WordPress core code, not in our plugin:
( Fatal error: Out of memory (allocated 1073741824) (tried to allocate 527429960 bytes) in /home/partyfav/public_html/wp-includes/class-requests.php on line 649 )
So it’s definitely not a restriction in our code. I would suggest hiring a developer to investigate what’s happening there.
- The topic ‘Fatal Error’ is closed to new replies.