OK. I admit that this is an inconsequential nit: When running “commandline” commands from the GUI, it always says “Starting backup…” in the status block, even if I’m running a different command (i.e. list, delete, verify, purge, etc.). Has this been cited before?
I appreciate that there are probably zero resources to fix this (or is it a “feecher”?). Just putting it out there.
Thanks for listening… Steve
I’m with you on both the fact that it’s not very important but also kind of annoying. I have panicked multiple times after clicking ‘Run “xxxx” command now’ and seeing it mention a backup. Then again, I’ve also forgotten to actually change the command away from “backup” when I meant to, too!
I’ve been meaning to look into how simple it would be to modify this. While I was at it, I was planning to see how easy it would be to have another instance of that ‘Run “xxxx” command now’ button at the top right, (or permanently in the lower right of the window as you scroll) since I have some backups with a LOT of extra options.
L
There’s this:
So at least once, although I can’t find the exact issue in a short search. You could open one…
If you open one, you might consider being specific. Some commands only suffer some delays.
To topic title “Why does the GUI always say”, my theory is that an uninitialized variable does it.
Enumeration types (C# reference) shows how integer zero corresponds to the first name seen:
To actually show that in the web browser, JavaScript converts the phases to a text string in
8.3.3 Default constructors says that the default value of an int is 0, which would give the above string.
UpdatePhase seems to be the way to set phase. Repair seems to not call that at all. Others call after other work, for reasons not immediately clear. Using the Verify files button delays a few seconds.
Starting and ending are always a little unclear. Sometimes there are things, e.g. run-script-before and run-script-after that specifically say that they mean before and after the operation, so because I run a fairly slow script after backup itself (to check the results), I’m staring at “Backup complete!” for awhile, waiting for things after to end. There might be preparations at start. Ideally they would be announced, however I’m not sure if the phase infrastructure is tied to the operation or can move to broader scope.
There’s definitely some of the code that knows more quickly. I see the following Information in the log:
2023-03-26 20:06:01 -04 - [Information-Duplicati.Library.Main.Controller-StartingOperation]: The operation Test has started
and a Repair also shows this sort of message in spite of its phase information seemingly not updating:
2023-03-26 20:30:01 -04 - [Information-Duplicati.Library.Main.Controller-StartingOperation]: The operation Repair has started
If nothing else, perhaps a new phase called Preparing could be the initial phase, until better is known.
Of course that begs the question “Preparing what?”, but possibly less so than “Starting” did, leading to:
“Starting …” message could be clearer: starting what? #3141
GUI - Added detail to the status messages #3147 which changed a vague term to a precise-but-wrong, however the vague term was probably only accidentally correct because it landed on “Starting …” by a fortunate accident of it being 0. I sure hope the original code wasn’t done intentionally to land that way.
Deleting never used configuration appears to trigger backup #3513 is the 2020 version of enum theory.
There’s a little bit more (and a link there) in a 2021 forum post here.
Build progress display into all operations [incl. “Starting backup …”] #4121 was thought to be database upgrade on a 24 GB database, which could take awhile, and might be before the operation itself starts, depending on what one considers the start. It’s the usual issue of how much detail status bar deserves.
If you file an issue, please link back here and preferably help out by being specific, e.g. does it persist? Repair seems persistent. Verify seems temporary. You can help identify cases by testing and watching.
Maybe someday someone will volunteer to do at least some type of improvement after studying further. Duplicati only exists and improves thanks to people who volunteer in some way (and it’s not only code).
Oh good! I see a volunteer showed up while I was putting this big post together. Hopefully it will help…
It’s not always there? If so, I guess I hadn’t noticed that happen.
This is a good lead in to my comment that sometimes the command output (GUI or real) is an easy way to gather insight into late status bar phase change. For example, you can see test do a list then phase. This actually looks like pretty much what the code actually does:
That last line is what moves the phase from my alleged not-initialized-right default to “Verifying files …”
Papercuts: Round Two is the Firefox UX team seeking behaviors they’ve defined as
What we’re after is the “paper cuts”, the stuff that gets in the way or annoys you about Firefox on a daily basis, and that we could help get prioritized.
There are probably some in the forum nicely filed in UX category or maybe Features.
While I think things like backup failures are big deals, some of these are worth doing.
I’m not sure who would be our UX team. They can help prioritize the pile of requests.
Some might be in GitHub too. After that, it’s then a question of volunteers to do code.
Watching port 8200 in Wireshark is one way to see what the server is telling the browser JavaScript.
For example, doing test, the progressstate from the browser gets below first, and second later…
...{
"BackupID": "1",
"TaskID": 34,
"BackendAction": "List",
"BackendPath": null,
"BackendFileSize": 0,
"BackendFileProgress": 0,
"BackendSpeed": -1,
"BackendIsBlocking": false,
"CurrentFilename": null,
"CurrentFilesize": 0,
"CurrentFileoffset": 0,
"CurrentFilecomplete": false,
"Phase": "Backup_Begin",
"OverallProgress": 0.0,
"ProcessedFileCount": 0,
"ProcessedFileSize": 0,
"TotalFileCount": 0,
"TotalFileSize": 0,
"StillCounting": false
...{
"BackupID": "1",
"TaskID": 34,
"BackendAction": "Get",
"BackendPath": "duplicati-bd7954fd92a1e4b42836e55faf5561c22.dblock.zip.aes",
"BackendFileSize": 52427821,
"BackendFileProgress": 52427821,
"BackendSpeed": 3560056,
"BackendIsBlocking": false,
"CurrentFilename": null,
"CurrentFilesize": 0,
"CurrentFileoffset": 0,
"CurrentFilecomplete": false,
"Phase": "Verify_Running",
"OverallProgress": 1.0,
"ProcessedFileCount": 0,
"ProcessedFileSize": 0,
"TotalFileCount": 0,
"TotalFileSize": 0,
"StillCounting": false
Poorly worded on my part. Yes, it is at the bottom right of the page. What I was suggesting is always have it at the bottom right of the window (not page). Same concept (different location) as this: How To Create a Sticky Element