Operation time out

Hello @ashishpatel1992,

Can you provide the URL you are trying to verify so we can test?

Operation timed out may indicate that your server is unable to access the media URL, it is possible either your web host is blocking your server from accessing external URLs or your media URLs are unreachable from your server for other reasons (maybe they are the same server?).

When you reply with the media URL we can do some testing with our sandbox which may give us more insight.

Hi,
Here is the requested media url: https://podcasts.truckstopquebec.com/wp-content/uploads/media/5_Octobre_Serge_Lampron.mp3
No we didnt move host. We just upgraded the PHP from 5.4 to 5.6
Here is the screenshot from out test

View post on imgur.com

I tested your media file URL on my own test site and when I tried to verify it, I got a 500 internal server error. However, the URL loads just fine in a web browser. I’m not sure what’s going on, but I think it may have something to do with how your website hosting server is configured.

Hi,
Is there anyway I can put any debug code in your plugin file to get more information about the issue? The web hosting company is ready to help but they need to know what exactly has to be done.
Well I never get a 500 Internal error! The file size is around 110 MB so probably you are trying to copy the file from my server to yours and your upload_max_file size may not be enough!
I am not 100% sure.. but this is what I understand from the PHP code, it uses curl to get files from remote server and calculates the filesize and extracts the mp3 file audio duration.

Hello @ashishpatel1992,

You are welcome to modify PowerPress on your server as you wish, it is open source after all. When you trace through the code you will see that the script itself tries to download enough of the file to get the ID3 information from it, which contains the duration and file size information. This all happens on your server, not ours. It also does not have anything to do with uploading, as this is code that lives on your server that “downloads” the media file to verify it. IT does not download the entire file, it only downloads the ID3 tags. Downloading the entire file would take a lot longer and cause the verify feature to be slow and inefficient. My personal contribution to the getid3 library as well as documentation how it works is posted on my personal blog: https://angelo.mandato.com/2015/09/16/getid3-analyze-function-file-size-parameter/

I checked your media URL and I see it is hosted by CloudFlare. CloudFlare is known to cause issues with hosting podcast media files. I am 100% confident if you switch your podcast hosting to a podcast friendly service you will not have issues. Specifically in this case, HEAD and multi-byte range requests are not supported by CloudFlare, which is a requirement for iTunes. You can learn more about why podcast hosting media files has these special requirements in our podcasting manual as well as which hosts to avoid, here is a direct link: https://create.blubrry.com/manual/internet-media-hosting/

Commonly podcasters will host their media files on a separate service (such as Blubrry Podcast Hosting) in order to prevent the bandwidth traffic from effecting their primary website. If you do not want to support us, the makers of PowerPress, you can get podcast hosting elsewhere, or even setup Amazon S3 with CloudFront (it works quite well but you pay for bandwidth and storage). Keep in mind though that your RSS feed and URL to your iTunes image should also not be hosted through CloudFlare for the same reasons, iTunes uses HEAD and multi-byte range requests for those URLs as well.

Thanks,
Angelo

For your testing, I put your episode on Blubrry’s Podcast Media Hosting so you can test with it.

https://content.blubrry.com/demo/5_Octobre_Serge_Lampron.mp3

Thanks,
Angelo

Hi,
I have tested URLs without CloudFlare and it works, so looks like it is CloudFlare that is creating the problem. But before upgrading to PHP 5.6 it was working over CloudFlare. So I am still quite confused why this has happened when this never happened in last 3 years!

Hello @ashishpatel1992,

I am glad you are able to get it working. CloudFlare is an odd service. It may be though that your verify feature worked by using the “localhost” when on the previous server and when you updated the php it updated the server and then used the dns records from CloudFlare. That is my only guess as to why it used to work. If you have shell access to the server, you can literally add your local hostname in the /etc/hosts file so your server goes directly to your website rather than through CloudFlare. But this does not solve the issue for others who try to download/listen to your podcasts though. It is best to avoid CloudFlare for podcasts if at all possible.

Thanks,
Angelo