mirror of
https://github.com/Cleanuparr/Cleanuparr.git
synced 2026-02-04 12:21:33 -06:00
[BUG] Run Schedule cron option missing "5" in hours #65
Loading…
x
Reference in New Issue
Block a user
No description provided.
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?
Originally created by @cybrnook on GitHub.
Before submitting a bug report, I have:
What is the behavior?
In setting up the "Basic" scheduler, I noticed that the "Hours" option goes 1,2,3,4,6, skipping 5.
At the same time, if I may make a suggestion, it would also be nice to have the minute and second range go from 1-59, and have the hours go from 1-24.
Again, thanks for the great work in the updated direction you are headed.
Which operating system do you use?
Unraid
What type of deployment do you use?
Docker container
Relevant log output
Anything else?
No response
@Flaminel commented on GitHub:
The same goes for the other schedule types (minute and second). Also there is no need to run the queue cleaner or the download cleaner more often than 30 seconds. The content blocker is allowed as low as 5 seconds because it needs to prevent files from being downloaded. Even if 1 second was an option, I guarantee it will not run every 1 second because it will not finish the work in that time span.
@cybrnook commented on GitHub:
Hmm, in peeking at the code, seems this is by design:
fb6ccfd011/code/backend/Cleanuparr.Infrastructure/Utilities/ScheduleOptions.cs (L23)@Flaminel commented on GitHub:
Yes, it is by design. All available values render predictable behavior.
A cron expression for every 6 hours will run at: 12am, 6am, 12pm, 6pm and again at 12am next day.
A cron expression for every 5 hours will run at: 12am, 5am, 10am, 3pm, 8pm and again at 12am next day.
Notice the 4 hour gap between 8pm and 12am. This is due to how cron expressions work and that is why advanced configuration is an option. The user should opt-in for this (imho) weird behavior by using a custom cron expression.
@cybrnook commented on GitHub:
Makes sense.