Downloads tab is empty even when items are out of sync and currently downloading

[Xarishark]

Windows 11

Using the inbuilt syncthing instance

the downloads tab is always empty even if there are files currently being downloaded/synced to this PC.

[Martchus]

I've just tested this with the mocked config and it works - so at least the UI code looks still good. I'll try to reproduce this with a real Syncthing instance when I have time.

What version of Syncthing and Syncthing Tray are you using? Is this a regression as of a certain version of Syncthing Tray?

This is using download progress events (see https://docs.syncthing.net/events/downloadprogress.html). I noticed that these events are not emitted for every single file and especially when downloading (a lot of) small files the download progress is not well observable due to this. There's nothing I can do from the side of Syncthing Tray but the current behavior probably also makes sense because updating the UI for every single file would be quite some overhead. If you're downloading big files this shouldn't be the case, though.

[Martchus]

I've just tested this with a real Syncthing instance tracing the events being emitted outside of Syncthing Tray via curl.

The unfiltered event stream (curl -X GET -H "Authorization: Bearer …" 'http://localhost:8080/rest/events') returned many events (e.g. ItemFinished events) as expected but no DownloadProgress events. The filtered event stream (curl -X POST -H "Authorization: Bearer …" 'http://localhost:8080/rest/events?events=DownloadProgress') returned none of those events, too.

So I can reproduce the issue but must say that it is probably simply due to Syncthing itself not emitting such events. Here I had no big files to sync are and would generally expect that each individual file can be processed in a few seconds at most.

I guess I could try this again with bigger files. You can also test this on your setup by running the mentioned curl commands (with your port and API key) alongside Syncthing when you'd expect download progress to be made.

Considering the limited usefulness it might be a good idea to hide the downloads tab by default and add an explanation with the caveats in the settings UI where one could still enable it.

[Martchus]

I nevertheless had a look at Syncthing Tray's code/behavior and this was actually nevertheless broken also in Syncthing Tray itself. It broke when I did many connection-related changes in August (see https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/215).

[Xarishark]

Sorry for not answering faster as I was swamped with work.
I am using the packed version of syncthing as I dont have a separate instance installed.

I have sync about 1TB in the past month and I never saw the download tab working to be honest.

Is there away to convert the tab to a TRANSFER tab.
So it can show the downloading files but also the files that are being send or if transparent to your front-end at least show the devices that are currently pulling files from the local instance. I know I can see that on the devices tab but it would be much more useful to have both ways in one tab as a easy to access overall view without the need to open the web-UI. thanks in advance for your time

ZX

[Martchus]

As I said, the downloads tab was broken to a regression in Syncthing Tray until I fixed it 3 days ago. So it is no surprise that you never saw any downloads within that last month.

Out of my head I'd say no, that's not possible because Syncthing doesn't provide an API for transfers like that. Maybe I'm misunderstood what you're asking, though. So maybe you can restate what Syncthing Tray is supposed to show in terms of a Syncthing API route providing this information.

[Xarishark]

What I am describing is a TRANSFER tab( same as other tabs) that shows on top the clients lets say that are pulling data and under that in a separate line the files that are downloading (current function of download app) if no client is pulling data then the top of the list will be empty. so priority of info is clients that we upload data to -> seperation line after the last client -> current data that the download tab would show.

if you wanted to see all devices in general you could still see them in the devices tab that also shows the current status (syncing etc)

[Martchus]

Ok, then I think Syncthing has no API for this. I can double-check that when I have the time, though.

Note that this would be a bit of an effort to implement in any case and I'm already busy with other things right now so don't expect me to work on it anytime soon.

[Xarishark]

No expectations AT ALL! Just a suggestion. your app already does amazing stuff. If I have the knowledge I would try to help to.

[Martchus]

Note that there's an event for remote downloads: https://docs.syncthing.net/events/remotedownloadprogress.html

I don't think it necessarily means that the other device is downloading from us, though.

[Xarishark]

If it indicates which device is downloading then the tab in my example can be split 3 ways. 1)downloading files to this device 2)uploading from this devices 3)(optional)transfer from device x to x(non local transfer)

[Martchus]

This is supposed to be fixed in the latest release in the sense that the downloads tab should not be empy anymore as long as Syncthing itself emits DownloadProgress events.

I must say I haven't paid much attention to the downloads tab when Syncthing was downloading big files and as mentioned in #293 (comment) the DownloadProgress even doesn't seem to be emitted for small files. Could you meanwhile test whether download progress is shown with the latest version of Syncthing Tray (at least for big files when keeping the downloads tab selected for a few seconds)?

I suppose it would make much more sense to query pending items initially when one selects the downloads tab via the REST API. Then ItemStarted and ItemFinished events can be used to stay up to date. This way it wouldn't rely on problematic DownloadProgress events anymore. This is what I'm currently trying to implement for the mobile UI with Qt Quick. It would be a bigger rewrite to use the approach as well in the Qt Widgets based tray app but maybe I'll get to it eventually. Maybe it would make sense to hide the downloads tab until then (at least by default) because in its current state it is rather unpolished.