Server not yet started, manual backup should be #1 in queue

UX
1

Hi,

my Duplicati has a “Pause after startup or hibernation” delay. So there may be scheduled jobs in the queue.

Now if I manually start a backup, Duplicati asks me to start the server, which I do, but then does not execute my explicit will which I insisted on. Duplicati thinks it should start all queued jobs first. So I have to cancel them all one by one which is really weird.

But in my opinion the users will should be respected.

TLDR:
If server not started and user clicks “Run now”, this job should go on top of the queue. Currently it behaves like a stack.

2

That makes perfect sense to me.

The current behavior seems to be a result of the datatype queue in C#. It doesn’t have a built in concept of placement, so you can only enqueue or dequeue items in the correct order (first in, first out).

I’ve made a pull request #3003 that deals with this and creates the expected behavior when Run now is pressed.

It should be noted that if a job is already running this change will not interrupt the running job as it just puts the selected job at the front of the queue.

1 Like
3

If a backup is currently running: A “run now” request could even be followed by a required user input with the entries:
[Cancel running backup: yes, but uploading of last file]
[Cancel running backup: yes, instantly]
[Cancel running backup: no, queue after running backup]

4

I’m not sure if a prompt is more user-friendly than simply having the user cancel the running job.
But that might just be because I have a dislike for prompts.

5

Personally, I like prompts as it provides an option to keep the “it should be queued” and “it should run right now” sides happy. I particularly like them when they have a timed default (such as “Cancel running backup: No, queue after current process finishes” in this case)

6

Hmm, fair point. It might not be obvious to the user that their job is queued next and that it will run right away if they cancel the current job. I guess a prompt there would actively inform the user.

Either that or having some other UI indicator of the queue.

But I still dislike prompts because I’ve seen too many applications that have too many prompts constantly interrupting my work flow :slight_smile:

7

I suppose in this specific example an alternative could be to have more “Run” links such as:

  • “Run now” (abort current)
  • “Run soon” (after current upload finishes)
  • “Run next” (after current process finishes)
  • “Add to queue” (current functionality, but maybe have a tool tip of how many items are in the queue)
1 Like
8

Now we’re cooking with gas.

It’s what I’ve always loved about Itunes as a media player. They just got that sometimes you want to start a song now and sometimes you want to play it next, or maybe just play it after your current list finishes.

9

Heh - I’m glad you like the idea. Of course the server still needs to be updated to support such features, and of course you should expect lots of discussion about keeping the GUI clean with so many (potentially wordy) links. Keep in mind the GUI has to be usable in more than just English…

A single select box could provide those features about the same space currently used, but tool tip style descriptions of which does what become more difficult.

10

I’ll implement the backend code required to support the buttons if we can find a neat way to put them there :slight_smile:

1 Like
11

Yes, that is discussed here, including cool indicator icons: