Podcast Preview doesn't work

Preview playback is working for me on the iTunes web listing for your podcast but it's not working inside the iTunes application itself. Your RSS feed is valid so that shouldn't be an issue.

I tested out a few other shows just to see if their preview players are working and they were tine. So, it wasn't just an intermittent problem on my end when yours didn't work. It's hard to say for sure what might be causing your problem but it may simply have to do with the speed of the server that's delivering your media. If your files are really large and/or your server's bandwidth isn't very high, it may just be that it's taking too long for iTunes to download your media and play it back properly in preview mode.

Checking your top episode, it can be downloaded, and it plays in a browser without a download being forced (which is correct). However it won't play in the iTunes Store within iTunes, and it won't play without downloading when subscribed in iTunes - however it will play on the website version of the Store page. It did take a bit of time to get started on the web page, but I gave it quite a long time in the Store and though there was some network traffic going on it never did start. The file size isn't excessively large at 58MB.

The media file URL given for this episode is

http://media.blubrry.com/timelineradio/www.merkandkremont.it/podcast/episodes/TM L033.m4a

There is a 302 redirect in place which redirects to

http://www.merkandkremont.it/podcast/episodes/TML033.m4a

It looks as if your server is not responding to requests for 'streaming' - this is outside my knowledge, but in a browser I believe it simply starts downloading the file and plays once a sufficient amount has been downloaded to act as a buffer. The other methods may be different, though whether they are literally streaming in the true technical sense I wouldn't know. It's probably something you will have to take up with the people running your server. It's possible that the Store and iTunes don't like the 302 redirect when it comes to playing rather than downloading the file - it might be worth trying your using the actual URL rather than the blubbry.com one and seeing whether that works. If it does, then it's probably the redirect. (302 is a 'temporary redirect' - the more common one is 301, which is a permanent redirect.)

Michael,

The preview did work for me, but I had to wait about 50 seconds for it to start.

I think your issue may be related to your server not offering byte-range serving. You can read about the requirement here:

https://www.apple.com/itunes/podcasts/specs.html

Post the RSS feed, cover art, and your episodes on a server that supports byte-range requests and a publicly accessible URL. Support for byte-range requests allows users to stream your episodes.

I believe your web server doesn't offer byte-range serving of content. You can test it using this command on a Mac:

curl -H Range:bytes:16- -I [LINK TO FILE]

I've pasted the results below. In the second line, you want it to say "HTTP/1.1 206 Partial Content".

curl -H Range:bytes:16- -I http://www.merkandcast/episodes/TML033.m4a

HTTP/1.1 200 OK

Date: Sun, 17 May 2015 22:57:43 GMT

Server: Apache

Last-Modified: Fri, 15 May 2015 15:46:05 GMT

ETag: "37ccf51-51620bdff00ac"

Accept-Ranges: bytes

Content-Length: 58511185

Vary: User-Agent

Notice how it said "HTTP/1.1 200 OK"? I think your server is only willing to send the WHOLE file (and thus my computer has to download the whole file to preview it). If your server supported byte-range requests, the iTunes page would only download the first small portion of the file and start playing right away.

Would you check with your host and ask them if they support byte range serving of files and let us know?

The test you have applied isn't the same as what I understand to be the normal and I don't know enough to say whether it's valid. (Incidentally the URL in the results you quote is incorrect - you've left the .it off - though the overall file size appears to be correct) .

The test I use indicates that the server is indeed accepting byte range requests:

curl -I -r 200-300 http://www.merkandkremont.it/podcast/episodes/TML033.m4a

HTTP/1.1 206 Partial Content

Date: Mon, 18 May 2015 06:33:25 GMT

Server: Apache

Last-Modified: Fri, 15 May 2015 15:46:05 GMT

ETag: "37ccf51-51620bdff00ac"

Accept-Ranges: bytes

Content-Length: 101

Vary: User-Agent

Content-Range: bytes 200-300/58511185

If the server didn't accept these the podcast wouldn't have been accepted in the first place (though that wouldn't apply if the submission was long enough ago to be before Apple made this mandatory).

In any case, the byte range request issue applies only to iOS devices. It shouldn't affect behaviour in iTunes. It's very odd that the web page version of the STopre page works OK, but neither the Store or the iTunes applications; this suggests that there is something specifically upsetting those requests. I would guess that either the server is not responding to requests from iTunes or the iTunes Store, though it does when the request comes from a web browser - I've seen this sort of issue before, though usually affecting the access altogether, not streaming as opposed to downloading - or that the 302 redirect (which is not usual, commonly a 301 is used) is causing problems: I don't know enough about servers to know whether this might be an issue, but in any case one can assume that Blubrry use this elsewhere and wouldn't do so if it routinely caused problems.

The request from a browser, which would include the web page version of the iTunes Store, may differ from when the request comes from the Store or from the iTunes application on your computer. I've seen cases where a file would play in a browser but neither play nor download in iTunes, suggesting that this may be the case and some servers may not respond to iTunes. Normally there is no distinction between downloading and playing (I don't know whether it is actually 'streaming' in the true technical sense) but again there may be sufficient difference to upset your server. If your server limits streaming then that could well be the problem, and may in the end result in your having to find another server.