Download single episode without subscribing

Feature request
1

Hi - is there a way to download a single episode of a podcast without subscribing? Thanks

5 Likes
2

Hello @Smollen
Thanks for chipping in on our community forum. That’s currently not possible, but there is a feature request for this:Add/play single episode without subscribing to podcast · Issue #4710 · AntennaPod/AntennaPod · GitHub

2 Likes
3

Hey as the github issue is closed for discussion, maybe we could brainstorm here about UI/UX and technical details. I like to propose a minimal working solution that I feel could be easy enough to realize within a few weeks, even though I admit that I have little experience with AP feed updating etc.

First the flow would be like this: what used to be opening the preview now directly leads to the subscribe action but sets a flag to the feed: not-updated (already have that) and also a hidden flag (don’t have that yet right?) Which will hide the episodes from all lists etc.
Then we need a subscribe button in the feedlist where now there are the settings and filter buttons.
And finally there needs to be a routine in the feed updating/fetching method that checks whether an episode of a preview feed is still in queue or downloaded, if not the feed is removed from the database.

Is this description good enough? Then we can go to the technical details, a roadmap might look like this:

  • adapt the open preview mechanism (possible difficulties: the preview screen is a somewhat self contained screen now that can also be opened by other apps!)
  • set not updating flag and implement hidden/preview flag
  • check all lists to respect the new flag
  • new routine for feed update to check for unused preview subscriptions (not in queue, not downloaded, what else?)
  • adding a subscribe button to the feedlist which removes the hidden/preview flag as well as setting the not updating flag to the user preference default

Idea: maybe do some things like downloading or adding to favorites trigger a promt offering to subscribe because I would agree that having this kind of ghost feed for to long is not great. Although I don’t see a real reason against it, if its not updated then it’s not slowing down the feed updating and the text only used up database space for a preview feed would be negligible I believe, but this point probably needs further thinking through, not too much though* :wink:

*let’s do a (minimal) working version and then beta it

1 Like
4

The biggest problem I see is that users might just start using podcasts without ever subscribing. As long as there is some episode in the queue, this probably mostly works. But then when there happens to be no episode in the queue at some point, it would unexpectedly delete the “played” state of that subscription. So I think these temporary subscriptions should either not be marked as played in the first place (which would be a bit strange when later subscribing) or the UI should make it really, really clear that we want them to click the “subscribe” button (and I currently have no idea how to best do that). Maybe even both? I can already see new users (who don’t know what podcasts are) getting frustrated because they never subscribe and don’t realize that this is why half of the features are missing. After it is implemented, we should probably do some user studies again, like the ones I did when rewriting the preview screen some years ago.

Note that the beta version targets existing users, but we really need to target new users with the studies here because if they don’t understand the app immediately, they will just download another app. For beta users, a minimal version is probably enough because they know the general flow (subscribing etc). For new users, it might be less clear.

I suggest to not work on too many things at once and wait for the toolbar/home things to be resolved. Otherwise, that could get frustrating when having to always come back to the earlier PRs to get them merged

5

Agree, and if we remind them if they download an episode, favourite an eoisode or play another episode of a preview feed? Preventing playedstate feels hacky, i think we should adopted a frame of leading a smooth the way to subscribing with friendly reminders and then well just have to see in beta if thats enough to inform the users (i feel like subscribing is something most users know from yt).
I also have a icky feeling about never subscribing but if users know they could but dont even with reminders and they are happy with their ghost feeds, why not? Who are we to judge how to use AP :innocent:

Most important i think is the cleanup routtine while feed updating, so that the ghost feeds dont clutter up the db if they are not in use.

Great so lets do both then :slight_smile:

I dont have to do (all) this, just wanted to conceptualize a roadmap, anybody feel free to work on this - its important and a big leap for AP :muscle:
the tasks could also be splited, i guess i would manage most but i’m not really familiar with feed updating/downloading service and i have other things going on, just a tiny AP rush rn

6

YouTube stores the “played” state, playback history, etc even without subscribing. With AntennaPod, this would be stored for some time and then disappear when the temporary feed gets deleted. I worry mostly about the fact that visible data disappears again. Maybe an alternative could be to store the state but not display it. So when you later subscribe, you have the full data, but when you don’t, it doesn’t look like there was data that gets lost.

7

Lets not make it to complicated because of hypothetical worries that might not even have enough substance to trouble any real user. Metadata like played state is ephemeral anyways, its useful, but no need to store it for eternity. That would be my take :slight_smile:

I actually like the yt way in this regard, i subscribe when i want more of it, but i have to listen to see if i do want more of it, and sometimes i just need to see a tutorial or listen to some sleep music then i dont want more of that, i just want that one video/episode.
I know the technical details/conception of yt and podcats are different but from a user view point - its not that different.

1 Like
8

That’s indeed what’s been proposed before. And I agree - I would just do that only on playback of an episode (not upon opening podcast preview).

I think I would also hide not-subscribed podcasts from the Subscriptions view - if that’s what you mean with ‘feedlist’. If we would display them, it’d be contradicting the screen’s title. If needed, the podcast can be opened via the History screen (and of course via the ‘Add podcast’ screen).

I think this risk is quite limited if the podcast isn’t shown anywhere else in the app. As this functionality is much-requested, IMHO the benefits outweigh the potential (limited) risk.

As I interpret it, that’s not what’s being proposed: the podcast remains in the DB (no feed refreshes, and I also wouldn’t show it anywhere). So historical data is preserved. (And if you meant to artificially delete that - I agree with @ueen that this goes against a smooth subscription experience.)

I think it’ll be inherently clear from the fact that the podcast doesn’t show up anywhere. Plus if we keep episode preview hidden as it is, the only likely ‘access path’ is when receiving a shared episode.

The actual UX to make a single-play episode more accessible (less hidden) can be hashed out at a later point. Including any potential warnings.

Well, we would be the ones getting the support requests on the forum and on Mastodon :wink:

I like that idea. Just wondering if it’s really necessary - if there’s no refresh, is it really harming to just keep it indefinitely? How much would the DB increase with, say, 10 additional feeds with maybe 10 episodes each?

If implemented, it should be a really long period. At least a year.

Where would this be visible, though? Only place would be playback history.
EDIT: ah, that’s what you then go on to propose. That was my idea from the beginning, so I agree :slight_smile:

Well. Disappearing data might be confusing for users and lead to questions to us (which we want to avoid). Going through such theoretical scenarios is what made AntennaPod the user-friendly & stable app it is today. (But the scenario is actually discussed in this thread, so I’m happy :wink: )

9

Summary of my proposal, building on @ueen’s description:

  • User starts episode preview from Podcast preview screen → Store podcast + episode in question (not all its current episodes) in DB; apply ‘not subscribed’ flag, disable ‘keep updated’ flag.
  • Not-subscribed podcasts don’t show up any-where.
  • Episodes from not-subscribed episodes only show in History screen.
    • To be discussed if they also show/end up in the Queue. Probably necessary to not mess up Continued playback logic?
  • If user opens the Podcast screen of a not-subscribed podcast (via History, Player or Queue):
    • Display a big ‘Subscribe’ button
    • Disable feed refresh (display modal with explanation of situation if pull-to-refresh is attempted)
    • Hide ‘settings’ icon (:gear:) (none are relevant if not subscribed)

Would you agree/did I capture that right?

1 Like
10

Almost, i would allow pull to refresh, at most once a notification mentioning subscribing. Reminding of sensible useflow yes but disabling features to force one: no.

About delete preiew feeds with no active episode in queue or so I’m not sure, i feel like delete after a week max, because not doing so would create true ghost feeds that are nowhere visible in the UI which seems like bad practice. Also what is lost is only 1 single playstate in probably over 90% of cases. But I guess you’re right that there’s no real impairment in keeping the few bytes in db, expect of that would slow down anything…

1 Like
11

They also might want to download it instead of just previewing/streaming. I think it would make sense to completely remove the preview screen and display it directly on the normal podcast screen.

Users have already asked for showing the date on the preview screen. When we allow downloading there, they will ask for the size as well. Then we would have to basically add more and more of the normal screen into the preview screen. Instead, I would just use the normal screen directly.

2 Likes
12

Fair enough. It was mainly to address @ByteHamster’s concerns of users getting confused about not-subscribed feeds, but don’t feel strongly about it.

Bad practice from which point of view? Technical/DB management?

Question is a bit when these users might subscribe to said podcast. Because at the time they do, I’d want to still have the correct playback state (even if just 1 episode). But I guess that decision is made quickly after listening, so in that sense a week after episode removed from miniplayer/queue is fine.

If favourited, deletion should be prevented as well actually. Starts to sound complicated to determine if and when this data may be deleted. Personally I think I wouldn’t bother and keep it indefinitely, if there’s no tangible downside.

I agree. But then you’re talking a whole bunch of other UX/UI decisions. And as you know (we’ve discussed this one a couple of times before) that’s a tough one. So I would just focus on agreeing & implementing ‘the back-end’ first (seems relatively straight-forward), and have the UX discussions in parallel/after.

13

Fully agree about that.

Actually I go further and believe when removing a podcast it should actually archive it and make it invisible. So if you subscribe again then episodes you have listened to are marked as read. Also with echo it would make sense to not remove information to be correct.
A (nice ?) side effect would be to keep episodes in queue even if you unsubscribe. Such episodes would in fact become “single episodes without subscription”

For privacy it would mean when unsubscribing AntennaPod should ask you if you want to also remove information about episodes states and statistics. It could be a checkbox in the dialog which already appears when unsubscribing.
And it should be also possible to truly delete afterwards from settings or from entries in statistics screen.

1 Like
14

Not so sure about that. There are times when you come back to a podcast forgetting you previously followed it. It would be a head-scratcher if you found that many earlier episodes did not show up. I think what you are suggesting is Archiving or Suspending a podcast subscription. Unsubscribing for me should mean exactly that getting rid of all its presence.

That said, I think there is also room for a Subscription Refresh function which would rebuild the database from active subscriptions and their listened history etc and in the process removing any orphan or ghost episodes it may find.

15

It’s out of scope of this functionality of playing episodes of not-subscribed podcasts. But I understand the use-case, see the link here and agree it’s an argument for not auto-deleting feeds+episode data of not-subscribed podcasts.

Not sure the statistics screen is the best place, but yes, we should think later about a place from where the user could possibly ‘clean up’ not-subscribed podcasts.

I won’t follow up on that point here, apart from saying that I trust we’ll find the right terminology when we get there. (Just to keep the focus here on back-end of playing a single episode.)

16

Technically that’s easy to determine when to delete, we just need to define when and then it’s a single query to the database.

UX/UI are at the core of this so we can’t leave that out. adding preview to db, setting the flags and open the feed will be way easier then what we are doing now, the only new thing is the preview/not subscribed flag that might be a bit tricky to think about everything and requires some testing, the rest should be relatively simple. then the only UI change will be the subscribe button on feedlist.

Maybe ByteHamster could offer a reality check on this formulation, but in my mind this will be super simple and a 1. Draft could be done in a day. :slight_smile:

17

Yes, a user request (UX) is why we’re talking about this, so that way it’s at the core. But I was referring to the specific UX of making it easier to find/start playing an individual episode (other than the current option of initiating a ‘preview’).

  • Either we implement UI changes together with UI changes, which we then need to discuss further (I’m not sure I agree with @ByteHamster’s proposal – and if we go for it, we need to agree on the changes we require in the Podcast screen).
  • Or we split the implementation in two: back-end now without any UI changes (the flag you mention; seems we’re at 95% agreemt), and UI review later (for making single episode play easier).

Benefits splitting in two, moving ahead with the back-end now: 1) it allows us to move a bit faster as back-end implementation doesn’t have to wait on UI conclusions 2) it allows us to think about/work on receiving episode shares in parallel as an important part of the back-end is already locked/agreed (which may be higher priority than the UI changes).

18

Well I see your point but sorry to say: this makes no sense, it would mean changing the “backend” and keeping preview, right? That would require preview to be rewired as well: extra work that will be thrown out soon. What you call “backend” is closely intertwined with UI.

I guess we don’t have to solve every UI detail now.
But preview needs to be replaced my feed, which will make all of this way easier.

Also I don’t really see big disagreement about that (?) - let’s start doing a working version as formulated above? :slight_smile:

19

I’m suggesting to move ahead with something that we already agree on, and you want to wait until we have UI sorted. The world upside down :upside_down_face:

I see. I guess I’m a little surprised that this mechanism (apply not-subscribed flag in DB) are tied to the preview screen. (Digression: I guess that implies that single playback from a received episode share needs its own implementation of setting the flag.)

I thought a bit further and I can see that opening the podcast screen works. That’s also how other apps (e.g. Podcast Addict) do it.

However, I don’t think the button is the only UI change that should be implemented (yes, details, but I want the ‘MVP’ to be user-friendly also, and I want to avoid whoever implements this to get my comments after they made UI changes as that’s demotivating). And let’s briefly address the UI changes that the user will face with this change:

  • 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).
  • I think we already agreed on displaying the Subscribe button as it currently exists on the preview screen. I would
    • put it inside the header container (i.e. with background image, below the cover and icon buttons)
    • make the button not scroll off of the screen and display the podcast title in the app bar when it’s not visible on-screen (as in the GitHub app with issue titles, reason: so it’s visible what the ‘subscribe’ button relates to, plus generally beneficial) - is this feasible?
  • Are we OK with dropping the ‘Include in auto downloads’ button (revert #1915)?
    • If not, we keep it as obnoxiously visible as on the current preview screen.
    • If yes (my preferred option), we should set it active by default (when subscribing).
  • Are we OK with dropping the episode descriptions? I think it’s a minor loss; less important than the podcast description - don’t think that needs to be added back b/c an episode is quickly opened.
  • Are we OK with ‘adding’ the download/stream buttons? I guess so, as it fully closes #4710.

Following up on a comment from @ByteHamster in #4710 and my reply:

what happens if someone goes to the podcast page and downloads another episode of that podcast without subscribing?

Either nothing special (episode gets added, nothing else changes), or - probably better - a dialog is shown saying that they’re currently not subscribed and adding more episodes is not possible, offering to ‘subscribe’ (i.e. remove the ‘not subscribed’ tag).

I guess based on earlier comments, we’ll go for ‘nothing special’.

And two technical points with no conclusion yet:

  • 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?
    • setting when opening podcast: easier technically but stores more data than needed (not great for sync also)
    • setting when interacting with ep: needs changes in more places (technically more complicated) but doesn’t store in db unnecessary data.
  • Deletion of not-subscribed feeds: @ueen, @Matth78 & myself shared opinions already - keeping seems acceptable/preferred.
    • I think we need to discuss later how we make viewable/removeable not-subscribed podcasts. For now I was thinking to have an option in the Subscriptions overflow menu to open same fragment with only not-subscribed podcasts.
1 Like
20

This is what i said, in a sense the answer is no but if we have adding single episodes and dont remove the current preview screen, we need rewiring for that from what could be the new preview feedlist to the current preview. Which would be throw away if we do the new preview feedlist, that we want to do anyway and as its basically no work (just have to agree on where to put the subscribe button on the feedlist), i suggest doing that at once and dont produce throw away code :slight_smile:

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.

instead to icon buttons like settings

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

yes, everything else than afromentioned stays the same or resorts to default settings.

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). This also solves

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 - which for me outways the cost of having ghost feeds in db that are not (and should not be )represented in UI. A week from last played to deletion of preview feed seems like a good timeframe (as its most likely that users to listen to a single episode and then within a week or two, to another episode and subscribe. After a week or two it becomes more and more unlikely and the cost of the ghost feeds overweigh in my view.) If i rediscover the podcast after (half a) year or so, i will have forgotton about that single playstate and won’t care about it - thats not the reason to delete, the reason to delete are ghost feeds. Because the UI should reflect the db IMHO and ghost feeds are hidden and thus feel weird.)

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