Download single episode without subscribing

[keunes]

@ueen

@keunes

Are we OK with dropping the podcast description? It is visible on the preview, not on the full podcast screen. I think that’s a loss (but fine to ‘repair’ later).

no it will still be avaliable when clicking on the cover in the feedlist as usual or we could keep the info button next to the new subscribe button that then is only covering/replacing the settings button.

I don’t really follow, sorry. Not sure why you’re referring to ‘clicking on the cover’.

I was/am comparing these screens, which users are currently and will be faced with after opening a podcast from the ‘add podcast’ screen:

On the left what users currently see, on the right what users will see after the change. As you can see, the (beginning of) the podcast & episode descriptions are shown on the left (current) and not on the right (to be). The user would have to make an extra tap (vis-a-vis current situation) in order to see the podcast description. (But as noted, I think this could be ‘repaired’ later.)

@ueen

@keunes

Are we OK with dropping the ‘Include in auto downloads’ button (revert #1915)?

resort to the deafult, i would suggest to not offer settings/filtering for preview feeds (this adds an incentive to subscribe).

Note the ‘include in auto-downloads’ checkbox option (which I incorrectly called a button) on the subscription screen. It determines what happens when subscribing (it’s not a regular podcast setting).

---

If I understood correctly, you’re proposing the version on the right here. I had in mind the one on the left - keeping the filter icon - but I prefer your proposal:

@ueen

@keunes

When we write the podcast to database: when opening the screen or when interacting with an episode. As suggested, I would do this only upon interacting with an episode (play, favourite, download), and only podcast+episode in question (not all episodes). Agreed?

is this the subscibing reminder? i would only use it rarely, suggestion: (only once) on pull-to-refresh in preview feed and when interacting with a second episode of a previewfeed (both easy database calls).

No, this is not about reminders. This is about when we write the podcast & episode information to the database (vs loading on the fly as happening, I think, with the current preview screen). My position is: we should not store the podcast in the database (with the ‘subscribed’ flag) until strictly necessary (i.e. only when we need to store episode-related data, such as played state). Curious to your perspective.

As for reminders: I agree with your proposal.

@ueen

the cost of having ghost feeds in db that are not (and should not be )represented in UI

What exactly is that cost? I don’t see any cost - you already said it’s a few bytes and little to no affect on performance. ‘Feels weird’ is not really a valid argument IMHO and certainly no ‘cost’.

@ueen

@keunes

Deletion of not-subscribed feeds

as then there is a clear reminder to subscribe most people will follow, so the effective lost data will be one playstate in a preview feed

You proposed to display the warning/reminder after second interaction with episode (and I agree - if displayed on first interaction it will be too soon after opening the screen). But I think it’s a realistic scenario that basic users will ignore/forget our one and only warning/reminder (power users will undoubtedly subscribe), for example: my dad reads about a limited series podcast about Aretha Franklin in the newspaper, finds the podcast, downloads the whole lot so it’s ready for consumption in the Queue (dismissing the warning as it’s interrupting his flow), never subscribes. This scenario would lead to data loss of more than 1 episode.

@ueen

A week from last played to deletion of preview feed seems like a good timeframe

If we go down this road of delayed deletion, as noted before I agree with the timeframe of a week. But what is the cost of this approach? I feel that a recurring check if any feeds can/need to be deleted from db has a higher impact on phone resource consumption than keeping it simply in the database. I’m comparing battery (recurrent checks) vs storage use (keep podcasts in db), but still.

@ueen

Hope this clears something up for you @keunes and we can move ahead with the proposal?:

Apparently there’s still some misunderstanding and things not hashed out (see above). So let’s wrap up those points - no reason to rush this.

(And before going ahead with implementation - I have the impression you’re willing to pick that up? - we should wait for ByteHamster’s agreement. Otherwise we might get stuck again later.)

(But yes, otherwise the broad roadmap seems fine.)

[ueen]

@keunes

I was/am comparing these screens, which users are currently and will be faced with after opening a podcast from the ‘add podcast’ screen:

dont care, could also be added, these are minor details, i think its important to get the big strides right and get going with the code

@keunes

If I understood correctly, you’re proposing the version on the right here. I had in mind the one on the left - keeping the filter icon - but I prefer your proposal:

yes that was my idea, exept that i would visually prefer to have subscribe on the left next to cover and the (i) on the right - thanks for the otherwise great mockup!

The description would then only be accesible through info which is fine but also something i dont care about, it could also be added to the header is really important to anyone. In general i would modify the feed screen as little as possible (only adding subscribe button).

@keunes

No, this is not about reminders. This is about when we write the podcast & episode information to the database (vs loading on the fly as happening, I think, with the current preview screen). My position is: we should not store the podcast in the database (with the ‘subscribed’ flag) until strictly necessary (i.e. only when we need to store episode-related data, such as played state). Curious to your perspective.

that wasnt on my mind before, good point, i wouldnt be dogmatic about this, i would do whats easiest (coding- und UX-wise), either store every preview feed straight to db and delete after a week or only if an episode is played @ByteHamster any feelings about this?

@keunes

What exactly is that cost?

The cost is, as explained above, to not accurately reflect db data in the UI over an extended period, which i hads the feeling is important to all of us. And it could add up, if you look at the top 10 previews every other week there might easily be 100 preview feeds hidden in the db over a year or two. Though i feel not super strongly about this, i would prefer to have a delete routine eventually, be that a week or two or maybe even a month. It comes down to the likelyhood function that results from people first listening to an eipsode to when they subscribe. And i’d suspect that only around 2% of subscriptions occure after a week or two. Thats only an estimate of course and i guess you’re right, that its not a hard criterion to reflect db-state. But something to consider.

@keunes

my dad reads about a limited series podcast about Aretha Franklin in the newspaper, finds the podcast, downloads the whole lot so it’s ready for consumption in the Queue (dismissing the warning as it’s interrupting his flow), never subscribes. This scenario would lead to data loss of more than 1 episode.

I dont want to argue this to death, i just want to add: so what? if that works for your dad and hes happy, thats fine. One solution could be to automatically subscribe (=remove preview flag) if multiple episodes are played,
*but my prefered solution would be, *
*let users be free! *
*Remind them once or twice *
and then leave it up to choice.

@keunes

recurring check if any feeds can/need to be deleted from db has a higher impact on phone resource consumption

@ByteHamster what do you think? i believe this to be negligible when added to the update feeds/download service, it would be one single db query to check which to delete and then a second query to remove from db - every email consumes more ressources…

@keunes

you’re willing to pick that up? - we should wait for ByteHamster

agreed on the latter. would i pick it up: not necessarily, i could take a shake at it, but i’m really unfamiliar with preview and update/download service, someone more experienced could do this super quickly (a few hours max) and i could focus on home and maybe deeplink, but if no one is able to take this on or not alone of course i would assist - when i have time - to move this forward

@keunes If everything is cleared up for you, please agree to my road map and or modify it to a new (concise!) one (plus mockup), so @ByteHamster doesnt have to read all the fragmented explanations or only if he wants to.

[ueen]

@keunes ping, can we move ahead with this proposal?

[keunes]

Thanks for the reminder @ueen. I was away, but will get to it Thursday or Friday (as I’m off from work for FOSDEM and will have time).

[ByteHamster]

@ueen

can we move ahead with this proposal?

Before starting with this, I would prefer to move ahead with your other PRs first. Having too many things going on at once makes each individual one quite slow to progress (and causes lots of mental “context switching” to work on all of them simultaneously)

[ueen]

Well this is closely related to the web share page, so its not that much context switching as it is seeing the bigger picture.
Plus I’d like to reiterate that I don’t necessarily want to work on this, but rather just finally agree that this make sense and is the right way. If we stop scaring off contributers that then go one to do kotlin translations we might even find someone to work on this

[corkmaster]

I came here looking for this feature request and would wager it will become a more common ask as more people move over from Google Podcasts which is now closing.

I switched to Antenna from Google when the closure was announced and the main thing missing is the ability to queue single episodes without subscribing.

In fact I find it strange that the main button next to a podcast episode is “download”. Maybe it is just my workflow but I almost never want to download anything to my internal device storage unless I am travelling somewhere/on a plane etc.

For day to day usage the main easy to access buttons should be something like “Play” and “Queue”, then maybe “Download” as third. But that’s my 2 cents as a new user.

Thanks for the work guys

[Nilex]

I do have to say this particular list is #2 on my list of priority items that I think AP needs, surpassed only by this issue…

Play button doesn't work on screen lock

I have to open the app and hit okay from there (Pixel 6)

[Matth78]

@corkmaster

In fact I find it strange that the main button next to a podcast episode is “download”. Maybe it is just my workflow but I almost never want to download anything to my internal device storage

In settings then playback you can set “prefer streaming” which would replace download buttons with streaming one.
But it’s not strange download is the default since podcasts are meant to be downloaded and not streamed.

[gomezz]

For many users downloading is preferred to streaming as they are, like me, on the move passing through areas of patchy internet coverage for example. I do have some podcasts I only or mainly listen to at home which I don’t bother downloading but they are a few among many.

[Nilex]

Yeah, I wasn’t so much talking about actually downloading (although I know that’s the topic of this post), it’s actually specifically about it not being able to add a single episode to the queue. I just have downloads automatically added to the queue.

[ByteHamster]

I have a first proof of concept of this feature here: Add episodes without subscribing by ByteHamster · Pull Request #7098 · AntennaPod/AntennaPod · GitHub It might need some more nudging to make users eventually subscribe to the podcast if they continue playing episodes from it but the overall idea seems to work

[Nilex]

This seems like a fair solution.

I glanced at your github comments and the only thing I have a question about is your “Doing this does not really make sense on a distributed podcast app.” comment.

Just so I’m understanding your explanation better, by distributed podcast app do you mean an app that does NOT sync to a centralized server?

I ask because while I don’t use it often, I do sometimes just want to go listen to a single, specific episode of another podcast because maybe they had a guest on a podcast to which I DO subscribe and they say they go into more detail on the topic in a specific episode. In that scenario I don’t want to subscribe and add it to my usual list of podcasts going forward, I just want to one off listen to that specific episode and move on.

What I’ve found is if I start playing just that single episode without subscribing that things like remembering where I stopped listening don’t appear to happen so unless I can listen to the episode in it’s entirety it’s a frustrating process. I also understand the reason it’s working that way may be (likely is) because I’m not subscribed to that podcast.

[keunes]

@Nilex

Just so I’m understanding your explanation better, by distributed podcast app do you mean an app that does NOT sync to a centralized server?

Indeed. Although ‘sync’ is not really the right word here as we do support synchronisation, but it’s about retrieving podcast and episode data from a central server.

More info: Central and distributed podcast apps – AntennaPod

@Nilex

I also understand the reason it’s working that way may be (likely is) because I’m not subscribed to that podcast.

Yeap. That’s why the approach is to subscribe in the background.