SmartCast refusing to make enclosure for audio file (though it recognizes it as an audio file)

[JJ Sonick]

Hello, for the most recent episode of our podcast "Bite Club Show", ep. 124, the Feedburner SmartCast service is refusing to make an enclosure for the mp3 file.  I know that usually this is a case of the host server (in this case, archive.org) mis-reporting the content type of the mp3, as a text file for example.

BUT in this case, the mp3 is correctly being reported as content "audio/mpeg" by archive.org (as shown in the Feedburner Troubleshooting screen for the feed), but SmartCast nonetheless reports "Media enclosure not created because: The content type returned from your hosting server was incorrect for your SmartCast settings.", even though it's set up to make enclosures of audio files, and has been doing so without problems for all our previous episodes.  It also shows an additional error, displaying the feedburner link to the full ep 124 html post and complaining that this html (!) link is "a text type, not a binary media type."

Here is the full feedburner error from the Troubleshooting panel:

"Content Item: "BiteClub Episode 124 - The Vampire Diaries Recap: Before Sunset"

• Link: http://www.podtrac.com/pts/redirect.mp3/www.archive.org/download/BiteClubEpisode124/Bite_Club_124.mp3
  Content Type reported: audio/mpeg
  Media enclosure not created because: The content type returned from your hosting server was incorrect for your SmartCast settings.

• Link: http://feedproxy.google.com/~r/BiteClubPodcast/~3/hsJNlVQ8No0/biteclub-episode-124-the-vampire-diaries-recap-before-sunset.html
  Content Type reported: text/html;charset=UTF-8
  Media enclosure not created because: The content type returned from your host server was a text type, not a binary media type. Podcast content should always return a binary media type, such as audio/mpeg for audio, or video/mpeg for video."

I can't find any HTML error in the ep 124 post itself, but maybe I am missing something.  The coding of the link in the ep 124 post is identical to the coding in previous (correctly enclosed) podcast posts, so it really seems like an error on the SmartCast side. Here is the post:
http://www.biteclubshow.com/imported-20100117015857/2012/5/6/biteclub-episode-124-the-vampire-diaries-recap-before-sunset.html

and ep 123 for comparison:
http://www.biteclubshow.com/imported-20100117015857/2012/4/27/biteclub-episode-123-the-vampire-diaries-recap-s3-ep-19-20.html

You can also compare the ep 124 mp3 on archive.org:
http://archive.org/details/BiteClubEpisode124

with the ep 123 mp3 on archive.org:
http://archive.org/details/BiteClubEpisode123

No differences I can see in the archive.org metadata that would cause 124 not be enclosed, while 123 gets enclosed.

Again it seems like SmartCast is incorrectly refusing to enclose what it's set to enclose.  I checked in my SmartCast settings to make sure, and yes, it's still set to "audio files only" for making enclosures.

The mp3 links in the episode posts include podtrac re-directs (for tracking) and I thought this might be messing the link up -- but, again, all the previous posts also have the podtrack re-direct in them, and are still being properly enclosed.  If something was wrong with podtrac, wouldn't it be effecting all the podtrac-redirected mp3 links?

For example here is the podtrac-redirected, not-being-enclosed ep 124 link:
http://www.podtrac.com/pts/redirect.mp3/www.archive.org/download/BiteClubEpisode124/Bite_Club_124.mp3

Here is the ep 123 link:
http://www.podtrac.com/pts/redirect.mp3/www.archive.org/download/BiteClubEpisode123/Bite_Club_123.mp3

Nothing is different but the destinational mp3, and all other podtrac-redirect mp3 links are being properly enclosed, so podtrac doesn't seem the likely problem.

Suggestions?

Much Thanks,
JJ

[JJ Sonick]

On closer inspection, there was a bit of messy HTML in the post (unclosed <p> tags and unnecessary <spans>s), apparently from the Square Space WYSIWYG editor.  What's weird is similar messiness have been in previous posts and haven't caused issues with enclosures, it must have been some special combination that did it in this case.  Anyway, cleaning that up seemed to make SmartCast happy again, enclosure made - case closed.

[敬杰 李]

Please refer to the :http://www.ytfoam.com

On 5月9日, 上午2时18分, JJ Sonick wrote:
> Hello, for the most recent episode of our podcast "Bite Club Show", ep.
> 124, the Feedburner SmartCast service is refusing to make an enclosure for
> the mp3 file.  I know that usually this is a case of the host server (in
> this case, archive.org) mis-reporting the content type of the mp3, as a
> text file for example.
>
> BUT in this case, the mp3 is correctly being reported as content
> "audio/mpeg" by archive.org (as shown in the Feedburner Troubleshooting
> screen for the feed), but SmartCast nonetheless reports "Media enclosure
> not created because: The content type returned from your hosting server was
> incorrect for your SmartCast settings.", even though it's set up to make
> enclosures of audio files, and has been doing so without problems for all
> our previous episodes.  It also shows an additional error, displaying the
> feedburner link to the full ep 124 html post and complaining that this html
> (!) link is "a text type, not a binary media type."
>
> Here is the full feedburner error from the Troubleshooting panel:
>
> "Content Item: "BiteClub Episode 124 - The Vampire Diaries Recap: Before
> Sunset"
>

>    -
>
>    Link:
>    http://www.podtrac.com/pts/redirect.mp3/www.archive.org/download/Bite...

>    Content Type reported: audio/mpeg
>    Media enclosure not created because: The content type returned from your
>    hosting server was incorrect for your SmartCast settings.

>    -
>
>    Link:
>    http://feedproxy.google.com/~r/BiteClubPodcast/~3/hsJNlVQ8No0/biteclu...

>    Content Type reported: text/html;charset=UTF-8
>    Media enclosure not created because: The content type returned from your
>    host server was a text type, not a binary media type. Podcast content
>    should always return a binary media type, such as audio/mpeg for audio, or
>    video/mpeg for video."
>
> I can't find any HTML error in the ep 124 post itself, but maybe I am
> missing something.  The coding of the link in the ep 124 post is identical
> to the coding in previous (correctly enclosed) podcast posts, so it really

> seems like an error on the SmartCast side. Here is the post:http://www.biteclubshow.com/imported-20100117015857/2012/5/6/biteclub...
>
> and ep 123 for comparison:http://www.biteclubshow.com/imported-20100117015857/2012/4/27/biteclu...

>
> You can also compare the ep 124 mp3 on archive.org:http://archive.org/details/BiteClubEpisode124
>
> with the ep 123 mp3 on archive.org:http://archive.org/details/BiteClubEpisode123
>
> No differences I can see in the archive.org metadata that would cause 124
> not be enclosed, while 123 gets enclosed.
>
> Again it seems like SmartCast is incorrectly refusing to enclose what it's
> set to enclose.  I checked in my SmartCast settings to make sure, and yes,
> it's still set to "audio files only" for making enclosures.
>
> The mp3 links in the episode posts include podtrac re-directs (for
> tracking) and I thought this might be messing the link up -- but, again,
> all the previous posts also have the podtrack re-direct in them, and are
> still being properly enclosed.  If something was wrong with podtrac,
> wouldn't it be effecting all the podtrac-redirected mp3 links?
>

> For example here is the podtrac-redirected, not-being-enclosed ep 124 link:http://www.podtrac.com/pts/redirect.mp3/www.archive.org/download/Bite...
>
> Here is the ep 123 link:http://www.podtrac.com/pts/redirect.mp3/www.archive.org/download/Bite...