It isn't the hosting service for the feed which matters, but that for the episode media files. Your top episode's media file URL is
When entered in a browser, this downloads - that's not going to work, you need a direct URL to the mp3 file and it should play in a browser, not dowload (as well as being on a server which accepts byte-range requests).
The URL above redirects to another URL, but as it downloads the URL disappears to quickly to see what it is. The server your media files are on is not configured properly to serve mp3 files.
The top episode's media file now plays correctly in a browser, though it's still a redirect - I don't know whether that is any sort of issue. But I'm afraid I can't advise any further on byte-range requests - if the Store is saying your server doesn't have it and the people running your server say it does (though I can't say whether the log you quote in your first post actually proves that it does) then the only thing I can suggest - which you don't want to hear - is that you find another hosting service, specifically asking them to confirm that they do handle it.
OK thanks for your help anyway Roger.
According to this page here they do support redirects and considering this is Feedburners way of counting hits I can't imagine its not supported by Apple:
I just thought I'd update this thread with more information as I have spent quite a while looking at this problem and I think this info may help other people. As I stated in my original post, my hosting provider does support byte-range requests. After spending a good couple hours adjusting and retrying the submission with different versions of my feed I noticed this error message is erroneous!
iTunes seems to throw this error randomly. First I noticed it gave the error when I had a typo in my feed which made the enclosure URL invalid (it returned a 404) but iTunes still gave the "byte-range requests" error. I then noticed sometimes iTunes would accept the feed and sometimes not. Then I worked out once I get the error I could just click the "continue" button repeatedly and then after 3-10 times it would accept the submission. Stupid!
So in summary, if you are sure your hosting provider supports byte-range requests and you still get the error, just retry. You can check if your provider supports it by using the command in my first post and see what HTTP headers are returned. The ones in bold should indicate that your provider supports it. The curl command is not on Windows but it is on Linux and I think it is on OSX.
I hope this helps someone!
Interesting. This is the result of your curl process with one of my episodes, hosted on GoDaddy:
curl -I -r 200-300 http://rfwilmut.net/podcasts/Soundof78s36.mp3
HTTP/1.1 206 Partial Content
Date: Fri, 31 Aug 2012 15:31:14 GMT
Last-Modified: Sat, 02 Jul 2011 07:44:11 GMT
Content-Range: bytes 200-300/10720154
Would you read this as meaning that GoDaddy do accept byte-range requests? - because it seems to be generally nbelieved that they don't.
Given what I've read about byte range requests, I would say that particular file on that particular host can be downloaded using a HTTP 1.1 byte range request. I don't know anything about GoDaddy or what their policies are.
Here is an example of a server that does not allow byte range requests, it returns a 200 status code:
$ curl -I -r 200-300 http://img1.wsimg.com/fos/hp/1/86462_background.jpg
HTTP/1.1 200 OK
Last-Modified: Tue, 24 Jul 2012 21:10:50 GMT
Date: Fri, 31 Aug 2012 16:57:21 GMT
This file is part of the GoDaddy homepage.
If anyone is interested here is some more reading...
(Scroll down to "10.2.7 206 Partial Content")
I could still be wrong but from the reading I've done I'd say if you receive a 206 you are good
BTW you're a star with the amount of support you give in this forum!