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]: Managing auto disabled rss schedules #2500

New Issue
Open
opened 2026-04-25 00:07:47 +02:00 by adam · 8 comments
adam commented 2026-04-25 00:07:47 +02:00
Owner
Copy Link
Copy Source

Originally created by @ScuttleSE on GitHub (Jan 18, 2025).

Type of Enhancement

Web Interface/Frontend

Describe the Feature/Enhancement

As I understand it, if a podcast feed fails 24 times, its schedule "silently" deleted. No indications in the UI, just the logs.

The only way to re-enable the schedule is to manually edit the podcast-feed and create a new schedule.

If your internet-connection goes out for a while, or if you have any amount of extended downtime, you will then have to manually create a new schedule for every podcast you subscribe to.

Combined with the fact that the default schedule is to check hourly, you technically only have to be offline for one day for all your podcast-downloading to completely break down...

My suggestion is:

  • Don't delete a schedule for a podcast, just disable it.
  • Clear notification when a podcast schedule is disabled (not deleted). An overlay-icon in the UI and a message in the web UI for example
  • Easy, one-click way to re-enable the existing schedule. Clicking the "this podcast is no longer updating" icon suggested above perhaps.
  • Setting to adjust how aggressive the mechanism for auto-disabling a schedule should be.
  • Option to completely disable this mechanism.

Why would this be helpful?

It would be useful to not have the application silently delete settings...

Future Implementation (Screenshot)

n/a

Audiobookshelf Server Version

v2.7.17

Current Implementation (Screenshot)

No response

Originally created by @ScuttleSE on GitHub (Jan 18, 2025). ### Type of Enhancement Web Interface/Frontend ### Describe the Feature/Enhancement As I understand it, if a podcast feed fails 24 times, its schedule "silently" deleted. No indications in the UI, just the logs. The only way to re-enable the schedule is to manually edit the podcast-feed and create a new schedule. If your internet-connection goes out for a while, or if you have any amount of extended downtime, you will then have to manually create a new schedule for every podcast you subscribe to. Combined with the fact that the default schedule is to check hourly, you technically only have to be offline for one day for all your podcast-downloading to completely break down... My suggestion is: - Don't delete a schedule for a podcast, just disable it. - Clear notification when a podcast schedule is disabled (not deleted). An overlay-icon in the UI and a message in the web UI for example - Easy, one-click way to re-enable the existing schedule. Clicking the "this podcast is no longer updating" icon suggested above perhaps. - Setting to adjust how aggressive the mechanism for auto-disabling a schedule should be. - Option to completely disable this mechanism. ### Why would this be helpful? It would be useful to not have the application silently delete settings... ### Future Implementation (Screenshot) n/a ### Audiobookshelf Server Version v2.7.17 ### Current Implementation (Screenshot) _No response_
adam added the enhancement label 2026-04-25 00:07:47 +02:00
adam commented 2026-04-25 00:07:47 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Jan 18, 2025):

Related to https://github.com/advplyr/audiobookshelf/issues/3455

@nichwall commented on GitHub (Jan 18, 2025): Related to https://github.com/advplyr/audiobookshelf/issues/3455
adam commented 2026-04-25 00:07:47 +02:00
Author
Owner
Copy Link
Copy Source

@radonmiser commented on GitHub (Mar 24, 2026):

I got hit by this and re-enabling 100s of feeds manually seems impractical. At this point the only choice is to stop using ABS for podcasts.

@radonmiser commented on GitHub (Mar 24, 2026): I got hit by this and re-enabling 100s of feeds manually seems impractical. At this point the only choice is to stop using ABS for podcasts.
adam commented 2026-04-25 00:07:48 +02:00
Author
Owner
Copy Link
Copy Source

@Vito0912 commented on GitHub (Mar 24, 2026):

Imho hitting 24 should be impossible for an "outage" if not abusing the RSS feed, but iirc there is MAX_FAILED_EPISODE_CHECKS as an env which lets you specify how many fails are allowed. 0 should disable it

@Vito0912 commented on GitHub (Mar 24, 2026): Imho hitting 24 should be impossible for an "outage" if not abusing the RSS feed, but iirc there is `MAX_FAILED_EPISODE_CHECKS` as an env which lets you specify how many fails are allowed. 0 should disable it
adam commented 2026-04-25 00:07:48 +02:00
Author
Owner
Copy Link
Copy Source

@cgsmith commented on GitHub (Mar 26, 2026):

Just want to chime in to say I would love an option like this:

Option to completely disable this mechanism.

@cgsmith commented on GitHub (Mar 26, 2026): Just want to chime in to say I would love an option like this: > Option to completely disable this mechanism.
adam commented 2026-04-25 00:07:48 +02:00
Author
Owner
Copy Link
Copy Source

@radonmiser commented on GitHub (Mar 26, 2026):

Imho hitting 24 should be impossible for an "outage" if not abusing the RSS feed, but iirc there is MAX_FAILED_EPISODE_CHECKS as an env which lets you specify how many fails are allowed. 0 should disable it

the fact is it can happen with stock abs and default rss setup, and the users effected still have no way out other than manually re-enabling each feed.

@radonmiser commented on GitHub (Mar 26, 2026): > Imho hitting 24 should be impossible for an "outage" if not abusing the RSS feed, but iirc there is `MAX_FAILED_EPISODE_CHECKS` as an env which lets you specify how many fails are allowed. 0 should disable it the fact is it _can_ happen with stock abs and default rss setup, and the users effected still have no way out other than manually re-enabling each feed.
adam commented 2026-04-25 00:07:48 +02:00
Author
Owner
Copy Link
Copy Source

@Vito0912 commented on GitHub (Mar 26, 2026):

@cgsmith As stated above, if you set the env to 0 it should disable this completely iirc. If not just set it to 9999 e.g.

@Vito0912 commented on GitHub (Mar 26, 2026): @cgsmith As stated above, if you set the env to 0 it should disable this completely iirc. If not just set it to 9999 e.g.
adam commented 2026-04-25 00:07:48 +02:00
Author
Owner
Copy Link
Copy Source

@cgsmith commented on GitHub (Mar 27, 2026):

Thanks @Vito0912 - missed that point (clearly). I'll take a crack at a PR for this issue soon.

@cgsmith commented on GitHub (Mar 27, 2026): Thanks @Vito0912 - missed that point (clearly). I'll take a crack at a PR for this issue soon.
adam commented 2026-04-25 00:07:49 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Mar 27, 2026):

Thanks Vito0912 - missed that point (clearly). I'll take a crack at a PR for this issue soon.

The web client front-end is currently being migrated and rewritten, so PRs for it are not being reviewed or merged. Not sure exactly what you are planning to do for it, but just FYI.

@nichwall commented on GitHub (Mar 27, 2026): > Thanks Vito0912 - missed that point (clearly). I'll take a crack at a PR for this issue soon. The web client front-end is currently being migrated and rewritten, so PRs for it are not being reviewed or merged. Not sure exactly what you are planning to do for it, but just FYI.
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#2500
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?