Angelo Mandato

Can you share the URL to the mp3 file you are trying to verify?

Your server may be using an out of date certificate bundle. What version of WordPress are you using?

If you are using LetsEncrypt SSL you may be dealing with the root certificate change that started today October 1, which is an issue where the cert is not including the correct root certificate with your lets encrypt cert. It is not the cert that expired but the root cert that expired being the issue. Here is an article on the issue: https://techcrunch.com/2021/09/21/lets-encrypt-root-expiry/

Please share your feed URL and your FeedBurner URL so we can check it. We may be way off what the issue is.

I recently learned following another thread that Google Search issue changing your feed has to do with the atom rel=”self” value. Apparently FeedBurner does not update that with its own feed URL, instead keeping the URL it is copying, which is why Google followed it back.

According to Google they use the itunes:owner > itunes:email if no googleplay:email is present. ref: https://support.google.com/podcast-publishers/answer/9889544?hl=en In so many words 2 years ago when they phased out Google Play music they said they will no longer be pushing their RSS tags opting for the Apple ones. They’ve even moved on to using Apple’s categories from what I understand. It is very frustrating.

Also more concerning, that page does not mention that the atom link tag has to point to itself (something that appears to just started 2 weeks ago), otherwise it will redirect to where it is pointing is a bit disconcerting. It seems to be a new change as some podcasters have been complaining about it.

<atom:link href="FEEDURL" rel="self" type="application/rss+xml" />

PodcastMirror updates this tag to point to itself.

I submitted you to be a PTE for the plugin for #de_DE Will follow up when i see a response.

Thanks,
Angeloo

Hello @flipty,

I found the issue, our RSS import does not handle the episode or season number information during an import. Assuming they are using the itunes:no and itunes:season attributes. I added that to the development backlog. Not sure when we will get to it but it’s in the work list.

Thanks for bringing this to our attention!

Thanks,
Angelo

Hello @damienoneill2001,

The Podcast meta data is more complicated than it seems. We will soon be making a PowerPress for developers documentation that is a bit more in-depth, but this page should explain a few things and give you some functions you can use: https://blubrry.com/support/powerpress-documentation/powerpress-and-your-theme/ Specifically the examples under “Other Useful PowerPress Functions”.

The name of the field in the post meta table you are looking for is called ‘enclosure’ assuming you are using the default podcast feed provided by PowerPress. If you are using post types or podcast channels feature in PowerPress, please let me know I can explain how those meta fields work. If you use our built-in functions you do not need to be concerned about how the data is stored.

Back story: Back in 2006 there was a plugin called PodPress, which saved the podcast information into a field, I think it was called ‘_PodPress’ using the serialize function. That was problematic because WordPress natively stores podcast information in the post meta table in a field called ‘enclosure’. As PowerPress was developed we wanted to maintain the backwards compatibility, meaning if PowerPress was disabled, WordPress would still see the podcast episodes. To achieve this, we save the podcast in the ‘enclosure’.

The WordPress enclosure post meta field was started before the practice of storing information in the post meta field expanded to include serialized content. At the time WP Developers decided to store a podcast episode into 3 separate lines and it still works this way today. I think 2007 Google summer of code, a developer made a Podcasting plugin, it was short lived but he had a good idea of adding a 4th line to the enclosure field which stored the rest of the information serialized. In 2008 when we created PowerPress we followed suit and we have been using that method to store the podcast information to WordPress since. Past podcasting plugins and the current Seriously Simple plugin copied this technique as well, it makes it easy to switch between plugins, no one wants to store your podcast information in a format that makes it hard to switch things if needed.

Because of this special formatting how the podcast episode data is stored, we made the functions you can find in the page linked above. Call $episodeData = powerpress_get_enclosure_data($post_id);, $episodeData will have all of the fields in key/value pairs. When you referenced the fields that you see in HTML such as “Powerpress[podcast][url]”, that is a 2 dimensional associative array in PHP. The first index is the ‘feed slug’, it is what PowerPress registers as the podcast feed (e.g. example.com/feed/podcast/). If you use post types or podcast channels, feed slugs can be anything you specify like ‘sermons’ (e.g. example.com/feed/sermons/). The 2nd dimension key corresponds with the meta fields for that episode. To access the media URL for a specific post ID 123 for the default podcast feed, you would call: $episodeData = powerpress_get_enclosure_data(123, 'podcast'); The 2nd parameter is optional and if you do not specify it, we will assume you wanted the ‘podcast’ feed.

Are you developing a plugin that will be posted on ww.wp.xz.cn? If so, please let us know, we will gladly link to it from our plugin.

Thanks,
Angelo