iTunes and other locations not updating audio for new podcast, but updates show

Duplicate post might be the issue if it does not generate a fresh GUID for the new post it creates. From looking at the feed I do not see that issue though.

You’ve written a lot, but it is unclear exactly what the problem is. IS it that you release an episode then change the descriptions and the new descriptions are not getting syndicated? I’ve checked Blubrry, Apple, TuneIn, and Stitcher and I see all of the episodes so I think perhaps I am missing exactly what the problem is or perhaps it has resolved itself in the past couple of days?

Blubrry has 2 listings, more than likely Blubrry added your podcast when you submitted it to iTunes, and perhaps around the same time you also added the podcast to blubrry. The submission process should have asked you if your podcast was already listed on Blubrry if we found the exact same title in our directory. IF you were changing the program title throughout all of this, ever so slightly, that may have allowed the same podcast to be added to the directory twice. If there was a different feed URL used as well, it would have allowed the listing to be added twice, such as a FeedBurner URL. If you claim one (if you have not done so already) and then contact us and request the other duplicate to be removed we’ll take care of it right away. UPDATE: It appears the duplicate was already removed.

FeedBurner can cause issues. If the podcast directory is using the FeedBurner URL and it is not updating promptly, you can have exactly the issue you describe, a delay on syndication. I looked up your podcast on iTunes however, and it is pointing to https://charlescarrollsociety.com/feed/podcast so that should not be an issue.

Are you still having issues?

@ab11936,

I wrote a reply earlier but it is not appearing, hopefully if it got caught in some moderation queue it gets approved.

Everything looks fine now on Blubrry, iTunes, Stitcher and TuneIn. Are you still having problems?

It is possible if the program title and/or the RSS feed URL changed recently that Blubrry discovered a 2nd podcast which which lead ultimately to a duplicate listing.

[Moderator note: Your first reply got caught in the spam filters. ?? ]

• This reply was modified 8 years, 5 months ago by Steven Stern (sterndata).

Thanks @sterndata!

Thank you for your response.

Problem statement. After much troubleshooting I suspect that Duplicate Post version Version 2.6 is having an issue with Blubrry Version 7.0.2 when running “on” WordPress 4.6.1. That bug shows it self that if you “duplicate” a previous podcast episode, the show notes and episode title is updating accurately. However the actual media associated with the new episode is pulled from the “previous” post.

The problem statement said another way is: I have noticed sometimes (it may be happening all the time, but I only notice sometimes) when I publish a new show, the episode title will update, a “new” episode will be created with new show notes. However even though it says it is playing the 05-2016.mp3 it is actually playing the previous show 04-2016.mp3. After spending the last four days walking down public troubleshooting steps across all of these platforms it “feels” like Blubrry is referencing “something new” of the post for some of the information. Thus it publish new “copy” or notes and titles, but it is referencing the old media file perhaps because of Duplicate Post GUID or something. Thus various publishing platforms (iTunes, Stitcher, etc.) see the new show notes, but when they download the actual media it is the previous week. Duplicate post is the prime suspect, but we don’t know it is them.

You can see evidence of this at bug at Stitcher. If you look at the CCS Show Page on Stitcher https://www.stitcher.com/podcast/bard-of-the-american-redoubt/the-bard-of-the-american-redoubt?refid=stpr you can see that the last podcast is listed as #05-2016 (title updated) and the previous podcast is listed as #04-2016. However they have the exact same run time of 76 minutes. The actual media for 05-2016 is actually 04-2016. You can listen to them and confirm if you like. For some reason Stitcher is getting the new “meta data” of the show, including the name “#05-2016” but it is actually playing old an old media file if you either listen to it, or see its run time. BTW, I have recently updated the last show to remove the leading hashtag, so the current episode is 05-2016 not #05-2016. I did that so I can easily see which are pulling current information. Stitcher and Tunein are still broken. Blubrry and iTunes are fixed.

In working with iTunes I found most likely a significant cause of the issue for them. WordPress has its “own” feed in Jetpack or something (I am using version 4.3.1). For me that feed is https://charlescarrollsociety.com/category/podcast/feed/. That is the feed they were using. I guess when I was moving from Google’s Feedburner to Blubrry I must have tried to simply use Jetpack for awhile and forgot to update iTunes. Perhaps Blubrry was updating “all feeds” and thus I never noticed. But it does not update perfectly. I will give you an example of issues between Jetpack and Blubrry. In my settings in WordPress I say display the last 3 episodes. This is used by in Jetpack / WordPress to display the “related posts.” However in Blubrry I asked it to display the last 10 episodes of podcast. Even though I told Blubrry to update “all feeds” if you check https://charlescarrollsociety.com/category/podcast/feed/ it is set to only display 3 shows. However again, this is OBE for me because I have simply told people to stop using the old “WordPress managed feed.” I would like to know how do I delete that “WordPress managed” feed. I would like it gone to remove variables. I cannot find a way to “remove” that feed.

What I did was ask iTunes (very easy to work with BTW) to use the podcast specific feed Blubrry “manages” for me that is https://charlescarrollsociety.com/feed/podcast. Once they did that everything came out fine. I put in a 301 redirect from https://charlescarrollsociety.com/category/podcast/feed/ to https://charlescarrollsociety.com/feed/podcast/ to maintain subscribers.

Thus to sum this Wall of Text up:

1. There is a bug where you get new “show notes” but play “old media.”
2. This may be an issue between Duplicate Post and Blubrry.
3. There may be an issue between Blubrry and Jetpack / WordPress management of feeds.

I am still having the problem with Stitcher and Tunein. iTunes and Blubrry appear to be fixed.

[moderator note: this got stuck in the spam filter, too. eventually, akismet should figure it out. ?? ]

• This reply was modified 8 years, 5 months ago by Steven Stern (sterndata).
• This reply was modified 8 years, 5 months ago by Steven Stern (sterndata).

I wanted to pass on my workaround to this issue to whoever may come after. I am unsure when it will be resolved or if my theory is actually the root cause.

1. I do not use Duplicate Post (ver 2.6) for podcasts. I actually create a new podcast post each time.
2. I have installed Simple 301 Redirects version 1.07 and redirected my “default” Jetpack / WordPress feed https://charlescarrollsociety.com/category/podcast/feed/ to the Blubrry managed feed of https://charlescarrollsociety.com/feed/podcast.
3. I have asked all distribution platforms to use the Blurbrry managed feed. The redirect appears to have kept my subscribers.

A couple of things I notice

a. I have long used SSL (https). Everyone should use it. When you ride bareback you ride with the NSA. It now appears that all of my distributors can work with an https RSS podcast feed.

b. A _media file_ that is protected by https does not seem to work. First it does not validate using https://www.feedvalidator.org. The error code says “not a valid URL” which I could not understand at 0200 in the morining after coming home from the first job, the kids homework. I was looking at it and it I could not see why, then I saw it. Even though it does not validate Blubrry and iTunes still play the media file as normal. Google Play Music, Tunein and Stitcher appear not to be able to find the media file, and the episode does not show up. When I leave the feed as URL as https, but change the media file to HTTP it seems to work across all platforms. From this observation it is my theory that Google Music Play, Tunein and Stitcher do not support media files with SSL protection while Apple iTunes and Blubrry do. This means when putting the URL into the Blubrry editor box that appears under your podcast post, you must remove the “s” in https and only use “http” to ensure these other platforms will download your show.

c. Also, it appears each platform only “polls” your feed at certain times. It appears that iTunes and Blubrry polls a lot, like multiple times a day. It appears Stitcher is on the other side of the scale and only polls it once. For example while everyone has my new podcast release two days ago, because I changed that podcast (from https to http) Stitcher still does have the new episode.

On a scale of 1 to 10:
iTunes podcast support gets a 10
Blubrry gets a 5 sorry the response here has been very slow
Tunein gets a 4
Stitcher gets a 3. They are slow and stuff is still not fixed.
Google Play is unrated as I have not used their tech support.

Good luck and keep working to make the legacy mainstream media old news!

Your last comments were flagged by www.remarpro.com spam filters and thus we never got an email notification for them. In the future if you want to grade our response on support, please contact us at https://www.blubrry.com/contact.php, we have staff monitoring our support system and can schedule phone/video conference with our support when convenient. Plus you can call us during business hours to speak with one of our support staff!

A password protected feed and media URL does not work with podcast directories. You cannot submit protected podcasts to iTunes for example, because the media is not public they cannot index it.

Password protected feeds and media URLs do work in some podcast applications, but you need to manually subscribe to them for them to work. Quick list: iTunes desktop, podcast iOS app (it’s not easy to subscribe manually though), BeyondPod, and Podcast Republic.

HTTPS is supported but not 100% by iTunes. Read more here: https://create.blubrry.com/manual/your-web-site/secure-ssl-podcast-website/. Note that some of the newer SSL certs like LetsEncrypt.org certs do not work with iTunes currently, but they will in time (as soon as Apple updates their iTMS Java servers to latest versions of Java).

I cannot speak for other platforms but Blubrry pulls podcast feeds once every 4 hours and we honor eTag and Last modified since tags, so if your server is optimized, we simply perform a link and your server will return a 304 not modified response. You will see this in your logs as 304 if your server is optimized for these types of requests. iTunes pulls feeds every 4 hours and they perform multiple types of requests such as HEAD and GET. IF the HEAD requests fails they do not perform a GET on the feed URL.

It sounds like the original problem was caused by different feeds being used in difference directories. Stitcher is currently undergoing major changes, they will soon function like all other podcast directories in that they will no longer keep copies of your content and redistribute them with ads in their own network. This is a good thing for podcasters and also means that podcast statistics will be more accurate for their downloads.

Thank you for the information. We do not have a passsword protected feed at all. I never talked about that. We do have a feed that is https and we have media files that are protected by https. But no password protection. I am not sure how that go in there.

The original problem appears to have been caused by an issue with Duplicate Post and Blubrry. You mentioned something like the GUID. I believe that may be down the right path. I would recommend people not use Duplicate Post with Blubrry. I used it with the Jetpack / WordPress audio / podcast solution and it worked fine. It does not appear to be stable with Blubrry plugin.

It does seem that Blubrry and iTunes are much better about keeping their feeds up to date than the other providers. I can attest to that. Also if you get your SSL cert from one of their approved vendors (I do) it appears to work fine. Actually the SSL RSS feed is working for all the distributors. Thank you very the response. I was unaware that anything was caught in the spam filter.

Hello @ab11936,

I just assumed you were doing both. I am not aware of any podcast application that can deal with password protected content from a non-password protected feed. Usually a password protected feed indicates to the app that the media may also be password protected. Sorry, you get used to this stuff over the years that you forget that such details are not documented.

One other thing that can cause the URLs to change is switching a site from http to https. For folks reading this, when you switch from HTTP to HTTPS, do not update the GUID column in your database, doing so will cause all your episodes to appear as new (the guid is a key for episodes).

Blubrry, and just about all other podcast directories support all SSL certs, the exception is iTunes currently because the backbone to iTunes iTMS platform is written in Java and only in the past month or so did Java support LetsEncrypt SSL certs. Java’s top level packaged certificates are not complete, you can Google about it, a lot of folks get frustrated by this with Java.