Endless audio buffer on WP audio player
Haven’t found a solid solution in the forums regarding the never-ending-buffer that has been occurring in my WP audio player when I post audio. Here’s my post, moved from the wrong forum:
I’ve been having difficulty posting audio properly. I’ll usually have 2 audio files appx. 60 megs each per post, and the WP audio player usually buffers until I get an error message.
Any ideas as to why the stream breaks? All are greatly appreciated.
Is the URL for the audio file correct?
Can you link to an example of this so we can see what is occuring?
I double-checked the URL to the audio file, and made sure the coding was done properly
Here’s what I’m talking about:
Part 1 will buffer until “Error opening file”, but doesn’t build the buffer meter up at all.
Part 2 will buffer for about 1 minute, and then the buffer meter will start to move, and the audio will play (extremely long delay from first click).
Any ideas why this is occuring?
Volunteers cannot help when it comes to problems like “endless buffering” on the wp audio player. Please use the “support” button located on the top right hand corner of any admin side blog page to report this to staff. Support is open Monday to Friday 8 AM – 4 PM, Pacific time. Please do not post personal information to the forum but do note that staff require the following information when you send in your support ticket:
– your browser
– your browser version
– your FULL blog address (not the name, the real address that begins http:// )
– your FULL username
– your REAL email address that is registered here
– and a very good description of the exact problem.
One of the reasons of the ‘endless buffering’ problem is when the audio file is being hosted by a provider that doesn’t allow direct access to such file.
Try hosting your audio files on a different server. I use http://www.musicwebtown.com and, so far, haven’t had this kind of issues.
YAY! devblog – thanks for this information. I’m bookmarking this thread. :-)
Also, if you host at Odeo, every file has three different URLs. In my experience, you need to use the URL of the MP3 in the podcast, otherwise it buffers eternally.
I got real excited about devblog’s tip, as I (a noob) am having a similar problem to letsgetserious: my mp3s just won’t play. No endless buffering, just ‘ error opening file’. I had first put my mp3s at Z-share, then Support told me that the link had to end ‘.mp3’, so I’ve tried a number of things, from simply copying a .mp3 address from a site that already plays the file, to signing up for webhosting at Filefreak.com. I went to webtown, but the problem persists. Until Support opens, any tips? My link now looks like this:
I’ve created a test post with the URL of your audio file and it plays well. Check it out:
The code I’m using is like yours:
Please let me know once you’ve seen it so I can delete that post.
no; that just buffers forever….do you think maybe it’s just MY computer (and letsgetserius’s) that won’t play these? I even tried just clicking on one of the URLs that I had tried before [http://www.box.net/shared/static/e1n3pay069.mp3] which was just stuck in an email, and it opened a Windows Media Player and started playing…but when I stuck the URL in my WordPress blog it doesn’t play, it asks you to save the file. Again, I’m a noob, but I’m gonna put my MusicWebTown link BACK in my blog; will you try it and see if it plays? If it plays for you, it must be something in MY computer. (and can you also try the ‘click below for new window’….see if that works? Thanks:
I’m testing too the box.net URL and it works. Check it out:
BUT Here’s the thing… both players work in:
* Firefox 2
* Safari 3.0.4
The player linking to the file hosted at box.net works only in:
* Opera 8.53
* Opera 9.01
Neither of them work in IE6
So, I’m assuming you’re using IE6?
This is very strange, and right now, I can’t think of a reason why these browsers are behaving like this…
So is not your computer, it’s the browser. I’d suggest you to contact support and point them to this thread… Both param tags have the same values (except the URL to the audio files, of course) and I see no reason why they shouldn’t play.
I use MSN Explorer, as well as IE7, but here’s what MSN says in my setup:
System Configuration Summary
Operating System Windows XP (5.01.2600)
Internet Explorer 7.00.5730.0011
MSN Client 9.50.0039.1900
MSN Market en-us
MSN Brand MSN [VZ02]
MSN SKU Verizon Broadband with MSN Premium
Default E-mail Program MSN Explorer
So, when you say ‘contact support’, do you mean WordPress Support?
So, when you say ‘contact support’, do you mean WordPress Support?
yes, of course.
I’ll go ahead and delete the test post.
Thanks for your help devblog, but I still don’t know what my solution is; all Support keeps telling me is that the help I’m getting here is excellent. I guess if some of my friends get back to me and tell me that the songs play in THEIR browsers, that makes it less of a problem.
My default browser is Firefox, and the songs hosted at musicwebtown and box.net play with no problem (see my post above for a browser compatibility list).
If you’re friends/readers visit your blog with either Firefox or Safari, they won’t have any problems listening to your audio files… However, issues will araise if they visit your blog using a different browser (see list above).
I can’t say it’s a ‘bug’ from wordpress’ end, but I believe they should look into this and solve it.
My guess, and this is just a guess, is that the wordpress guys don’t use IE at all, and as long as it works in their browsers, they’re happy with the results. IF this is the case, then how bad because they should test their web apps in as many browsers as possible. Even, if they’re adapting 3rd party plugins, they should test them in as many browsers as possible as well to make sure the user experience is a good one no matter what browser they’re using. This is just my opinion.
For now, I’d suggest you to host your files at box.net… based upon my tests, those hosted there, do play in IE7. They might not play on MSN browser since, I believe, the engine it uses is the same as IE6 does. (see list above)
Sorry I can’t be of more help.
Thanks for the time and energy you put into this. I have bookmarked the thread. :-)
yeah, thanks again devblog; you’re a lot more help than Support has been (nothing personal, Support; I’m sure you’re trying and will help me soon!) I’m such a noob, I assumed that, like 90% of people out there were using IE, but I just emailed a Mac-using friend and told him your findings, and he reports:
“That’s odd because they will not play on either my Firefox 2 or Safari 3.0.4 on my Mac.”
Thank you, TT.
No problem, djeddieo.
It’s odd indeed because they do play on my Mac as well… I haven’t tested them yet on my Linux box, though. I’ll do it as soon as I get home and I’ll update this thread. Maybe it’ll be useful to someone else later.
I’m aware that there are problems with the audio function (for the lack of words). Most of my visitors who used IE could not listen to it at all (eternal buffering). I used to be able to replicate it with IE myself, but not anymore. I couldn’t analyze it any deeper than that, so I never send in for support. Not quite sure whether it is the host either, since i used musicwebtown before, but hotlinkfiles now.
I’m inclined to believe devblog’s analysis that it’s a browser compatibility issue (if I’m summarizing devblog accurately). I poked around on other wordpress blogs to see if there were ANY audio players I could listen to, but didn’t find any. I was really excited to start blogging (a cousin of mine had set up this WordPress site a s a surprise), but the audio player was, for me, a key element. I might do some looking around for other blog hosts.
I have some posts with an audio player on my blog. This is one of them:
it doesn’t work in IE6 nor IE7 and those I mentioned above…
I didn’t notice this issue till you brought it up. I assumed this audio player would work in any browser but guess not…
Devblog’s audio works in FF 184.108.40.206 as well as Konqueror 3.5.8 under Fedora.
The topic ‘Endless audio buffer on WP audio player’ is closed to new replies.