Device: darwin, Apple M4 Pro
Client ID: 762efcd0dfd5456fa053f5bab8bbb1e6
Sync Version: 3
Profile Version: 49
Keychain Supported: Yes
Alternative instance ID: -
Sync target: Joplin Server
Editor: Markdown
Revision: 7e2765a
Backup: 1.5.1
Freehand Drawing: 4.3.0
Sync target
Joplin Server
What issue do you have?
When I open Joplin, it immediate starts syncing even though I went into settings and set synchronization interval to "disabled". I've closed and re-opened the application several times, and also clicked on the "cancel" button the bottom left of the window several times. It won't stop.
I'm trying to troubleshoot a connectivity issue and I need Joplin to not sync automatically while I'm troubleshooting the connection to the sync server.
I think I have the same problem. The app is also not saving new notes or downloading new ones from other devices (everything works fine on all my other devices).
Sounds like the initial sync has not completed yet. If you are using a mobile device, ensure the screen is turned on constantly and the Joplin app in the foreground until the synchronise button in the sidebar stops spinning, and pressing the synchronise button stops within a few seconds when pressed again
You cannot disable the synchronisation on startup. If you need to do some tests without the sync, you can just disconnect the internet on your device before opening Joplin?
Joplin is very much supposed to be under the control of the user - I've always thought that was a core part of the thinking behind it and it's what many of us love about it.
So I'm really surprised that if we set sync to "disabled" it is not in fact disabled. I and others just want sync to be operated manually when we deem it to be necessary - eg not when opening the app and not when editing a note. I really think the option to switch off this "push" sync should be made available. I'm also almost convinced this didn't used to be the case.
Case in point - Electron causing to Joplin to majorly slow down while editing heavy notes. I'm often in a situation whereby the app is beginning to lag while pasting in lots of text (this is on a powerful desktop i9 system) and things start to lag and grind to a halt and become unusable - known Electron issues of course. But then the problems are seriously compounded by the fact that at that moment Joplin decides it would be a good time to sync! The app then freezes for long periods of time.
TL;DR - sync disabled really should mean disabled. Please can this be re-examined?
I think those Electron issues tend to be related to hardware accelleration? I've never personally experienced this issue with an Electron app, but I have experienced stutter in other apps due to hardware accelleration. I haven't tested it, but ChatGPT suggests you can turn it off by passing the --disable-gpu command line argument to the Joplin executable. Maybe you could try that?
I think the forced auto sync has been a point of contention in the past. While Laurent tries to give users lots of flexibility, he can only go so far without creating a maintenance / support burdon. In particular, the sync is a significant generator of support requests, and making a way for the user to potentially cause more sync conflicts, for the benefit of a minority who want more control over this, just adds to the burdon.
I would say though that the name of the sync interval setting could do with being named more accurately, to make it clear it only applies to syncing incoming changes (with the exception of an initial sync upon starting the app)
I'm having the problem on a laptop, and it's been trying to sync for days, hours at a time. The app is unusable, and nothing I do stops the syncing (including reinstalling the app).
Thanks @mrjo118, I've tried this but it doesn't make a difference to this issue. I think it's perhaps to do with a lot of Javascript threads running at once and the app/Electron can't keep up under load?
For what it's worth on the desktop app the issue with heavy, long notes seems to be mainly with the Rich Text Editor; the problem is you're literally talking about a complete lockup with a long note so you can't just flick to the markdown editor. This is on a powerful 12900K system with 64 GB fast DDR5 and an NVM, so the bottleneck seems to be the app, the way the RTE's coded or Electron.
But even without handling long notes with auto sync I'm often experiencing an interruption of the task I'm doing, or the app itself flicking to another note, UI lag and hanging etc. Again this is on the desktop app but I've experienced this frequently on Android too, both while undertaking normal tasks. It's particularly bad on Android on the initial auto sync on launch, and the UI can jump around between notes, ie away from where you're working. I've also had this happen on the Windows desktop app on launch.
I understand what you're saying but the auto sync is creating a significant performance issue which in itself may lead to a support burden and frankly is detrimental to the app and user experience. I think either these performance issues need to be fixed - likely tricky and not something that can be achieved overnight because they're probably intrinsic to Electron to an extent - or the auto sync needs to be able to disabled for those affected.
I think there are lots of highly advanced settings in Joplin and so I don't think that being able to disable auto sync - as an advanced setting - would be detrimental to support. Moreover it would give power users control over sync and massively mitigate these significant issues I'm talking about.
The fact that it's affecting Android as well suggests it's an issue with the Joplin code itself, but is related to the shape of your data (because I don't have this issue, and what you're reporting has been mentioned a couple of times before, but does not seem to be widespread).
I think the way the synchronisation process in Joplin is written has poor memory management for large notes. I noticed this in previous investigations when reverse engineering the synchronisation code, and it may have been a contributor to why I could not get background sync on Android to work reliably when I looked into that too. I don't think the issue relates to having a large quantity of sync items, because there is pagination regarding how many sync items can be stored in memory at once. Also resource contents are handled properly and are not held in memory, but the full contents of the note body are.
I think usually users only get issues with sync locking up or crashing the app when having notes with unusually large content (such as containing base64 encoded inline images directly in the note body, instead of as a separate resource), but there have also been issues reported with unusually large revisions being created as well (with abnormal contents), which is an issue I'm looking into.
But just to be clear I'm essentially talking about two issues here although they can cross over:
Joplin freezing when trying to handle large notes, particularly in the RTE, together with the autosync.
Auto sync issues particularly on application launch, but sometimes just during sync, on Windows and Android causing the UI to "flit" around and move to different notes. This happens even when dealing with short notes and no large notes exist in a notebook or have recently been opened. I don't think there's anything particularly in my notes or data that could cause this. You can also often see this behaviour on Android when sharing from a different application.
In my experience given these multiple scenarios, auto sync is just really "aggressive" and gets in the way of normal work and application behaviour. An option to switch it off would provide huge mitigation for these issues.
It absolutely is a widespread issue, it happens to me on all the platforms: Windows, Linux, Mac, iPhone and Android. And many others are affected too, I've seen many topics in the past on this forum. And the number of affected users suggests that it's not related to the data shape.
@banan314 Would you mind sharing links to a variety of the topics you have seen? I have only seen 3 or 4 mentions of related issues since being involved with the community for over 2 years. I cannot find any way to reproduce this myself, and its very very hard to fix something which can't be reproduced by a developer