I’m revisiting this now that I have a slightly better idea of how scheduling works.
I’m imagining --destination-retry-interval
and --destination-retry-interval-silent
(same but NOT reporting missing destination) parameters that would work like this:
- Job runs but sees no destination
2a. If no--destination-retry-interval
parameter abort and put back in queue on schedule as it does now
2b. ELSE abort job (potentially silently) and put back in queue for retry-interval later (unless greater than schedule based time)
This allows for use of non-continuously available destinations (including USB drives) without hogging the queue from other potential jobs.
Possible issues include NEVER being notified if a destination is “permanently” offline. This could be addressed by adding some sort of failure-notification-interval-max
that would alert if more than interval duration has passed since last successful job ruin.