Feature Request: Progress on large individual files in overview


(ellnic) #1

Not sure if this is easily doable or not, but:

I am now using the large blocks setting on a couple of folders (which works very well :)) and I noticed that the progress overview appears to calculate it’s percentage on a per file basis, not size basis. Last night I was trasferring a single file of about 3.18G:

progress

So as you can see from the above, even though ~2.88G of 3.18G was transferred, the progress percentage on the overview remained at 0% until completion.

Is it possible for this to be updated to reflect individual file progress?


(Audrius Butkevicius) #2

Click on the “1 items” link, it already shows progress per file.


(Audrius Butkevicius) #3

Nvm, this is for remote devices…

It should update the remote progress once every 10 or so seconds… If remote device is not under super heavy load I guess.


(Jakob Borg) #4

Or unless progress updates have been disabled, I guess.

But the short of it is - your feature request is already implemented. Devices send updates while downloading large files, and this is reflected in the UI. If this doesn’t happen for you, something else is wrong.


(ellnic) #5

Thanks both for the replies. The box the data was being sent to is a low powered ‘yesteryear’ ARM box… if the receiving end is responsible for reporting progress, could this be the culprit? It’s an old Cubietruck to be exact, so by no means a powerful device at all.


(Audrius Butkevicius) #6

Potentially. Check if you can repro on two machines that are able to cope with the load.


(ellnic) #7

Ok, so on a more capable receiving node, I get percentage at 98% (send node) while the receiving node shows the actual progress as expected.

Sender:

20

Receiver:

34


(ellnic) #8

So I can repeat this again and again … is this the current expected behaviour then? All advanced settings are defaults.


(ellnic) #9

12

2 very capable Intel CPU nodes.


(Audrius Butkevicius) #10

Can you run with STTRACE=model env var and provide the logs from both sides?


(Audrius Butkevicius) #11

Hold on, from the legend, what does orange signify? (On the phone, can’t check).


(Simon) #12

Yellow is downloaded, red/orange downloading. I would guess this is an UI issue, as in the percentage simply doesn’t take partial transfers into account.


(Audrius Butkevicius) #13

I am sure the code intended to take care of it. This could be a bigger issue.


(ellnic) #14

Here you go:

syncthing-log-send-node.log (5.2 MB) syncthing-log-recieve-node.log (16.4 MB)

Fresh configs with one shared folder added. Only setting changed in advanced is large blocks. One node is send only.

The only difference is: new node ID’s and only 1 folder.

I could reproduce like this, 0% until completion.


(Audrius Butkevicius) #15

Right, the cause is large blocks I suspect, because if memory serves me well the heuristic deciding on whether progress updates should be sent is decided on the number of blocks being over some number, which with large blocks becomes too small.

Can you test without large blocks and if this “fixes” it, raise an issue on github?

Also, I assume when you say large blocks you mean on both sides.


(ellnic) #16

Yes large blocks is set on both sides. I will check later this evening without and report back.


(ellnic) #17

I’m really sorry to report that with large blocks unchecked on both sides, the problem still occurs.


(Audrius Butkevicius) #18

You might have to try with a new file after unchecking the checkboxes as blocks are settled after the scan, so just unchecking the box wouldn’t do anything.

If it still happens then this is probably worth a github issue.


(ellnic) #19

Ah, didn’t know that. Stand by…


(ellnic) #20

Transfer isn’t complete yet, but looks like the same behaviour. I’ll open a bug on git.

Edit: Done > https://github.com/syncthing/syncthing/issues/5131