Currently Being ModeratedApr 5, 2013 5:10 AM (in response to jeffrey allan j)
You can ignore both 'errors' in FeedValidator. The first doesn't matter, and the second is only relevant to the 'Atom' feed reader (which possibly no-one uses any more). In any case it's not the feed which could cause these issues, but problems either with the server or with the file itself.
iTunes is in fact using the feed from the URL without the www, but apparently both point to the same file anyway. I was able to subscribe and download the latest episode using a Mac and played it for ten minutes without any problems, so I can't suggest what the issue may be where Macs are concerned.
However you are likely to have problems with an iOS device (though it's not something I can check): your server does not appear to handle 'byte-range requests' (where only part of the file is requested at a time, rather than the whole file) - this method is used by iPhones and servers which don't handle this won't serve the file properly to these devices. (I tested for this but I don't guarantee the result 100%.) The only solution for that is to get your server set to handle this, or find another hosting service.
Thank-you for your quick response. It looks like you help a lot of people on here!
Anyways, I called our hosting company, and they said that they do support the byte range requests, but it is a feature I have to activate on my end. They said it is done in the htaccess file but I cannot find that file. Actually, they couldn't even find that file.
I'm at a loss. I don't know how else to do this. The tech support suggested I create an htaccess file, and drop it in the root folder, but that's way above my head... let alone knowing what kind of code to write to enable byte range requests.
Do you have any other thoughts on this? Once again, thank you for your help.
ALSO - I just had an idea for a possible workaround:
I already pay a monthly fee for a nice big chunk of data space on my DropBox account. What if I moved all my podcast media from our web hosting server to my publicly accessible DropBox folder, and updated all the links to those files in my podcast.xml file?
Do you have any recommendation to hosting podcast media files (not xml file) on DropBox? In other words, have people found success in hosting their podcast media on DropBox?
Thanks again for your help?
Currently Being ModeratedApr 5, 2013 2:08 PM (in response to jeffrey allan j)
Dropbox is not a good idea - we've seen a number of problems arising from its use. I would advise not risking it.
Your hosting company's idea that you have to enable byte range requests is ridiculous. I should find a hosting company that behaves itself. The htaccess file is an invisible file at root level of the server (or of a specific folder) and can be used to force dowloads or impost password protection. Unfortunately I can't advise you on how to use it to enable byte-range requests, and a quick Google search produced nothing useful.
Currently Being ModeratedApr 5, 2013 2:35 PM (in response to jeffrey allan j)
Please take a look at libsyn.com for your podcast hosting needs.
It is 100% itunes complaint - is fast and easy to set up.
It is what most of the big podcasts in iTunes use - Marc Maron, The Nerdist, Happy Tree Friends, The NFL.
Let me know if you have any questions about libsyn.
rob (at) libsyn (dot) com
Thanks for the tip. I actually looked into libsyn earlier today (out of my frustration). Problem is that we like to archive at least 2 years worth of messages.
With one message per week amounting to approx 35mb per message, that opens us up to a cost inflation beyond our capacity. I know 2 years is a lot, but we have a lot of visitors to our church that find us online, and like to go through a bunch of previous messages.
Mind you, if I cannot resolve this issue, I will have to revisit our mandate to archive so many episodes, and look at a paid service like the one you recommend.
Currently Being ModeratedApr 5, 2013 8:54 PM (in response to jeffrey allan j)
With libsyn - the pricing plans are based on new uploads in any 30 day window. Once a file is over 30 days old it no longer counts against your upload quota and is moved to Archive - which just means it no longer counts against your upload quota. The file will contine to download as long as your account is active and there is no need to remove files from your account ever. I have files in my own account that are now over 8 years old.
This link goes over the libsyn storage in greater detail.
At 35 MB per message you are looking at having 5 files at most active in your account in any 30 day window. So the Classic 250 plan ($15 a month) would be more than adequate for your needs.
Again let me know if you have any questions per my email above.
Rob, just to clarify - when most other services move an episode file to the archive it gets removed from the feed, but I take it that is not the case here? So that after the 30 day window the files aren't counted in the costing but the episodes still appear in the Store and for subscribers?
With libsyn - your episodes are NOT removed from the feed when they go to "archive".
So correct - the only thing that changes at the 30 day mark for an episode is that it is no longer counted against your quota. The File URL stays the same, it continues to download just as fast as before, it remains in your feed for as long as you want it up there.
I have all my episodes still on my feed for both my podcasts I host with libsyn. One going back 8+ years - the other going back 6 years.
Thanks again for the tips... this time on avoiding DropBox and pushing back on the Hosting company to get better answers.
I was emboldened to call them back, and have a deeper discussion about the "byte range requests." After re-visiting the problem with the tech support, they decided to create a ticket for me and look into it further. They stated to me that byte-range requests should be on by default, but in our case it wasn't, and they would investigate.
If I cannot get this resolved with them, I will likely look for a separate server to host our podcast media files... which leads me to a question that branches off the original issue: After pouring through some forums looking for help, I've found a number of suggestions that advise to NOT host the podcast media on the same server as your website (which is our current scenario). Have you come across this idea before, and if so, what are you thoughts toward it?
Once again, many thanks!
Currently Being ModeratedApr 6, 2013 8:00 AM (in response to jeffrey allan j)
jeffrey allan j wrote:
... I've found a number of suggestions that advise to NOT host the podcast media on the same server as your website (which is our current scenario). Have you come across this idea before, and if so, what are you thoughts toward it?
I can see no point whatever in doing this. It's what I did, and a lot of people, and I've never seen it as the source of any problems. Or you can just as well place the media files elsewhere. As long as the servers are serving the files properly it makes no difference at all.