Thank you for reaching out to us.
Error occurred when trying to fetch the file using wp_remote_get(). cURL error 28: Operation timed out after 30000 milliseconds with 624013 bytes received.
I have carried out a test in my dev site and I don’t get this error myself. And I run the latest WordPress version and the latest plugin version. I also run PHP version 8.2.4.
This is a server configuration issue. Please, speak to your host and ask them to make some changes to your account. This will fix your cURL error 28 issue.
Let me know how you go.
Kind regards.
Thread Starter
Malae
(@malae)
I doubt that testing on a dev site would provide much information, unless the URL of the file in question was known.
It would seem that you were not aware of the changes in the version 1.9.12 of the plugin that caused it to throw the cURL 28 error. You did not address the addition of the scap-utility-functions.php file in this version, for which I sent you the information where it throws the error in line 69, when it checks if the file is accessible.
On my site, the file is a stream from a radio station and is played on a radio plugin on the home page and the Compact WP Audio Player plugin allows a user to play the stream on another page without added information. Note that the radio plugin has played the stream for well over a year and continues to do so. I also have this site on a LAMP server for development with the plugin version 1.9.9. On updating, it immediately ceased playing and had a similar cURL 28 error. This server has few limitations.
Thank you for sharing more information. I have submitted a message to the developers to investigate further your findings.
Kind regards.
Plugin Author
mra13
(@mra13)
Hi, We needed to make the change (that checks if the audio file is accessible) to this plugin to remove a potential security issue.
Sorry to see that you are facing this issue but the change was necessary. The best option for you will be to switch to an alternative plugin that can embed the audio file without any error.
Thread Starter
Malae
(@malae)
Thank you for the reply.
I have looked at the scap-utility-functions.php file and see that it is checking for non-Latin letters, Javascript , accessibility – response code is 200, url is protocol relative http, https etc. It would not have found any of these issues as the url is https:// with latin letters and numbers and no code.
Line 69 $is_accessible_response = scap_verify_file_url_accessible($fileurl);
seems to have determined that it is not accessible, which is obviously not the case. Your answer is therefore again not addressing the real issue. I want to continue using this plugin and would appreciate your discussing the issues further with the developer.
Thread Starter
Malae
(@malae)
Hello,
I would like to add another issue caused by the addition of the the scap-utility-functions.php file to version 1.9.12. On another site I serve audio in two formats:
[sc_embed_player fileurl=”http://www.example.com/wp-content/uploads/my-music/mysong.ogg|http://www.example.com/wp-content/uploads/my-music/mysong.mp3`
Thithis now prints the warning:
Requested file could not be found (error code 404). Verify the file URL specified in the shortcode.
[sc_embed_player fileurl="http://www.example.com/wp-content/uploads/my-music/mysong.ogg|http://www.example.com/wp-content/uploads/my-music/mysong.mp3"]
I see two URLs in the code above http://www.example.com/wp-content/uploads/my-music/mysong.ogg|http://www.example.com/wp-content/uploads/my-music/mysong.mp3. I also see that your URLs are not secured https://.
Kind regards.
-
This reply was modified 2 months, 3 weeks ago by
mbrsolution.
Thread Starter
Malae
(@malae)
Depending on the actual audio, I often prefer to use .ogg as opposed to .mp3. Ogg Vorbis employs more advanced compression techniques compared to MP3, resulting in potentially better sound quality at the same bit rate. If you go back 5 – 10 years, browser support was lacking and it became common practice to use both the .ogg and the .mp3 version of the audio file, so there could be a fallback, if .ogg was not supported. I have often done this with HTML 5 players for many years including the Compact WP Audio Player, which has had no issues until version 1.9.12. What is your issue with two URLs?
Regarding my use of http:// instead of https://. This is really not an issue, but since you asked, these are not my URLs, but copied from the example on this plugin’s page:
https://wordpress.org/plugins/compact-wp-audio-player
Usage
Use the following shortcode to embed an audio file anywhere on your site
[sc_embed_player fileurl=”URL OF THE MP3 FILE”]
Example shortcode:
[sc_embed_player fileurl=”http://www.example.com/wp-content/uploads/my-music/mysong.mp3″]
Perhaps you should ask the plugin developer to update the page. FYI, all my sites use https://. Instead of chasing non-issues, please try to understand the real issues.
Thank you for providing more information. I have submitted a message to the developers to investigate further your issue.
Kind regards.
Thread Starter
Malae
(@malae)
@mbrsolution
@mra13
With reference to the following:
https://wordpress.org/support/topic/access-issue-with-mp3-files-from-s3-bucket-after-plugin-update/
I’m very happy that the issue has finally been recognized and is now fixed. I can now update this very useful plugin.
May I suggest that the plugin Admin page be edited to remove: “… There is [sic] no extra settings…” .
Plugin Author
mra13
(@mra13)
Thank you. I will do that.
