I am really not sure how this happened, but the device was indeed set to “paused”, although this should not be possible. It was still syncing fine nevertheless. I have now modified the file manually, restarted Syncthing, and now Syncthing Tray is reporting the status correctly again.
Edit: I know how this happens! In the Web GUI, if you pause everything using the “Pause All” button, but then resume each device only separately, the own device will stay “paused”.
I could change Syncthing Tray to completely ignore the device being paused but considering that this is actually really just the state of the Syncthing configuration it feels a bit like lying.
You can easily resume your own device via Syncthing Tray itself to workaround the problem so I’ll wait until the issue you’ve created is resolved before doing any changes on my side.
Strange, I can change the paused status here. It works even when I have initially <paused>true</paused> within the Syncthing config and the status is reflected immediately and written to the config file (using Syncthing 1.13.1 under openSUSE).
I am looking at setting up ST on multiple machines running Debian Buster w/ KDE as the windowing environment… I am not thrilled by having ST as one of the many tabs in my browser and would rather have a separate task for it…
Is this something Syncthingtray would be good for? It looks like it from the Github page, but I am not sure.
Also is there a .deb package or other suitable ‘ready to run’ install package that is compatible w/ Debian, or do I need to figure out how to compile from source?
If syncthingtray isn’t the best choice for this, is there a better alternative?
There are no packages for Debian, I suggest using the AppImage to try it out and if you like it just build it yourself (see Yet another Syncthing Tray - #95 by Martchus). Note that the AppImage only features the desktop-neutral version and not the applet for the Plasma desktop.
I have recently observed that Syncthing Tray seems to be using a lot of RAM after being open for a few days.
When started, the processes use about ~50 MB of RAM each, but the usage seems to keep increasing with time. Is such a high RAM usage expected, or if not, what can I do to try to find the cause of it?
It is not expected that it uses so much memory. It is possible that Syncthing Tray or one of its dependencies leak resources. One could use valgrind to investigate this potential problem.
Note that memory freed by an application is not necessarily immediately reflected by the OS memory statistics. I once had an application with a huge in-memory db which could regenerate all the data and then throw away the old data. Throwing away the old data was not fully reflected in the OS memory statistics. However, even after weeks it never exceeded a certain memory usage after all.
I’ve checked today with valgrind under GNU/Linux and there were in fact 3 places in my code where it would leak memory. I have fixed those. However, these places can not be responsible for the growth in memory usage you’re observing. I’ve also seen some potential leaks in code of dependencies but I also doubt they would actually accumulate. I’m not sure what I can do to improve the situation.
Is there anything that I could do in Windows to help find the possible culprit? The valgrind software unfortunately seems to be available for Unix-like systems only.
Just for the record, this is what RAM usage looks like after a reboot and a few hours of work.
The previous screenshot was taken after several days of work though, so something must have happened in the meantime, but I cannot think about anything special right now that could have caused the possible memory leak.
The Qt Creator documentation links Windows users to Heob. Otherwise you’ll need to google yourself. It is possible that you one also need to use a debug build and sources for useful output.
It has been about a week since this first happened and they have been stuck like that since then. Restarting the PC, Syncthing, or Syncthing Tray does not change anything.
Do you have any idea what the problem may be about?
Since it differs from the official web UI and also persists after restarting Syncthing Tray it is likely a bug on my side. Without being able to reproduce it myself it is hard to tell what the problem is, though. If it would occur on my setup, I’d just use GDB to find out what makes Syncthing Tray behave like that.
It would be cool if I had implemented a feature to capture the Syncthing’s config/status/events. Then you could send me the files and I could load them locally in a mocked build. Unfortunately not done yet.
I can only say that now I have also tried to completely reset the Syncthing Tray settings and re-configure the connection from scratch. However, the problem is still here. The two devices keep being marked as “synchronizing”.
There seems to exist a GDB release for Windows. If I try running it with Syncthing Tray here, will the debug logs be of any use?
No, I’d use GDB for an interactive debugging session and it would require a debug build.
Maybe it would help if you would capture the traffic between Syncthing and Syncthing Tray with Wireshark. Of course you can’t use TLS for that and you need to make sure to redact all sensitive information before sharing it.
Today, I have had Syncthing Tray crash on one of my Windows computers.
The Event Viewer recorded only the following.
The program syncthingtray.exe version 1.1.3.0 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Security and Maintenance control panel.
Process ID: 1244
Start Time: 01d7211ed6e0c5d1
Termination Time: 133
Application Path: syncthingtray.exe
Report Id: a718d7bc-940f-11eb-89bd-40167e136d92
Faulting package full name:
Faulting package-relative application ID:
This happened when the machine was locked and idle, so there was nothing special going on there, except for Syncthing running. Unfortunately, there doesn’t seem to be anything else recorded anywhere in any Windows log files, etc. Syncthing Tray itself does not seem to be recording any logs, or does it?
No, it doesn’t record any logs. If it was Linux I’d inspect the coredump via GDB although that’s also not that helpful unless a debug build was used. Unfortunately I doubt I can do anything at this point.
Note that it is a known bug that tests currently don’t pass. It is not a regression of the new version but I have to adapt my code to Syncthing v1.15.1.
Maybe Syncthing devs know more about the change within Syncthing itself:
[12:13] Were there any changes about querying the completion of paused devs/dirs? I’m asking because my test setup for Syncthing Tray does that and I now apparently get a 404 error where I previously got 200: syncthingtray test 2 fails · Issue #102 · Martchus/PKGBUILDs · GitHub
[12:14] Not sure whether I’ve got any useful data before, though. Maybe I should just ignore the 404 error in case of paused dirs/devs or not do this request in the first place.
