starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Enhancement]: respect ttl element if present for podcasts (rss) #1527

New Issue
Open
opened 2026-04-24 23:48:50 +02:00 by adam · 2 comments
adam commented 2026-04-24 23:48:50 +02:00
Owner
Copy Link
Copy Source

Originally created by @zeridon on GitHub (Nov 15, 2023).

Describe the feature/enhancement

The RSS 2.0 Specification outlines an optional TTL channel element defining how long a feed can be cached (before new fetch). It can be used to automatically set the autoDownloadSchedule to reduce server (both abs and podcast).

Originally created by @zeridon on GitHub (Nov 15, 2023). ### Describe the feature/enhancement The [RSS 2.0 Specification](https://www.rssboard.org/rss-specification#optionalChannelElements) outlines an optional `TTL` channel element defining how long a feed can be cached (before new fetch). It can be used to automatically set the `autoDownloadSchedule` to reduce server (both abs and podcast).
adam added the enhancement label 2026-04-24 23:48:50 +02:00
adam commented 2026-04-24 23:48:51 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Nov 15, 2023):

I'm trying to think of how the UI should change to accommodate this. I don't think it should automatically change the download schedule because:

  1. If the UI updates automatically, users may be confused why their settings were changed (or think their changes are not saved)
  2. If the UI does not update and only happens in the background, users may be confused when looking at the logs and saying "there should be a download check here but there isn't"

Maybe the best option is to have an indicator underneath the scheduler (right above "Next scheduled run") that shows whether the RSS feed has a TTL field and displays the TTL there. The TTL is taken into account for the displayed "next scheduled run".

If an RSS feed has a TTL, should the download manager check for new episodes immediately, or wait for the next scheduled run?

I'm thinking "Check immediately if it missed a cron time, otherwise wait for the next cron time."

@nichwall commented on GitHub (Nov 15, 2023): I'm trying to think of how the UI should change to accommodate this. I don't think it should automatically change the download schedule because: 1. If the UI updates automatically, users may be confused why their settings were changed (or think their changes are not saved) 2. If the UI does not update and only happens in the background, users may be confused when looking at the logs and saying "there should be a download check here but there isn't" Maybe the best option is to have an indicator underneath the scheduler (right above "Next scheduled run") that shows whether the RSS feed has a TTL field and displays the TTL there. The TTL is taken into account for the displayed "next scheduled run". If an RSS feed has a TTL, should the download manager check for new episodes immediately, or wait for the next scheduled run? I'm thinking "Check immediately if it missed a cron time, otherwise wait for the next cron time."
adam commented 2026-04-24 23:48:51 +02:00
Author
Owner
Copy Link
Copy Source

@zeridon commented on GitHub (Nov 15, 2023):

Some context maybe.

I am long time user of FeedWordPress aggregator system and got the idea from there. There it has been realised as follows:

  • On adding the new feed the schedule is according to TTL (e.g. 240 -> check for new every 6 hours)
  • There is an option to override with your schedule (e.d. every hour no matter what the feed says)
  • There is an option to speed up checks (e.g. TTL is 30 but your frequency is 60)
  • There is an option to slow down, because you might have changed your mind or the feed introduced the tag (e.g. TTL is 120 but frequency is 60)

Generally from UX/UI point of view:

  • On adding a new feed - default to feed TTL (or the closest one down) - probably the creator knows better
  • On edit disregard the TTL
  • For changed feeds (e.g. TTL appeared/disapeared/changed) ignore the change
    • If you desire to improve on this - if schedule has not been changed follow the change if ttl is changed otherwise ignore
  • If cron is missed do the check as soon as possible.
  • Add documentation - as i found that side very lacking (can try to draft something)

If time/value permits implement speedup/slowdown of checks in regards of when having custom schedule that does not align with the one the feed suggests.

On the next scheduled run display if implemented in "No unexpected stuff hapening in the UI" principle outlined above the indicator itself is not needed anyways.

@zeridon commented on GitHub (Nov 15, 2023): Some context maybe. I am long time user of FeedWordPress aggregator system and got the idea from there. There it has been realised as follows: * On adding the new feed the schedule is according to TTL (e.g. 240 -> check for new every 6 hours) * There is an option to override with your schedule (e.d. every hour no matter what the feed says) * There is an option to speed up checks (e.g. TTL is 30 but your frequency is 60) * There is an option to slow down, because you might have changed your mind or the feed introduced the tag (e.g. TTL is 120 but frequency is 60) Generally from UX/UI point of view: * On adding a new feed - default to feed TTL (or the closest one down) - probably the creator knows better * On edit disregard the TTL * For changed feeds (e.g. TTL appeared/disapeared/changed) ignore the change * If you desire to improve on this - if schedule has not been changed follow the change if ttl is changed otherwise ignore * If cron is missed do the check as soon as possible. * Add documentation - as i found that side very lacking (can try to draft something) If time/value permits implement speedup/slowdown of checks in regards of when having custom schedule that does not align with the one the feed suggests. On the next scheduled run display if implemented in "No unexpected stuff hapening in the UI" principle outlined above the indicator itself is not needed anyways.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#1527
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?