iTunes 8006 errors- completely mystifying

Several posters have complained of this in other forums without getting any very definite answer. I got the same thing with your latest episode.

You are using Google FeedProxy to serve your episodes. he URL in the feed is

http://feedproxy.google.com/~r/ImperialTrouble/~5/3rrbYNxma78/Imperial%20Trouble %20Episode%2037.mp3

This redirects to http://imperialtrouble.com/podcasts/Imperial%20Trouble%20Episode%2037.mp3

(The '%20' code is to cover the fact that you've got spaces in the filename, which you shouldn't have: however th use of this code should handle it.)

This redirect works OK in a browser and plays the file, but there is a bit of a delay before the redirect. Although these redirects sometimes work in iTunes they can cause problems, and it may be that the delay is timing out iTunes. It would be better to give the actual URL of the file in the feed.

I just tried subscribing to the feed again in iTunes. I tried to download several episodes: each one started downloading for a split second then gave the error. In a browser I get the redirect - actually it appears to be a double one, though it's very quick, but it looks as if there is another URL between the link and the actual file URL. Then after spending a few minutes I subscribed afresh and it worked.

A large number of people have complained over a period of some years of this error: of course it may be a catch-all 'unknown' error and they don't all have the same problem. Several people found re-subscribing solved it: once person had an incorrect URL (which doesn't appear to be your case) and so on. Redirections arose as a possible issue several times.

I can't give you a hard and fast answer. Personally, I'd be suspicious of redirects, particularly double ones. Something in the process may be falling over for iTunes, which isn't as robust as a browser when there are problems. Personally I'd always advise avoiding them, which may not be of much help to you - but you could try changing the feed to the direct URL of the file on at least the latest episode and see whether it settles down.

I just tried subscribing twice and it worked OK both times, so I don't know what's going on. Possibly the redirect is a bit slow sometimes and this times iTunes out - though when I've seen it not work the timing seems too fast for that.

The only suggestion I can offer is one you don't want to hear - stop using Feedproxy and link directly to the mp3 file.

I can't answer why it worked originally and now doesn't. I wasn't suggesting that you stop using Feedburner: I was suggesting that you stop using FeedProxy and just put the actual URL of the media file in the feed. I assume that you were using FeedProxy in order to get usage statistics, which you won't get by using the direct URL, which is why I said you probably didn't want to hear this. However, though you will understand that I'm running on guesswork here, it seems possible that the most likely cause of the problem is the use of FeedProxy.

I would suggest you change the URL on the latest episode for a start, and see whether it improves matters.

The first time I tried subscribing in iTunes it didn't work, even now you have the direct URL: the second and third times it did. The file can be played in Safari or FireFox perfectly well.

The space/%20 issue shouldn't be a problem: I've seen it work OK elsewhere (it's when there are spaces in the URL in the feed it falls over).

So, guesswork: the only thing I can think of is that your server is responding to requests from iTunes in a different way to the way it responds to requests from browsers - I have seen something like that happen - but is doing it intermittently. If you can approach the people who run your server with the details they may be able to say whether that's a possibility.

I don't think it's anything to do with the feed, which as far as I can see is perfectly OK, so I shouldn't waste effort chasing that.

It would seem to be something not working between iTunes and the server for your actual file (rather than FeedProxy as I originally suspected); unfortunately it's outside my competence to offer any explanation. The only other suggestion up my sleeve at the moment is to try hosting one episode on a different server, if this is at all possible. For example if you know someone with their own webspace on a different server and can persuade them to host the episode temporarily so you can see whether that works.

As it happens my podcast is on GoDaddy and there's no problem there, which tends to confirm what they said.

Here's another wild guess. Make a new mp3 file of your latest podcast, but make sure not to embed an image into it (the present one does have an embedded image). Upload that to the server to replace the existing one and see if that works.

There is actually a reason for suggesting this: I downloaded your episode and opened it in QuickTime 7. The Inspector window showed some lines of code in one of the fields, which I guess maybe from your image - this shouldn't be happening, and suggests that there is something odd about the way the image has been embedded. As I say, we're at the guesswork stage, but try the substitution. If it works OK then that lends weight to my latest wafer-thin theory.

'When you have eliminated the impossible, whatever remains, however improbable, must be the truth.'(Sherlock Holmes).

I was able to have a closer look at the file, and what I saw was in the Comments field, which reads

0000041E 0000043D 00005AB0 0000595E 00287B40 00287B40 00008000 00008000 0035BAA0 0035BAA0

I've no idea what's that about, but wouldn't have thought it could have caused any problems. What we've see does suggest some oddity in the construction of the file, but I can't see any actual evidence to suggest this is the case or what it might be.