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

[zeridon]

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).

[nichwall]

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."

[zeridon]

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.