yaponvezos

Same here. After a (relatively) quiet period, the issue came back with a vengeance these last few days so I can’t trust any of the stats.

@zahardoc

Testing after manually filling the host field and upgrading to the latest version of SSP led to no issues with Spotify or any other platform.

@zahardoc

I’ll know by tomorrow and I’ll get back to you on that.

As for the rest of your comments, the pre-3.0 behaviour has been the default since I started using SSP back in 2018. This feels more like an unfortunate design choice than a bug. When you choose to indicate a field is empty not by actually keeping it empty but by filling it with anything (just in gray) AND mislabelling it, I doubt we’re in the presence of a bug. Even more so when whatever’s in gray actually makes it to the feeds and has been making it to the feeds for more than half a decade. But all this is a different discussion. Just sharing my thoughts on what you highlighted.

@zahardoc

It was inherited/auto-completed as halftone.fm which is correct. That should have been enough. It has certainly been enough for the last 5 years. And if not enough, your plug-in shouldn’t be showing it as inherited, but empty instead. Even so, I manually reentered it, because why not.

And yes, Spotify’s problem was the empty author tag, as I said from the off. There was no mystery as to that being wiped from the feed on every 3.x.x version.

Also, I’d say having a field labeled “host” that somehow controls the “author” tag is all kinds of impractical. Even more so if pre-3.x.x the author tag was being filled correctly and no metadata editing on my end between all versions of the plugin mentioned here.

In any case, I will try to test with a newer version of the plugin, to see if that manual reentry helps. I’m pretty weary of jumping into testing though, as each time I have to do this and things disappear, I spend hours dealing with listener complaints and with Spotify support to bring everything back ASAP whenever I rollback to save my skin.

I’ll get back to you when I can.

• This reply was modified 9 months, 2 weeks ago by yaponvezos.

@zahardoc

Again, while on 3.0.2, the same 6 out our 8 feeds disappeared from Spotify.

As I said the first time around, both Spotify support (they would know why their system rejects a feed) and my webdev confirmed that the Author tag gets wiped with newer versions of the plugin and Spotify insists that’s what caused the problem with their system in the first place. Both the first time and the second. I checked with them again today.

On the issues you brought up:

1. This is irrelevant. It’s been like this for a while now, at no point did I have an issue with Apple and what’s happening in this instance is happening on Spotify. And Spotify support raised no issue with it either.
2. I’ll look into this as it doesn’t remind me of anything and I haven’t changed anything else in months and months in my WordPress installation, but it too can’t be the issue as a) it doesn’t explain why rolling back your plugin restores my podcasts on Spotify and b) these lines are also included on the 2 (out of my 8) feeds that remain on Spotify even when all others disappear.

• This reply was modified 9 months, 2 weeks ago by yaponvezos.

@zahardoc

Still running some tests across different plugin versions (since 3.0.2 showed up in the meantime).

Spotify hasn’t been grumbling so far but what I noticed is that I deliberately changed a show’s associated email to a different address (using the halftone.fm domain), as a way to determine whether changes go through as I’m testing with different plugin versions.

And that email change isn’t showing for me. Only the one I previously used (my Gmail).

I’ll keep it at 3.0.2 for a while so that you can check without chasing a moving target.

This is the feed.

https://www.halftone.fm/feed/podcast/cmdos-podcast/

1. According to the plugin settings, the Owner/Author tag had inherited my previous global setting, which wasn’t an email.
2. The email tag, with one exception, was indeed empty.
3. Still, before rolling back, I manually filled both that field AND the email field and saved the new settings. That didn’t help at all.
4. Neither Spotify support reps nor my webdev could see the Author tag as anything other than empty/CDDATA after saving the new settings.
5. That’s when I rolled first back to version 3.0.0. That didn’t help.
6. Then I rolled back to 2.25.2 and that did the trick, as confirmed by both Spotify support and my webdev.

Long story short, I tried everything you proposed BEFORE the rollback and I got nowhere. Hence the rollback.

They seem to be counted in “Other”. But that is always the case. Plus, when these spikes happen, they’re evenly distributed between feeds and episodes, so if I check episode stats and all the extra downloads count as Other, I’m not going to see some huge and obviously nonsensical number in Other for any particular episode.

It’s not as clear as back in 2021 when all the spikes were counted in Audio Player, which is pretty specific. Your Other category never was specific enough.

I will try to check the bot activity but my firewall doesn’t make that easy. I am sure the extra traffic doesn’t originate from suspect parts of the globe though, I keep my firewall pretty aggressive as it is.

This has been affecting any and all shows and episodes. Not always all of them on the same day/at the same time, but most of them, most of the days.

I get a couple of quiet days every now and then but the issue resumes seemingly at random (so it’s not happening on certain days and repeating circumstances on the production side), meaning it’s not that I publish a new episode on a certain feed and that’s the feed that happens to go haywire that day.

No, my episodes are not being distributed through other sites, just the regular podcast services, whose stats remain realistic.

As for the page you highlighted, it doesn’t get many visits, certainly not enough to explain what I’m seeing, even if it autoloads. But I removed that embedded player, just to be on the safe side.

Updated to the new version and so far so good.

For extra flavour, the jumps are so ridiculous during these last few days, I get a daily listen count that is 10x to 50x my weekly listens. That’s just can’t be right or organic, I’m not running any ads and I can only wish I were that successful. I can’t bring those numbers to advertisers with a straight face. They’ll think I’m trying to defraud them, with historical stats being what they are.

This reminds me off that month-long period in May/June 2021 during which I had the same issue and it proved to be a bug on your end.

[ Please do not bump. ]

The issue persists.

So. I’m not on an NGINX-based server or in any way a customer of Bluehost.

Here’s a recording of my replicating the issue. The episode plays, when I update it stops playing through the player on the website, I rollback a version and it plays once more.

https://www.icloud.com/iclouddrive/098NZns90EKMk0HG23ONIAuYA#Issue_Demo

I’ll get back to you on the server-side set-up of things, but nothing changed on that side around the time this issue came up, nothing has changed since and this only happens with one of our shows. I imagine that if it was server side settings issue, we’d have problems with all of our shows.

So, yeah, rolling back to the previous version fixed it so it must be the latest one that somehow managed to be disastrous.