Mark episode(s) as NEW + filter on NEW episodes

@gomezz Are you saying that you wish these properties were fully decoupled, or that you believe that they currently are? Could you please explain how to make an episode New and Played at the same time? I’m fairly sure that is currently impossible as that would mean read would simultaneously need to be both -1 and 1.

@Matth78 It seems the only difference between your and my use is that you seem to have your subscription counter set to unplayed rather than new episodes. Would adding a new and queued setting for the subscription counter, in combination with my three other suggestions, perhaps work just as well as adding a separate ignored state for you? When adding old unheard material to the queue, given that filters and views make it easier to find desired information, does it really make a difference to know whether an episode was previously rejected explicitly or just undecidedly skipped?

I definitely see the need to be able to ignore episodes. What I’m saying is that I believe the cleanest implementation would use the three states currently existing, and improve on how they are used rather than complicating everything by adding unnecessary states. Please remember that it is already possible to favorite episodes. Would adding silver favorites, and :poop: or :-1: “favorites” in addition to the currently existing gold stars be an alternative to an ignore state?

Further on somewhere in the distant future, I’ve gotten the impression that multiple playlists could possibly become a thing. Wouldn’t that both be complicated by a convoluted state model, and the real solution to some problems around how to treat undecided episodes?

IMHO ignore is really a state on his own.
I live without it with no problem but for managing episodes I clearly see it’s needed and don’t see how it could be accomplished using existing states.

For me what it boils down is what you visually see and can filter when looking at the screen of episodes for a specific podcast.
What is usefull is to be able to distinguish episode not played and not new so you can add them to the queue when you’re short on episodes to listen.
If no such episodes exists then is there ignored episodes you would play because there is really nothing else or because you spoke to someone who changed your mind about ignoring an episode.

Favorites is something entirely different which IMHO allow you to keep episodes from being deleted and / or allow you to quickly get to them.

1 Like

@cos I am saying that logically these two properties are decoupled. If and when AP becomes my main podcatcher I will find a way to use it that fits in with that as best I can.

@Matth78 I have no problem with using mark as played as a way of ignoring episodes that I do not intend to listen to. That is for newly dropped episodes. For the backlog episodes I have no problem in leaving them as unplayed until and when they pop up as the next old one to listen to and at that point either play them or mark them as played. If someone or something prompts me to revisit any episode whether already played or marked as played I can always find it again.

As you can see in the GitHub ticket (which summaries the forum + hackathon conclusions) only 1 extra state is introduced: ignored. New is kept and used for the inbox (or perhaps renamed accordingly).

Your proposal is pretty much the same as the one in the GitHub ticket: fresh=new(=undecided), will-possibly-listen=unplayed, wont-listen=ignored. This list is only missing the ‘played’ status. States could of course be renamed (e.g. as per your suggestions) to better reflect what they mean.

That’s not how it currently works but I fully understand your expectation. This was one of the reasons to propose to get rid of the ‘New’ label.

No. And this is in line with the current proposal: when played the episode status changes to played, regardless its previous state (meaning you indeed loose the info that you mention is not important).

No, because it would be rather complex to have (new or custom user-created) ‘favourite’ values have an affect on/integrate with automatic download processes (1 extra state is much simpler).

We have seen that many users don’t mind and actually do this. I used to do it in the beginning, too. But it invalidates the statistics :slight_smile:

Can’t say I find the listening statistics of any more than casual, passing interest.

Another forum post seems to request making it easier to mark episodes as played.

I realize to have failed getting my point across. To simplify, lets drop the third of my suggestions for now and focus on the other two. They would be of value to have, regardless of whether an ignored state is added or not, right?

So essentially you don’t have any strong opinions on my suggested changes to functionality. Got it! Noted!

Would not adding filterability on new deliver exactly the distinguishability you’re after? After applying a filter of not new + not played + not queued, all episodes remaining are those which previously never got queued. Thus the ignored ones, if I understand you’re usage correctly. I’m suggesting adding improved usability with the states currently existing.

Regardless of whether adding one, two or ninethy five new states. Wouldn’t it be worth making it possible to filter on new and explicitly marking episodes as new? Are there any arguments against this, or is it mainly that no one has yet presented a patch?

My suggestion is to add filterability on new and the possibility to mark episodes as new. My claim is that it could mostly fill the same need as adding an ignored state, but realize that some people might wish to differentiate between unseen and undecided. Fixing the handling of new does not conflict with adding additional states, but it makes it possible for users to differentiate between played and ignored with less complexity (although requiring some discipline).

You’re right! They are different. Getting too deep into them might not be interesting enough now.

Adding an additional state does not come without added complexity, but I will not push for additional ‘favorite’ types. The point with this thread was to suggest making the currently existing state new more useful.

My afterthought after answering :

I wonder if what make this things hard for everybody to agree is because what people do with new episodes.
If your new episodes are your waiting list to listen then I can understand there is no need for ignored. (I think @cos is how you see it)
But if you consider your new episodes as a list to review and clean for what has just been released then an ignore state is needed because after reviewing your new episodes list is empty. (This is how I see it)

So “Not new + Not Played + Not queued” would amount to unplayed not new and not queued.
=> As far as I understand for episodes left you still won’t be able to tell apart the one you would probably never listen to (and want to ignore) to those no longer new and not queued but you put aside to listen for whenever.
=> What is needed is not to filter ignored episodes but to filter out those episodes so there is only episodes played or not but you would want to listen to.

Deciding to put aside an episode to whenever is not and edge case IMHO and it would be good if AntennaPod was able to make it easy. Reasons to put episodes aside for later :

  • you are not much interested in episode (for instance a topic you are not too keen on)
  • you have already too much podcast in your queue and you don’t mind skipping an episode
    => in both case you would probably listen those episode in future if you find yourself short to anything to listen to. (In fact you would probably have listened them if you had not much else when they had been released)

Worst case scenario with no ignored state is for podcasts releasing a lot of “episodes” which in fact are excerpts from real episodes. At least in France there is a lot of radio releasing their show as a podcast and doing this kind of thing.
=> getting back to the real episode you didn’t listen to is annoying, you would need to add additional filter like duration for instance. Yet if you could have marked excerpt episodes as episodes to ignore and it would be much simpler.

At last initially I marked episodes I wanted to ignore as played. I stopped to do so because it makes it impossible if you want to check if you truly listened to an episode and… it screws statistics :wink: :rofl:


Thank you @Matth78 for going this deep in trying to understand me. It seems you’re getting close to it.

I consider the Inbox list to be the waiting list of episodes to decide on whether to listen to or not. The actual queue is my waiting list for episodes to listen to. At the same time I also consider the Inbox list to be a list to review and clear. I’m well aware that I’ll never ever clear it globally, but I do keep it clear for feeds in some folders and work towards clearing the list for other folders. That is, I use different folders for feeds fully tracked, feeds to be cherry-picked, feeds to be caught up on from their starts, feeds to possibly consider in the future and finalized feeds.

You are making a strong point for having some kind of way to ignore episodes. What I’m opposed to is making ignore a too central part of the work normal flow.

As of currently, I would describe the state transitions as in the following picture:

On Feed Addition the user currently has no control to place episodes new to the listener as new to AntennaPod. One single episode pass through F2I into the Inbox, all else forcefully goes through F2N to Not played. I realize increased ability for placing episodes in the Inbox would also require fixing automatic download of episodes, but reworking that is another ongoing other thread. I, who do not use automatic episode downloads, have manually placed new episodes into the Inbox ever since folders were introduced through modifying the database with some SQL. That has been fully successful and an improvement for my usage, even considering the hassle of manually exporting and re-importing the database whenever adding a feed.

What I’m suggesting is making it possible to manage the Inbox so that most people would be able to get a simplified state diagram such as this:

Generally people would know when adding a feed whether they intend to listen from the start or skip all old episodes only caring about newly released once. Please consider e.g. RTHK’s eating smoke or CBC’s a death in cryptoland. Those two are short series, who everyone adding them would want to hear from first episode to last. No new episodes will ever be released for either of them. (They are also essentially timeless and I would recommend them.)

My attempt to illustrate how I understand what is suggested in GitHub with adding a Skipped (or Ignored, renamed to keep initial letters unique) state is as follows:

It becomes a hell of a lot more complex, with all those state transitions for normal use. The more I think of it, the more I’d consider Skipped to be handled and implemented more like Favorites. That is, as an external flag.

What’s missing in the sketches above? I could make the source svg file available if someone is interested in adapting them with details.


While being at it with pictures. Here’s my illustration of adding Skipped as a separate attribute, rather than encoding it within the read field.


This is supposed to indicate that any episode could be hidden without affecting state, just as any episode can independently be marked as a favorite.

Hey, I would even be tempted to suggest that a skipped episode could be forever lost from the user interface. But I leave it to those more interested in it to have opinions on whether to have Skipped as a filterable property, make them gone until resetting hidden episodes per podcast or whatever seems appropriate.

@cos Your “simplified” diagram seems to be missing a transition between Queued and Unplayed. For me I would want that to be there and to be a two way transition. I often add something from my backlog (Unplayed) to the current playlist (Queued) to pad out the total playing time for a listening session then sometimes move it back again if there turns out to be less time than anticipated.

@gomezz Thank you for pointing out the purpose of my diagrams was unclear. The idea is not to present every possible action, but to illustrate the normal state transition of episodes. Starting when they first enter the flow, until they reach their final state. Individual operations to transiently regress episodes backwards should of course be possible to do, but such deviations are not what the diagram is intended to capture.

As for an Errata, Skipped should have been depicted using a significantly smaller pile.

I haven’t been following this, but recently decided to see what all the fuss was about.

Here is my ten cents.

@cos, I appreciate your desire to improve AP, but your solution seems to just be a rehashing of the same problem as using ‘played’. Neither new or played actually distinguishes the users real intent. By implementing this, instead of using played, were just switching over to new.

Marking episodes as new doesn’t really make sense.

  1. It is supposed to be used to identify recently published episodes (which interests some users)
  2. Autodownload depends on new state to download episodes. Having too many new episodes will
    cause auto-download to behave incorrectly.

It takes a lot of effort and testing to realize a feature. The last thing one wants to do is add a workaround that sort of does what needs to be done. If we are going to solve your problem we should do it the right way.

I agree with @Matth78, ignore would solve your problem and Matth78s. It is a valid use case. I’m surprised more apps don’t have it.

Regarding the inbox. I don’t think it is necessary. It just adds extra complexity. However, I haven’t read much on it. I might change my mind later. For now, i don’t like it.

1 Like

Great! Improving AP is why we are here. We could not be in more agreement on avoiding workarounds!

Of course! Please remember that no one has demanded or required you to do anything. What I have done is initiated a thread with a proposal for how to redesign episode states. In order to reach an agreement on a user experience and interface that makes better sense, as it is welcomed in the contributing guidelines on the project’s web page.

My intention is that we solve this problem, not my problem. As you can see in the opening post, it refer to several users having these issues. If I was in this purely to scratch my own back, you would possibly already have seen a PR for #445 which personally annoys me more.

This thread has been started because the current handling of NEW is the biggest usability problem AntennaPod currently has. Please reread the opening post with references, to see my motivation for that fact. (Admittedly, it also bites me.)

Why would you so say? That is the springing point. We know that users misunderstand the functionality, or completely fail to realize its existence. Yet no explanation or motivation for the current behavior has been given, other than that it’s currently implemented that way.

AntennaPod is a wonderful piece of software, and you current contributors can be rightly proud over making it what it is. What I’m suggesting here is bringing the app towards perfection.

Yes, of course. That was mentioned in my opening post, and me understanding that has been repeatedly stated in the thread.

Really? That statement rings clearly false to me, and makes me think I’m still not being clear enough.

Did you have a look at the state transition schemas posted?

It is obvious that discussing this purely using text is unsufficiently clear. That’s why I attempted to illustrate the state transitions with pictures.

Please feel free to adapt state_transitions.svg which I made available to clarify how to better model user’s intent for the primarily supported listening flows.

Or do we not agree that there even are a couple of problems which could be solved?

I’ll quote you out of context here, just to say that I very much agree to those principles.

I’ve intentionally tried to focus on a overviewable set of changes, scoping conversation for the clearly required modifications to episode auto-download to a not-yet-started thread. But I’ll briefly comment below.

Every FeedItem has a pubDate. Wouldn’t that be a more appropriate field to use to determine what is new? But please let us get back to those details at a later point?

Again, I consider ability to ignore to be mostly a separate functionality. Solving it as a state of read is one possible solution, but it really is unrelated to handling of NEW.

An importantant ending point is there is a difference between having a legitimate need to explicitly ignore episodes, and being confused about what to do because how NEW currently works.

1 Like

So before we go into debating this issue, let try to get on the same page.

What is your reason for wanting to mark episodes as new? You want to be able to control the inbox, right, which you use as a ‘waiting list’?

If this assumption is right, then you support the use of an Inbox.

I’ve read through the thread regarding the Inbox. It seems the main usecase is to allow users to quickly be able to access new episodes from all subscriptions. And @Matth78 pointed out that it seems like a revamped All Episodes screen. I think he is absolutely right. I am in favor of NOT using the Inbox. Instead, we should just improve the Episodes screen.

@keunes pointed out various problems which necessitated the reason for creating a new Inbox screen. I think those problems can be solved be simply changing the Episodes screen. It is a much better solution, in my opinion, for the following reasons.

  1. It is simpler as it uses an existing screen. Why not focus on improving what is already there? It does not make sense to keep adding to a subpar UI. By enhancing All Episodes screen, we avoid needing to have a another screen, which will please @ByteHamster.

  2. It is a better mental model. I think we have to remain focused on the user. @ByteHamster as mentioned before that we should not change the UI too much as that will anger and confuse many existing users. Current users are already familiar with an All Episodes screen, not just from using AP, but also from other apps like Podcast Addict. An Inbox screen is completely unique to AP and it isn’t necessary. Most users barely understand the Queue let alone by placing another mechanism on top of it. We have to remember that the average user is a casual listener and will not need or care to understand how to use an Inbox. The same benefits can be obtained by modifying the Episodes screen. In this way, we can accommodate both the average user and the power user.

Can you not achieve your same workflow with an All Episode screen that allows you to

  1. Filter episodes by New
  2. Mark episodes as Read/Ignored

Yes. But pubDate varies. Remember, the main usecase for New is to filter recently published. What is new is different for each feed. In order to keep track of what is new, we need to mark them with New. This occurs when the feed is updated after the initial download.

Well, why would you think that, as they are just different ways of filtering episodes?

The possibility to filter on NEW is half of what the thread is about! It is one of the two suggested changes and part of the thread subject. Does this mean we agree that filtering on NEW is desired?

Can I assume you’ve read the thread? Quoting myself:

So no, I do not have opinions on the Inbox, it’s design or even it’s existence. We’re not really talking frontend level design here, are we? But rather about the underlying conceptual models of what usage flows should be expected, possible, supported and endorsed. When having a sound structure, tweaking presentation tends to be possible.

As when it comes to my personal use, I’ve mentioned having 25k new episodes. I’m surprised you believe either the Inbox or All Episodes could be of any use for anyone with a heavy backlog. I always add to my queue from the lists of each individual podcast. Anything else is completely unmanageable.

Possibly so. However directly exposing that technical detail as a concept the user rightfully has another perception of is the mistake, and essentially what this thread is intending to address. Timely enough, the support request Download all back episodes was just posted yesterday.

I did not wish to unnecessarily confuse the conversation with implementation details at this point, but see at least a couple of reasonable ways to decouple the app-internal new state from what is presented to the user.

Fixing the handling of existing states is a fully independent activity from that of adding additional states. Right? If explaining it with graph theory; A fixed set of nodes can have edges added, remove or modified without necessarily needing to add any new nodes.

Although including a partial redesign and being a major change, modifying handling of new would essentially be a bug fix. It would make AntennaPod behave as users already expect it.

Adding a completely new state is a feature addition. It would make it possible to do something previously not possible with AntennaPod.

Are you seeing the difference yet?

I posted diagrams where every state, and all transitions between them, are named. My expectation was that doing so would open up for more initiated and specific questions and comments referring to those names.

What are your comments on those diagrams? Do you consider the three pictures to be representing their models, or would you prefer to illustrate the episodes’ cycle-of-life in some other way?

As currently implemented, the lack of F2I cripples the flow and prevents users to meaningfully use the Inbox (New) state for all episodes (minus one) posted prior to when subscribed.

To make it more clear; What’s crippled is that AntennaPod has a different perspective of new episodes than the listener’s perspective of new. An alternative would be; When adding a new feed, it should possible mark all episodes in the entire backlog as new. AntennaPod’s assumption that all podcasts are of the current-affairs or contemporary-extroverted-blabber kinds (when in fact the most listen-worthy content always age well) is the basis of the bug. However, making it possible to manually mark episodes as new is likely the pragmatic implementation.

Could we please, please, please defer this conversation to a separate thread in order to be able to focus on one distinct change set at a time? Do you really consider that conflating those details is necessary at this exact moment?

1 Like

The idea of “new” (to be renamed to “inbox”) is that you have never interacted with those episodes yet. As soon as you start changing their state, they can no longer be “new” - so marking something as “new” doesn’t really work.

If you want to mark all as “new” because you are interested in the entire backlog, you can just add all the episodes to the queue. If this is about auto-download, then we should change the auto-download feature, not work around it by manually changing the “new” state.


Welcome to the thread @ByteHamster!

Yes, exactly!

You seem to be making the assumption that New/Inbox can always be cleared in every sitting, when in fact new episodes might occasionally be coming in at a far too great pace for that.

Please compare this with how email is used. Some people tend to reset messages’ statuses to unread, until having had a chance to act on each one. Coretex has even had lengthy discussions about how being able to peek without changing read status is a deciding factor for some people when selecting email client. I believe manageability of the New/Inbox state should be considered a user expectation. So far I have not really seen any motivation to why that can not be made possible. I am fully aware it is currently not being implemented that way, and that any decision to allow a change will require (duh!) actually making changes.

That is not practical for at least a couple of reasons. Some podcasts are to be cherry-picked, lets get back to those. Even for the simple case where the entire backlog is interesting; adding hundreds of episodes to the queue creates the bigger problem of constantly needing to reorder the queue. Months or years might be required to clear the backlog of one single feed, and practically there is probably more than one such source to slowly progress through, all while trying to stay on top of other feeds listened to in real-time as new episodes are released.

Regarding cherry-picking. Please consider e.g. BBC’s desert island discs which has 2k5 episodes available to podcast, from eight decades of broadcasting. Few people would listen to all of those, but still it is the type of material which people find relevant to listen to selected parts of. Proof: podcasting wasn’t a thing in 1942, but BBC has bothered to make all these available. Is the recommendation for anyone wishing to sift through that treasure trove to add five years to the queue at a time? Do you truly find that to correspond to what makes AntennaPod more attractive than BBC Sounds? We have similar programs with timeless material from other public service broadcasters, and people do have interest in listening through such old material. Wouldn’t it be desirable if AntennaPod made that experience as pleasant as possible?

If putting the user experience first, rather than being fixed at never allow changes to the current functionality, would it then not make sense to allow adding to Inbox/New? If not, I would really wish to understand the rationale behind why that suggestion does not seem to at all be considerable.

I stick with my view that just because there is a backlog of old, unplayed episodes that it does not make sense to call them new. Unplayed, yes. New, no.