The new option ‘New episode action’ seems to have some unintended side effects. People experienced that auto-download is no longer working after the setting is set to ‘Nothing’:
So the discussion on GitHub about whether to revert the introduction of the ‘New episode action’ or not was continued in the Needs: Discussion meeting.
The unintended side-effect (auto-download stops working) is that auto-downloads are coupled to the Inbox. As per the CURRENT auto-download eligibility check:
- episode is not currently playing
- AND auto-download is enabled on episode
- AND episode is
- in Inbox
- AND auto-download is enabled for its podcast
- AND episode is not filtered out based on the episode filter set at podcast level
- OR in Queue
- in Inbox
Auto-download boolean & download fails/retries
Auto-download gets turned off for a given episode (boolean set to ‘no’) in 2 cases:
- user manually cancels download
- auto-download failed 3 times
More details on the (auto-)downloads retry & fail policy.
Both manual & automatic episode downloads are sent for processing to the system (Android). If it fails, the system informs AntennaPod, and asks if it should try again. After the initial failed attempt, the system waits 30 seconds, and this waiting time doubles with each new failed attempt, with a maximum waiting time of 5 hours: 30s, 1m, 2m, 4m, 8m, 16m, 32m, 1:04, 2:08, 4:16, 5h, 5h, etc. The system also waits until other conditions are fulfilled, e.g. that there is a network connection.
AntennaPod tells the system to retry two times; upon the 3rd failed attempt we
- tell the system to cancel the download
- set the episode auto-download boolean to ‘no’
- put the episode back into the Inbox, IF it was in the Inbox before / (auto-downloaded or downloaded from the Inbox) [@ByteHamster to confirm]
For manual downloads, a snack-bar is shown on every failed attempt, explaining we will retry later (or not, if last attempt). For automatic downloads, because it is not initiated by the user, we do not (need to) inform the user.
We might increase the number of failed retries (for auto-downloads). A decision is to be taken still.
We can provide the system (Android) with additional metadata, allowing distinguish manual and automatic downloads, in order to ‘fail faster’ for manual downloads.
- manual: 2 (current: 3)
- automatic: 15 (current: 3)
- if a media server is out for a day, we’re still retrying next day
- if retry fails even then, we might disable auto-download at podcast-level, and show a warning (like for other errors: dot in menu & subscriptions screen + error in detail screen. Related: #6609).
We discussed removing the 'auto-download' boolean at episode level, and tracking this only at podcast level. However, for some technical & UX reasons, we should not.
Moving the ‘auto-download enabled’ boolean from episode to podcast level, would make the database and code simpler. Having the setting only at podcast level would not prevent future implementation of popular auto-download enhancements (only x most recent, strictly oldest to newest within a podcast, priority setting between podcasts). It would require the introduction of an ‘auto-download fail’ boolean at podcast level, and consider this boolean in the auto-download eligibility check.
However, there are three scenarios that prevent us from implementing this approach. Both scenarios would cause an auto-download loop, with potential impacts on UX (frustration that one’s action is ignored), and battery & network use (downloads are attempted again and again).
- user cancels ongoing download from the Downloads screen, but auto-download re-initiates
- episode was manually or automatically downloaded and the user removes the file via the Podcast or Queue screen without having played the episode, auto-download downloads the episode again
- an auto-download fails, but auto-download re-initiates
These scenarios are much more likely if a user has only 1 subscription with few auto-download eligible episodes (with many podcasts/eligible episodes, auto-download is unlikely to pick & attempt downloading of the same episode).
- The third scenario could be prevented by extending the number of retries and implementing a block & warning at episode level (see ‘We might increase the number of failed retries…’).
- The second scenario could be prevented by the introduction of the ‘Ignored’ status (#5237), which could potentially be set when a user removes the download.
- However, for the first scenario we don’t really see a solution (apart from keeping the boolean at episode level); cancelling a download may be for network/battery/timing reasons and should not also set an episode to ‘ignored’.
However, we did not discuss yet in detail whether we should check the podcast auto-download setting in the eligibility process, in addition to checking the episode boolean. Doing so means we only need to change the auto-download boolean at episode level for the three scenarios described in the technical details above. This would have the benefit of maintaining episode-level data when the podcast-level setting is changed.
Effects of changing the auto-download setting at podcast level
Given that we keep (and rely more on) the auto-download boolean at episode level, we must consider what happens with this boolean when the user changes the podcast setting.
Technical details
- User adds podcast
- for most recent episode: enable
- for all past episodes: disable
- for all future episodes (as per setting; see next points)
- User enables auto-download for a podcast:
- for future episodes: enable
- for past episodes, we have several options:
- disable → selected solution (for now; see next point)
- keep as is → to implement if & when Ignore status is introduced; especially relevant when auto-download setting is introduced to make eligible episodes which are not in inbox and not ignored (Keunes’ desired feature)
- ask user → this we did in the past, but it was confusing
- User disables auto-download for a podcast:
- for now: disable for all (past & future) episodes
- if/when Ignore status is introduced:
- keep as is for all past episodes, so that previous actions (e.g. Ignore) are not overwritten and episodes would be considered for auto-download again if re-enabled at podcast level
- tbc for all future episodes
- add auto-download eligibility check on podcast level
Updates might be needed depending on whether we add auto-download check on podcast-level setting, as described above.
Uncoupling Inbox & Auto-downloads
The starting point of the discussion was a review of the three scenarios:
- Add to Inbox
- want to review all episodes for worthiness, using Inbox
- Skip inbox, include in auto-download/add to queue
- want to listen to all episodes; #5246
- Skip inbox, exclude from auto-download
- want my episode data to be updated (keep refreshing) but only manually download/stream an episode once in a while
- want to review all episodes for worthiness, using notifications; #6671 (comment)
As mentioned above, auto-download will only consider episodes in the inbox - preventing scenarios 2 & 3 (if the user hit their episode cache limit; otherwise current situation is fine). So to enable these three scenarios we need to decouple the Inbox and the Auto-download mechanism.
For this, we can take either of two technical approaches. Both will (should) result in the exact same behaviour for end-users. We decided to do the following: Get rid of the Inbox check, and only rely on auto-download boolean at episode level.
Technical details & discarded option.
The chosen solution implies that we need to set the auto-download boolean to No:
- when user removes an episode from the Inbox
- upon feed refresh, if the user has selected scenario 2 or 3 for the episode’s podcast
The discarded option was to extend eligibility from Inbox & Queue to also podcasts which are set to 2nd scenario. Considering that we want/need to keep the auto-download boolean at episode level, this approach introduces another layer while the chosen solution removes a layer (i.e. simplifies things).
Effect of decoupling Inbox & auto-download
Affects, based on user’s settings:
- New episode action = Inbox && auto-download = enabled
- Current situation: your Inbox only contains not-downloaded episodes (because auto-download is considered an action, which removes from Inbox; if it fails, it is put back in the Inbox)
- After change: your Inbox may contain downloaded episodes IF you run into the cache limit (because why?)
- @ByteHamster can’t we keep existing behaviour? We could remove from Inbox upon succesful (auto-)download, no? This would also be in line with what I noted on ‘migrating existing users’ - maybe this was already the plan and took wrong notes?
- New episode action = None && auto-download = enabled
- Current situation: episode is nowhere (because it never reaches the Inbox, it will also never be downloaded and reach the Queue)
- After change:
- IF episode cache limit is not reached: episode in Queue IF ‘Enqueue downloaded’ is enabled (suggestion to take out this condition: #6837)
- IF episode cache limit is reached: episode is nowhere (not in Queue & not in Inbox)
Merging the ‘New episodes action’ and ‘Include in auto downloads’ settings
We currently have two podcast settings: ‘New episodes action’ (Global default; Add to Inbox; Nothing) and ‘Include in auto downloads’ (Yes; No). We thought about merging these settings, with the three options being as per the three scenarios above. But we decided not to do that.
Reasoning
- Usability: Merging the settings might make it harder to understand & pick the right option.
- Visibility: Merging them makes it harder to find auto-download setting of a podcast. As the global auto-download setting might be dropped (it being ‘always on’), visibility of this setting at episode level is even more important.
- Future readiness: Keeping them separate enables us to expand the ‘new episode action’ with new options in future, e.g. ‘Add to queue’.
New global setting ‘Auto download pool’
Keunes’ desired functionality, is to use the Inbox as a review tool.
- ‘pass the inbox test’ → action = Remove from Inbox
- ‘fail the inbox test’ → action = Ignore
It was briefly discussed as it would affect the auto-download eligibility check.
Technical details
Auto-download then should only consider episodes that have ‘passed’ the test. To enable this, a new setting would probably be needed (as it might not work for everyone):
‘Auto download pool’
Which episodes should the auto download system consider? Ignored episodes and episodes from podcasts with auto download disabled are never considered.
- All episodes
- technical implementation: as described throughout this post
- Episodes not in the Inbox
- technical implementation: in eligibility check, remove episodes in Inbox
Initially the first option was ‘Episodes in the Inbox’, but as we decided to decouple auto-downloads from the inbox, this setting name is not entirely correct. We could replace the option ‘All episodes’ with ‘Episodes in the Inbox and episodes of podcasts in scenario 2’. That would be better (more useful for users) but it would be hard to (find wording to) make it easy to understand for users.
‘New episode’ notifications
The ‘New episode(s)’ notifications are currently (tightly) linked to the Inbox: it opens the Inbox screen and displays the number of episodes in the inbox for a given podcast. However, as you can now set a podcast to skip the Inbox, the notification no longer fully works. We need to change the way these notifications are set up.
Four options & their technical details
- Only present most resent episode → Downside: we loose the number of total new episodes.
- Single notification for each episode, grouping:
- all New episode notifications → Downside: if one podcast messes up a feed you can get many notifications, which you can then all swipe away, but you will also ‘loose’ the single new episodes of other podcasts. And you don’t have the number of new episodes per podcast.
- the New episode notifications of a given podcast → Upside: action per episode possible (Ignore, Download, Enqueue) & system shows number of episodes per podcast. Downside: if you have notifications enabled for many podcasts and they all have one or two new episodes, you have a long list of notifications.
- Yet it seems to me that in Android 14 all notifications are grouped by app, so having one notification per podcast wouldn’t necessarily harm (they can all be swiped away in one go still). @ByteHamster, couldn’t we go for this option after all?
- Introduce case distinction, depending on whether user has new episode action = None (episodes not in Inbox) for at least 1 podcast (if yes: 1 notification per episode rather than per podcast, open podcast screen rather than Inbox) → Downside: unnecessarily complicated & unexpected UX for user if they change a podcast setting.
- Keep as is: notification per podcast, update existing notification upon new episode, display number of episodes in inbox. BUT don’t display the total number of episodes IF ‘New episode action’ = None for that podcast → This was selected for development, as it is closest to current behaviour.
No decision was made on whether to open Inbox or Podcast screen. Keunes’ suggestion:
* Open Episode screen if 1 episode
* Open Podcast screen if 2+ episodes (even though it means less visibility for the Inbox). Relevant only if we keep notification per podcast.
This probably needs some follow-up discussion & decision.
Migrating existing users’ settings
If at some point we change behaviour such that auto-downloaded episodes are not removed from Inbox, then should we set existing users’ ‘New episode action’ to None for podcasts that have enabled auto-download?
- Yes:
- would keep behaviour similar IF the user is not hitting the cache limit.
- would make episodes ‘hidden’ IF user is hitting the cache limit.
- No → As we’re not getting a clear benefit/expected behaviour for all users, we will not intervene.
Development summary:
- Remove Inbox check from auto-download eligibility check (consider all episodes in database)
- Set auto-download boolean to No if user or episode clean-up deletes download (tbc; might be there already)
- TBC: already add in the auto-download eligibility process a check for the auto-download setting at podcast level
- if yes, remove changes to episode auto-download boolean when podcast setting is changed)
- if no, set auto-download boolean of episodes to No when auto-download is disabled at podcast level
- TBC: inbox notifications need some rework