Global log wierdness

Well I’m not sure why but it seems changing themes (and possible a few other actions I haven’t seen yet) removes everything from the Global change log feature I just put into v0.14.17. At least temporarily until another file syncs… then everything comes right back again. It might just be an unintended “feature” of the GUI but changing themes isn’t a usual thing that users do often anyway, so no big deal I guess.

Not sure why it’s doing that, just letting others know I’m aware of it, if they also run into it.

It fetches last N available things, which might roll off or take a while to populate after a refresh.

Not completely related, but it takes very long time to load the list.

Once Web UI is up and loaded (and let it settle for a few minutes), from click on “Global Changes” to it actually showing something other than non-empty list it takes more than 15 minutes to load.

I monitored it for 15 minutes, gave up, and when I got back about an hour later, the list was up…

Maybe my config is too big (~50 folders, ~20 devices), but such long wait times are still not very reasonable.

The log is not persisted, so will vanish after restart, as well as is refreshed and populated only as activity happens.

Even without restarts - just closing and later reopening WebUI will result in >15 min wait time until the list will be populated again.

I understand that those might be technical limitations of the implementation. Maybe I’m unreasonably impatient, but such long wait times treat this functionality quite unusable from my perspective…

It’s not a function of time. It’s not actually waiting to refresh anything once you reopen WebUI, It just doesn’t even retry. It only retries once a new event occurs (new write to a folder by someone).

Try this. Next time it happens, just create a new blank document and press the rescan button, (or just wait for next rescan). You should see it populate immediately.

That’s basically the behavior I was talking about earlier. It might be an easy fix it might not. I’ll see if I have some time later this week to look at it.

Hmm, I think it’s simply that I only have refreshGlobalChanges() here.

syncthingController.js $scope.$on(Events.LOCAL_INDEX_UPDATED, function (event, arg) { refreshFolderStats(); refreshGlobalChanges(); });

Maybe if I put it in $scope.$on(Events.ONLINE, function ()) {} also? I hope it’s just that easy.

I’ll try that once I get home and have some time to get my dev machine online and recompile and git and all that stuff.

Yep, this is it. Once I change a file, the list shows up promptly.

Yes, you should add it there.


Ok it was pulled into master branch so… it should be fixed in the next release.

1 Like

@scienmind 0.14.18 is out so… this should be working now.

.18 is a hotfix for broken protobuf changes, so pribably no.

Huh… wierd. Cause when I close and reopen window the log works now without having to sync a file like before.

There were no dangerous changes since .17 so .18 was a normal release from master;

* 6809d38 (tag: v0.14.18) lib/protocol: Revert protobuf encoder changes in v0.14.17 (fixes #3855) (calmh)
* 69ae4aa cmd/syncthing: Avoid Keepalive/GUI refresh race (mpx)
* 8e8b867 authors: Add mpx (calmh)
* 0a118d2 lib/config, lib/model: Temporarily disable bad tests (ref #3834, #3843) (calmh)
* 8daaa5d gui: Populate global changes on load (nrm21)
* eb14f85 vendor: Update (calmh)
* c69c3c7 lib/sha256: Smoke test the implementation on startup (hello OpenSUSE!) (calmh)
* 54911d4 (tag: v0.14.17) gui: s/foldersendonly.html/foldertypes.html (calmh)

Its hotfixness status does indeed come from being released out of schedule to fix a specific issue. :slight_smile:

1 Like

I indeed do not observe the long loading times as I did before :thumbsup:

1 Like

Don’t forget a string for localization :wink:

Localization of what.

Of the button in the GUI. Many people use the GUI :joy:

If the tag is not there, you can do it via github web editor, or it was just not picked up by the release tag generation, then its our fault.