Queues aren't updating with new episodes

[ehula]

Checklist

• [X] I have used the search function for OPEN issues to see if someone else has already submitted the same bug report.
• [X] I have also used the search function for CLOSED issues to see if the problem is already solved and just waiting to be released.
• [X] I will describe the problem with as much detail as possible.
• [X] If the bug only to occurs with a certain podcast, I will include the URL of that podcast.

App version

6.3.4

Where did you get the app from

Other

Android version

CalyxOS 5.9.0, Android 14

Device model

Google Pixel 6 Pro

First occurred

has always occurred

Steps to reproduce

1. Subscribe to a podcast
2. Associate it with a custom queue
3. Open the Episodes page to verify there is a new episode since associating the podcast to the custom queue
4. Open the custom queue page to verify whether the new episode has been added to the custom queue

Expected behaviour

The custom queue should be updated to show the new episode.

Current behaviour

The custom queue does not get updated to show the new episode.

Logs

No response

[XilinJia]

When you associate a queue with a podcast, episodes (new or old) aren't just automatically added to the queue. Episodes are only added to that queue (in the same way as with a normal queue) when you manually added some episodes to queue, or in the case of automation, when episodes are downloaded (by auto or manual download).

[ehula]

I would think the preferred behaviour would be for new episodes to get automatically added to their associated queue, whether they are downloaded or not.

I hope you might consider making this change.

The automatic downloading isn't interesting to me because I stream all of my content.

[XilinJia]

When you hope to add all new episodes to the queue, do you expect to play them all? Because that's what a queue serves. Or if you would simply like to look through them and selectively play some, then perhaps it's better to do it in other ways. With 6.3.4, the feed episodes list serves as a virtual queue (if you set the associated queue of the feed to None), perhaps you can be better off picking and playing some episodes from that list.

[ehula]

Yes, I expect to play all (or most of) the episodes of the podcasts I have associated with particular queues. I feel that others would as well. I don't see another use for queues otherwise.

My workflow is to view a custom queue, browse all of the new episodes that have been collected, perhaps remove some that are not of interest, and otherwise play all of the episodes in that queue, one after the other. If you were to enable the automatic addition of new episodes to their associated queues, that would meet my requirements.

If I may offer a suggestion, it seems that there might be a better way to present Queues to the user with a more intuitive and familiar user experience. Also, I think you might be missing an opportunity to use tags in conjunction with Queues, which would eliminate the "Associated queue". It would involve a change to the design of the app, but I think it would have a long term return on efficiency and ease-of-use.

• Remove the "Associated queue" attribute.
  • The current flow is to select a podcast and then associate it to a queue. That seems backwards and counter intuitive to a new user.
  • The following describes a flow where the user creates a Queue, then selects the podcasts which are to be included in that Queue.
• Change the Queues page as follows:
  • Display Queues in a similar fashion to how Subscriptions are displayed on the the Subscription page. Each Queue is displayed as an icon.
  • Remove the drop-down menu from the Queues page and just display the word "Queues".
  • Display Queues as an icon with the Queue name underneath the icon. The initial state of the page will be empty. The icon can be made up of small images of each podcast included in the Queue (like a folder icon in an Android launcher). Tapping on a Queue will open the episodes view of that Queue.
  • Add a "+" icon in the lower right for creating new queues.
  • Allow the user to delete a Queue.

When the user creates a new Queue, they choose which podcasts are to be included. My suggestion is to capitalize on the power of the tags system by allowing the user to select one or more tags for inclusion in the Queue. The podcasts containing one or more of the selected tags will be included. You could also optionally allow users to just add specific podcasts from a list of all podcasts, but I think the tag solution is more elegant and allows for more complexity. The user also gives a name for their Queue.

This new layout has a number of benefits:

• It is a user interface that is much easier to understand and is more familiar to the user.
• It is very easy to see at a glance all of the Queues.
• It allows for more complex Queue construction.

Food for thought.

I think you are making great improvements to this app and want to encourage you to make it as good as possible. I hope you see this as supportive of your efforts. Keep up the great work.

[XilinJia]

Thanks for the suggestion, I will give more consideration to them.

Can you explain why your ideas on queues mean a better usage operation than simply playing out from the virtual queue of the feed episodes list?

[ehula]

The virtual queue is fine for some use cases, like listening to a podcast that is a series of episodes that must be listened to in order, or to play one particular episode.

My use case is that I subscribe to many podcasts that fall into several categories like "technology", "news", "entertainment", "history". For each of those categories, I subscribe to a handful of podcasts. They are generally published daily or weekly, and are generally standalone episodes (i.e. can listen to a single episode without having had listened to all previous episodes.)

When the mood strikes me to listen to some podcasts, I usually want to listen to one of those categories. I would like to open a Queue corresponding to one of those categories, say "news", and quickly scan the summaries of the new episodes, maybe remove one or more episodes that don't interest me, and then listen to the remainder back-to-back.

You can see why I would like the queues to be automatically updated. Having to manually add podcasts to the queues seems like an unnecessary step and removes almost all the utility of custom queues. Having to play all my newest "news" episodes by jumping from one feed episode list to another is not a great solution.

[XilinJia]

For now, in 6.3.5, added "Audo add new to queue" option in FeedSettings.

[ehula]

It looks like new episodes are added to the bottom of the queue. That makes sense for podcasts that might be serial in nature (i.e. you need to listen to each episode in order.) But then again, you are probably going to listen to that podcast using the virtual queue and probably aren't going to use a custom queue for this podcast.

I would prefer (and I would guess that most others would as well) to have new episodes added to the top of the queue.

In my example of a my "news" custom queue, I am more interested in listening to the newest content. Like I mentioned before, I will probably take a quick look at the queue, remove some episodes I am not interested in, I might reorder a couple of episodes, then I will begin listening from the top down.

Could you either add new episodes to the top of the queue, or have an option of top of bottom?

[XilinJia]

Did you try sorting the queue?

[ehula]

Yes, I tried sorting the queue, but like I said above, I like to manually adjust the order of episodes I am going to listen to, so enabling "Keep sorted" doesn't work for me.

[XilinJia]

There is actually a global setting under Playback->Queues that's currently observed. Try that and let me know if it works as expected.

[ehula]

Ah, I missed that. Yes, that works great for some queues, but not for the ones where I want new episodes to go to the bottom. It would be great if at some point in the future, you could make this a per-queue setting.

[XilinJia]

make this a per-queue setting.

I'm kind wondering whether this better be per-feed or per-queue setting?

[ehula]

I definitely think it should only be a per-queue setting (and the existing global queue setting). I assume that "per-feed" means "per-subscription"?

I think it's great that you can play directly from the subscription episode view in what you call a virtual queue. You can already sort this view a number of ways, so that would allow you to play episodes in newest to oldest order, or oldest to newest order. I wouldn't add anything else to this like manually sorting, or a per-subscription "Enqueue location". I think the subscription episode view works as is.

A user could always make a queue containing a single podcast subscription if they want that functionality.

[XilinJia]

But the queue can also be sorted in about the same ways as the subscription. So why need a new setting there?

[ehula]

I don't think it is absolutely necessary to have a per-queue setting.

I think the global setting might be good enough. I suspect most people will want new episodes added to the top of the queue (newest on top) because most likely their queue will be aggregating episodes from podcasts where it is not necessary to listen to every episode in order from oldest to newest. It might be a good idea to make "Front" the default for the "Enqueue location" global setting.

In the case of serial-type podcasts where the user would want to listen to every episode in order from oldest to newest, they probably won't use a queue for these podcasts and will instead listen to those episodes in the virtual queue offered by the subscription.

[ehula]

The next improvement in Queues should be to redesign the Queues page as I mentioned above. This would greatly enhance ease-of-use. The current drop-down menu method is not great, and is a departure from the rest of the UX.

[dyeray]

I don't think adding new episodes to the top of the queue by default makes much sense. If the queue is not fully emptied, first in first out is what makes more sense, it makes sure episodes stay relevant, and that there are no episodes that will probably never be played. Don't confuse your specific use case with what most users need.

@XilinJia In case you are interested of improving this feature, I suggest taking a look at what other podcast apps may have done, so you can benefit from their product design work. For example AntennaPod has had a lot of analysis work on this feature. See this screen as an example:

https://user-images.githubusercontent.com/6870496/161404103-b13839b0-0c2a-4b22-b881-c7bd364171d5.png

[XilinJia]

I feel the same about adding new episodes to the top of the queue by default. It sort of beats the concept of queue. It should be better left as an option for special need.

@dyeray Explain why you think having a list of queue in the drawer is better? Wouldn't the drawer become crowded? Of course the list can be shown/hidden upon click, but that wouldn't make opening the queue easier.

[dyeray]

I don't have personally a preference. It was just a general comment since there was a suggestion on this thread to redesign the queue page because it doesn't follow the rest of the UX. Just pointing out there is design work for free, specially on the AntennaPod side.

I still need to find time to start migrating some amount of feeds to Podcini and test the multi queue feature, but from the changelog, it seems good to me.

[ehula]

If you are going to implement a per-queue "Enqueue location" setting, then I think that solves the problem.

I personally don't see why you would want to put new episodes to the bottom of a queue. To me, that would mean that you are intending on listening to all episodes of a podcast in order, starting with the oldest, and therefore wouldn't you do that in the virtual queue of that particular podcast. Why would you want to use a queue to do that, because by doing so, you will have episodes from other podcasts mixed in?

Of course I am not trying to say that I am right and you are wrong, but I would be interested to see your personal use cases.

Making this a setting is probably the best solution, and then the only other decision is what to set as the default.

[dyeray]

OK, below go my reasons, but I'm not saying your use case doesn't make sense. It's just an opinion.

First, you would be increasing the time to listen of some episodes to reduce the one of others arbitrarily. If you listen to podcasts that have an order (like chapters of a mini series or audio novel) you are making them unusable. If you listen to news, you would be making some news irrelevant, to the point that you may as well delete the episode when it reaches the point of listening to it.

As I suggested above, it may also mean that are episodes that never get listened to at all. Imagine you have a queue of 10 episodes, every day add 5 and every day listen to 5. With a queue, it's a first in first out, and today's episodes are listened tomorrow. What you propose is not a queue, but a stack, and with that approach, the oldest 5 episodes would never be listened to, and the newest would be listened on the same day. Don't pay too much attention to the specific example, basically the idea is that old episodes are very likely to never be listened to, unless you empty your queue before adding new episodes. The FIFO approach, at least by default, is used by every podcast app out there that has a queue.

[ehula]

You seem to agree with me that podcasts that have an order (chapters of a mini series or audio novel, i.e. FIFO) are not good candidates for a custom queue. If you read what I wrote above, you'll see that I proposed that those are best experienced using the virtual queue for each podcast and not with a custom queue. I don't understand why you would put these type of podcasts into a queue, but I can understand giving users the option to do so.

News is a great example for my use case (LIFO). I don't want to listen to yesterday's news today. I want to listen to today's news today. Yes, old episodes may never get listened to, but that is the desired outcome when using a LIFO approach. That is the feature of LIFO.

You mentioned that I am proposing a stack versus your approach that you call a queue. While technically correct, it doesn't make the stack approach any less valid. You might be getting hung up on the fact that the developer has called this feature a "queue", and therefore it must only behave like a queue. I have always thought they should have been called playlists, but it doesn't really matter. Rather that create a new feature called "stacks", I think both approaches should be accommodated.

Some people will prefer a FIFO queue (series), and some will prefer a LIFO queue (news). Personally I don't see the need for a FIFO queue (why combine episodes of different podcasts?), and you don't see the need for a LIFO queue. The conclusion is that it makes sense that this should be a user setting.

[XilinJia]

One other thing to note about the queue (or playlist if you want to call it) is that items there are played in sequence (however you ordered it). So while it's playing, you add some other items, it's naturally expected that the new items are added to the back so as to be played later. If they are added to the front, and with the circular queue feature, I agree they will eventually be played later too, but it beats the sense of the queue. I don't see a problem for a user to customize and use it like that, but for it to be the default for everyone it appears counterintuitive. Don't you think?

[ehula]

I'm happy to use your term "queue", it just seems that @dyeray was taking the definition literally. Maybe using "playlist" could have avoided the confusion, but I don't think it is important.

I see what you are saying about adding new episodes to a LIFO queue, but it doesn't defeat the purpose of a queue like you are saying. It meets the needs of a LIFO queue perfectly.

I assume you are going to allow each queue to have its own "Enqueue location" setting? Regarding the default setting, my gut tells me that more people will prefer LIFO, but on our small sample size of three people, two of you seem to prefer FIFO, so I will leave it up to you to choose. I don't think it is that critical.

What I think is more important is to redesign the Queues page. What did you think of the idea of presenting Queues as "folder icons" on the Queues page?

And what are your thoughts about reversing the user flow when setting up a queue. Currently the user goes into the settings of a podcast and associates it to a queue. To me, it think it is counter intuitive and cumbersome. I think what makes more sense and is more efficient is to go into the settings of a queue and (dis)associate podcasts to that queue.

[XilinJia]

@ehula I can't think of reasonable use cases on reversing the use flow regarding the queue. I can see some usefulness of removing an associated podcast from queue, but why would one go about adding podcast to a queue. A user is first of all interested in the podcast, not the queue, right? A queue is nothing but a tool.

I've also given some thoughts on "Display Queues in a similar fashion to how Subscriptions are displayed". Interesting idea and it would work, but what problem is it trying to solve? It would require more tapping to get into a queue, right? Currently, when you open "Queues", the queue last used is automatically open. Also I think somehow equating queues with subscriptions is not a good idea. A subscription/podcast is something concrete if you will, they have their own contents. But a queue is simply a tool.

[XilinJia]

Let's close this chapter now.