[Plugin: podPress] Podpress Plugin – Can't stream large mp3 file (400mb)

Hi Jonathan,

today I have tried to download your 359 MB Blu Jaz episode. I wanted to add this episode in my test blog on my local server system (XAMPP) where I can control the server configuration. I wanted to find out whether the player is able to play such big files or not.
I have tried to download the file via the “Download” link and (in the browser with) “Save link target as”. I have tried it 8 times. 3 times with FireFox, 3 times with Safari and 2 times with the Internet Explorer. But every time the download stopped/aborted after 7-9 minutes and 89-215 MB. (The download rate was between 200kb/s-581kb/s.)

I guess something similar happens when you try to play the file with flash player which is a part of podPress and displayed above the download link. The player buffers (downloads) the file until the download aborts and plays all what has been downloaded (maybe only 27-30 minutes).
In general I can say that the player is capable of playing podcasts that are longer than 2 hours. But most podcasts I know of and which have a duration beyond 2 hours have a lower data rate than your last episode has (e.g. 128 kb/s vs. 320 kb/s). Which means that the file size is often smaller than 200 MB. But these podcasts are mostly no music podcasts.

But that I have such trouble to simply download your episode leads me to the assumption that it is most likely an issue of the server (configuration) of your blog.
The downloaded amount of data was different each time that could mean that it is not a limitation of the amount of data per download.
But it does not seem to be a static time limit either because the download aborted e.g one time after 7:42 min and one time after 8:05 min. Maybe the limit is a dynamic one which depends on the degree of capacity utilisation of the server. I don’t know.

Maybe you should ask your hosting provider for help.

Regards,
Tim

Hi Tim,

Thanks so much for your feedback! The tests you’ve done, while musically inconclusive (you weren’t able to have a listen), are extremely helpful. I now have a better idea of what could be happening with my hosting provider, my configuration, or the file itself.

I’ve just split the file into two smaller parts (320 bitrate and around 190 mb each) and uploaded them to the server to see if they load properly or not.

I’ve also modified the 370 mb file to a lower bitrate, now it’s 192 and the file size is 220 mb (see the *technical update*).

I hope you can let me know if these two options work for you. I’m pretty sure the split version will be OK, but I’m curious to know about the smaller single file version.

If neither of these options work (which I highly doubt), I’ll contact Godaddy. But from what I’ve read online they probably won’t like the fact that I’m hosting large media files, even though my audience is quite (very?) limited…

Thanks so much for your help!

Jonathan

Hi Jonathan,

I have tried to download the low res file as well as the splitted version.

LowRes: The download stopped after 159 MB (incomplete download).
SplitVersion: I able download the first part (177 MB) but the download of the second part stopped at 156 MB (of 181 MB).

But after some further thoughts I have tried to download the Low Res file and the original file with real URL (and not the masked URL which you get when you use the podPress statistics feeature) of the file – with success. I could download the both files without problem. The download of the big took 19 minutes but it worked.
If you use the podPress statistic feature then podPress masks all media file URLs like this: the-gonzo.com/wp-content/ … /Gonzo-Live@BluJaz(29-10-2010).mp3 becomes the-gonzo.com/podpress_trac/web/477/0/Gonzo-Live@BluJaz(29-10-2010).mp3. This masking takes place only while this statistics feature is active. It is a redirect. If somebody clicks on such a link a function of podPress will be called. This function counts the click, assembles the original URL and gives that URL back. The download begins and the podPress involvement in the download ends. But only if you use the “Counts Only” or “Full” method. The “Full+” method tries to find out whether the download was completed or not. In order to do that the podPress script runs all the time while the download goes on. But this can trigger a problem because on most servers the execution time of a PHP script is limited. In my experience this time limit is often something between 60-600 seconds. (That would be consistent with my experience with the downloads of your files.)

Do you use the Full+ method?

If it is true then please switch to the Full method and write a short note. I will try the download once more after you have switched the method.

Regards,
Tim

Hi Tim,

I have to admit I wasn’t even aware I had such an option, I customized the player and its integrations into posts, but I just left the statistics options with their default settings. “Full+” was indeed activated and I have now gone to “Full” mode.

This doesn’t really change anything for me as an admin since all I really want to know is how many people have been interested enough to click on the “play” or “download” buttons. But as a user, being able to stream or download the full file determines any potential of returning (which is exactly what I do when I visit websites featuring musical recordings).

Anyway, I’ve changed the setting and hopefully this will fix the bug. If it doesn’t, then I’ll have to try “counts only”, and I’m even willing to disable statistics altogether…

Thanks again for your help!

Jonathan

Hi Jonathan,

I have downloaded the big file successfully. So you can use the “Full” method. The difference between “Counts Only” and “Full” method is not very big compared to the “Full+” method. There are practically no advantages in switching to that “Counts Only” method.

So you may leave the settings as they are now and you don’t need to split the files.

Since I started to maintain podPress I have wondered what the real problem of the “Full+” method could be. The explanation on the General Settings page of podPress is still to imprecise. But the fact that the downloads always stopped after nearly the same time span made me think about which script would run during the download.

Thank you for reporting this problem!
I would not have discovered the cause of this problem without your report.

I’m going to modify the explanation of the Full+ method and explain what the disadvantage of this method is or when it might be ok to use that method.

Regards,
Tim

btw: I’m listening your last podcast with 1PixelOut player to find if this player is able to play such big files. I guess that is no problem for the player. But I will report back in approximately 2 hours.

Hi Tim,

Yep, everything seems to be working fine now, from the streaming with the 1 pixel player to the download through “save as”.

Thanks so much for your help, I probably would’ve spent a lot of time on various radical solutions before realizing it was as simple as an overlooked option in the settings.

I guess I can put this under “resolved”?

The 1PixelOut player plays the big file without problems.

You have not overlooked a thing. The explanation of the Full+ feature was not very good and imprecise. It is not your fault. I had to look into the code of plugin to discover the different principle behind the Full and Full+ method.
But the explanation will be better in the next podPress version.

(I have marked the thread as “resolved”.)

Regards,
Tim

BTW: That is a fine set of music in this episode. I have enjoyed listing the whole file.

Hey guys,

Looks like you have had similar problems to me, but not quite.

Can someone please explain what is happening to my podcast. I use podpress and currently the MP3 can be played if I click on the download or the icon but if I click play it buffers and then just won’t start.

Anyone know why? check it out here https://www.superioronlinemarketing.com/social-media/multi-millionaire-nigel-botterill-exposes-business-secrets-and-social-media/

Thanks

@paygo:
Your case is different then the problem which has been discussed above.

I have downloaded your last interview and could reproduce the problem in my test blog. But the problem is not the size of that file. It is probably the way it was created. I have noticed that the ID3 tag detection had a problem with this file. Because of that I have converted the ID3 tags to ID3v2.2 with iTunes and added a title and an author name. That solved the problem. The Flash player plays the file and the ID3 detection does not throw an error-like message anymore.

Please, control the settings of your recording or authoring software (and try to add some meta information to the files).

Regards,
Tim

Hey Tim,

Thanks for the response. Only issues is your response went straight over my head. Can you tell me exactly what I can do. Do I need to convert the file to something else, then upload again to Amazon S3?

Thanks

How do you record your podcasts?
A software? Or are the mp3 files created by a recording device?

Either way there should be a possibility to add the name of the author and maybe some other meta data like the genre to the mp3 files. If there is no such possibility or if it does not solve the problem then you should use a tag editor software (e.g. iTunes) to add those information or to convert the the existing meta information block.

I have added your file to the media library of my iTunes software and mad I click with right mouse button on the file name, a menu have opened.
One of the points in this menu is “Convert ID3 tags”. If you choose this function then you will get a little window where you can choose the version number of the ID3 tags. Choose e.g. 2.1 and click “Ok”.
(You can reach this “Convert ID3 tags” also via the Advanced menu)

Regards,
Tim

see https://serato.com/howtos/itch/2481/how-to-strip-and-convert-id3-tags

Ok not sure what was wrong but I reloaded the mp3 into Audacity and saved it and now it works fine, so cheers heaps Tim.

One more question I have, is that it now works, but not sure if it is counting up the downloads like it was before like a stat counter.

Not a biggie, but not sure why that would stop? I have the box checked under Podpress settings.

Thanks again

I’m glad that your file is working. The player plays the file now and it is also possible to download the file. That means the redirection and counter mechanism of podPress should work as before.
Please, write down the current numbers, wait maybe a day and compare the numbers.

I have clicked on the download link and the player just a moment ago. The web (+1), play (+1) and total (+2) number should be increased.

Furthermore I recommend the method Full. Counts only should of course also work. If you are using Full+ then please switch to Full.

Regards,
Tim