A new conundrum for podcasters: web host data transfer limitations
I discovered by way of a very stressful and unexpected think tank session a new problem that I believe many podcast producers are going to confront eventually. The local company that hosts my site's media content (which resells space from a third-party host provider's server, separate from
my public web stuff) informed me today that my site was the single culprit causing a huge server bottleneck. This was due to extremely high data transfer levels from my webspace, leading to reduced performance for the other sites hosted on the server I share.
I instantly knew this without doubt was due to my podcasts.
First, understand that I started podcasting using a model which I thought was clever, deviating slightly from the general RSS-based model. I launched my company's podcasts three weeks ago by offering a digital music delivery service, featuring 15 copyright-free songs from local musicians available at
http://music.kuam.com. The MP3s were freely distributed under a release agreement with the artists, and could be downloaded from said URL, in addition to being available via
the corresponding RSS feed for those already preferring the podcast format. The hook (or so I had intended) was that people could right-click and download tracks to their machine, and then learn about the magic of podcasting by subscribing to the RSS feed, which provided additional free tracks, not available merely over the Web.
My station produces four podcasts in all:
a three-times-daily newscast,
my daily talk show,
and a weekly sportstalk radio show, in addition to our music service. The music service was the only podcast being offered both over the Web and on RSS; the others are exclusively RSS. And although we've only been podcasting for less than a month, my traffic logs show us passing an astounding 13.3 GB of data...per day.
I've since learned that many people weren't downloading the files in the traditional manner, loading the music in their web browser's embedded media player for playback rather than saving the files to their drives for later use/reuse. And my server traffic logs indicate that the same people did this continually, for the entire set of songs. As a result, we've had our music MP3s accessed over 11,800 times, but not necessarily downloaded. By all the same people.
I've learned a lot from this.
Thus, my experience brings to light a new conundrum I believe people like me who really believe in the future of podcasting are going to unfortunately run into: bandwidth and data transfer limitations brought about by severe traffic loads, resulting in increased costs. This will hurt the medium by restricting many people's potential output, and impose additional charges largely unforseen by service providers.
Dion, who runs
KISSPodcast.com, shares my projection. He sees this potentially happening to his site, now in its third episode but already rapidly expanding in popularity, as more and more of his content is put on the Internet. More files available for download means more traffic as more people access them, which severely inflates the allowed amount of data transfer. Most web hosting companies don't account for such huge traffic swells and provide for a set monthly data transfer, applying additional charges thereafter. As an example, my web site is allowed 25GB of data per month, at this rate, I'd far surpass that level by halfway through Tuesday. In my case, proposed moving my stuff to a different server or service provider. Which was the worst suggestion they could have made, given my growing audience and already-in-place marketing push promoting our content.
I realize in retrospect that offering web-downloadable MP3s may not have been the most responsible thing to do in terms of using server space, bandwidth and traffic. And this is especially for a site like mine, which is hosted by a third-party provider, instead of internally; and further, hosted on a shared server, as opposed to a dedicated one. So to manage the load, I removed the ability for people to download files from the public Web and transitioned users to accept the RSS feed as the exclusive delivery mechanism. We'll see how this plays out in terms of traffic, throughput and bandwidth consumption, but I can already tell you this is going to return things to normal. So my host is happy, and indirectly, so do are other clients on the server.
With the optimal distribution for podcasts being in archival - MP3s placed and kept online for long periods of time - it doesn't make sense to constantly upload and then delete MP3s (which often for use in podcasts can be large, often around the 30-45MB range) just to stay within a space limitation or to self-regulate a server's aggregate load. We need to have our stuff online into the future for people to enjoy. This new medium can't be temporal. I want a backlog of stuff I've done and see other people's body of work grow over time.
But at the same time, this doesn't allow me to design my services in the manner that I'd like to, and come up with something neat. It was a pretty cool digital music delivery service which the artists and people really enjoyed using. It sucks that as we continue to get more and more successful I have to have less and less content available.
So lay blame to whomever you wish: my host, my users, me. This ultimately will cost someone, with more resources needed to provide an expanding base of content.