Problem you may be having, or feature you want: I spend a lot of time on finding new podcasts, I don’t always check the last podcast released. So I would love the visual indication (maybe not DOA) of possible pod fade.
Suggested solution: a option in settings / display to show DOA.
Screenshots / Drawings / Technical details: lol, I am a needs based scripter, with no talent for UI design and color deficiencies to . So I would not have any idea.
Pod fade is when a podcast stops being published, it implies that it is sudden and without warning. You get your regular podcast, then without warning you get no more. Some fade graceful (you get a last podcast that informs you there will be no more) and some just stop without any warning. I have hundreds of podcasts, if 1 just stops, I am unlikely to notice. Not that any major resources are lost if I don’t unsubscribe to a podcast,I just prefer to be thorough.
I do a filter on “not kept updated”. Thisis doable, but Iwould love a visual indicatoror notificationthat a podcast has faded. It is really only needed if you have a lot of podcasts. I hoped more people would be interested.
Not kept updated is a filter on what the settings for the podcast has been set to.
It’s not a filter on podcast which stopped releasing episodes, it’s a filter on podcast for those that AntennaPod won’t refresh / update because it has been set not to. (Same things than automatic download)
Thanks @EdwinHolley for that explanation of what podfading
Why would you want to know your which podcasts have (silently) stopped anyway? Would you follow up on it, and kick them off of your system?
I think the whole discussion over at the Podcast Index might be relevant:
If they track/calculate somehow the release frequency and can serve it over API, they could inform clients via the API when a podcast has stopped. In fact, Dave mentioned in the last Podcasting 2.0 episode that 37% of the podcasts in the database aren’t active any-more, and that (if I understood correctly) they already stop checking for new episodes. If that’s indeed the case, they might as well expose that info via the API.
That sounds great. I don’t know why it matters, but I would definitely remove/unsubscribe a podcast that is not currently active. Probably so I can know how many subscriptions I have (active). I am OCD, sorry.
dead: integer
At some point, we give up trying to process a feed and mark it as dead. This is usually after 1000 errors without a successful pull/parse cycle. Once the feed is marked dead, we only check it once per month.
However, this is, if I understand correctly, about the feed not working. If the feed is still up & running, but just doesn’t get new episodes, it doesn’t get the ‘dead’ tag. For this case I guess the discussion linked above (about Frequency tag) is still relevant.
On a related note: Podcast Addict has a filter when searching for podcasts to add: Hide canceled podcasts (no content published in the past 4 months). Might be useful to exclude ‘dead’ podcasts from the search results. And if we ever get an implementation of ‘inactive’ podcasts, that could be useful as an option.
Once I sort subscriptions by last updated, I would still have to check manually. I would have to estimate how often the episodes were released, then I would have to see how many cycles it has been since a podcast has been released. Then remove the subscription if appropriate. My preferencewould obviously be for just getting a notification that a subscription might be dead.
It doesn’t account for how frequent a podcast ‘normally’ releases new episodes. But it certainly serves that use-case in a much simpler way ^^
True. But if it’s been over a year ago since the last episode (example from my list), it’s safe to assume it’s dead. If there’s some that are a bit more recent, I’d personally just leave them.
Anyway, I agree an actual ‘is inactive’ label would be nice. Would just be more efficient to wait for an external service that can do that for us/the user (rather than making AP code more complicated/heavy to do it locally, unreliably). (Especially given that there’s a workaround.)
. So I would not have any idea.
