Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Desktop: Joplin Freezing During Syncing and Decrypting On Linux Kernel 5.5+ #2518

Open
dimyself opened this issue Feb 18, 2020 · 279 comments
Open

Desktop: Joplin Freezing During Syncing and Decrypting On Linux Kernel 5.5+ #2518

dimyself opened this issue Feb 18, 2020 · 279 comments
Labels
bug

Comments

@dimyself
Copy link

@dimyself dimyself commented Feb 18, 2020

I just started using Joplin recently, and since first using it's been locking up/freezing/unresponsive. It seems to be getting stuck in a syncing loop. It will try to sync, and something is not allowing sync to stop/cancel. Even if I manually click on cancel when it's syncing, it just says "cancelling" and stays spinning but won't stop.

At this point, when I click on any notebooks/notes, nothing happens. The notes don't load, the screen doesn't refresh to the note I click on. The only thing that works at this point is I can click and open menus/settings.

I then have to kill the app and relaunch it.

Is anyone else having issues on Linux with Joplin being buggy and freezing?? I'd really like to resolve this so I can use Joplin! I'm not sure if this is something on my system, or if others on Linux are having this issue?? It's pretty much unusable for me at this point! The bug also happens even if I don't click on Sync. I will come back to Joplin to make a new note, and it will be in this stuck sync state on it's own without me doing anything.

It is a major bug on my system. It happens frequently and I can reproduce it easily.

Environment

Joplin version: Joplin 1.0.179 (prod, linux); Sync Version: 1; Revision: b4e325d (master)
Platform: Arch Linux
OS specifcs:

Steps To Reproduce

  1. I can launch Joplin, and to reproduce, I simply click on Sync in the lower left corner a few times, and it gets stuck in the sync loop error/bug.
  2. It happens every time. I have to kill/relaunch at this point.

Describe what you expected to happen:

Logfile

Console shows normal activity before the problem when clicking on a different note: webview_domReady Connect {props: {…}, context: {…}, refs: {…}, updater: {…}, version:

Then when I initiate the bug by clicking on sync several times, nothing shows up in console whatsoever. It only has the last reported event from before the bug.

Here is my updated log.txt file: https://pastebin.com/CDdhuL25

Whenever I initially launch joplin in debug, I get these messages in the console (in case they’re important) console.log file : https://pastebin.com/zzjdguTX

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Feb 18, 2020

This issue seemed to crop up immediately after upgrading to Linux Kernel 5.5 in Artix Linux (an Arch offshoot). Since you, me and another person are all having similar issues on Arch or Arch based systems, I've decided to do an experiment and see if downgrading to the Linux LTS kernel (5.4.19) might solve the issue since I was also noticing some network issues along with other things since upgrading.

@dimyself

This comment has been minimized.

Copy link
Author

@dimyself dimyself commented Feb 18, 2020

Here's a video showing the problem if it helps!

https://youtu.be/sdpI4kBIaUY

@dimyself

This comment has been minimized.

Copy link
Author

@dimyself dimyself commented Feb 18, 2020

This issue seemed to crop up immediately after upgrading to Linux Kernel 5.5 in Artix Linux (an Arch offshoot). Since you, me and another person are all having similar issues on Arch or Arch based systems, I've decided to do an experiment and see if downgrading to the Linux LTS kernel (5.4.19) might solve the issue since I was also noticing some network issues along with other things since upgrading.

@bedwardly-down does the video look similar to your issue?

Did the LTS kernel change anything?

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Feb 18, 2020

@dimyself the video looks exactly like what I'm experiencing (minus that console log output). I have debugging turned on and have a Kitty Terminal running with tail -f $XDG_CONFIG_HOME/joplin-desktop/log.txt running on it just to the left of the bottom part of the console log. Other than that, definitely the same freezing issue shown.

2020-02-08-193241_1920x1080_scrot

To know if it's a kernel issue, I'd need to use Joplin extensively on it for a few days since the issue wasn't frequent enough for me to really test it out but enough to be a bit annoying. Ha

Also, my screenshot was from a failed attempt at getting a task done here that involved loading icons in the sidebar for all Notebooks. I got very close to finishing it, but couldn't get it to production level without spending a massive amount more of resources that were wearing thin. Ha

@Soltares

This comment has been minimized.

Copy link

@Soltares Soltares commented Feb 18, 2020

I thought it was just me at first experiencing this issue, so I was hesitant to file a bug however the video and description match what I see as well on Arch 5.5.2-arch1-1 / Joplin 1.0.179-1. I am using a filesystem sync target on a remote system via SMB. I switched to NFSv4, but there was no noticeable impact.

My Windows 10 instance of Joplin is working as expected on the same filesystem target, yet it's lagging behind a bit at version 1.0.175. I've been nervous to upgrade as I use it frequently during work. (Thanks by the way for such a useful tool!!)

Note: 479/479
Folder: 19/19
Resource: 158/158
Tag: 0/0
NoteTag: 0/0
MasterKey: 0/0
Revision: 366/366
Total: 1022/1022

Here is a short clip of what I see. Not much different from the youtube video other than I generally see the issue during my second sync and the Synchronisation Status is blank during the sync.

Joplin-Sync-Stuck-2020-02-18-min

@hpfmn

This comment has been minimized.

Copy link

@hpfmn hpfmn commented Feb 18, 2020

I have the same issue also with the newer 1.0.184 version of joplin. I'm not sure if it only happens during sync though. But seems like it is more likely during sync.

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Feb 18, 2020

I know that 1.0.184 is definitely not recommended for daily use and has quite a few (albeit small) areas where it can and has broken for me, but are you also on an Arch-based distro, @hpfmn ? My main view is that we all have that one factor in common which means that we all share the same kernel which may not load the same network drivers but more than likely would share the same protocols and whatnot. Ha

@hpfmn

This comment has been minimized.

Copy link

@hpfmn hpfmn commented Feb 18, 2020

@bedwardly-down yes I'm also running arch. Is there any information which versions are considered stable and which are considered unstable? I'm 1.0.179 has a text on the github release - is that what is saying that it is stable? I honestly don't think it is related network drivers ;)

@hpfmn

This comment has been minimized.

Copy link

@hpfmn hpfmn commented Feb 18, 2020

What is maybe different for me - if I wait a long time (like several minutes) it does recover and starts to be usable again. But some of the changes I made to the current document are discarded.

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Feb 18, 2020

I don't think it's network drivers either. I was referring to the fact that none of us would be running the same network drivers but all would have similar if not the same Network Protocol implementations built into the kernel. When i say Network protocols, i mean how the kernel handles things like https and interfaces with each of the various network drivers to allow them to function. If there was a major change there, it could affect how Joplin handles syncing and could be an upstream bug for whichever module is used to handle it. I wish some Ubuntu / Debian and Fedora users would pipe in so that the issue can be classified as a Linux wide one and not Arch specific. Ha

Also, the stable ones are linked in the forums and have a Green Release tag on github. All other releases are draft ones not meant to be used as a daily driver but instead a bleeding edge test (minus the Red Pre-release ones; those are for testing but are meant to be a stop gap between main stable releases)

@matcharles

This comment has been minimized.

Copy link

@matcharles matcharles commented Feb 18, 2020

Just wanted to let you know I am experiencing the same thing (#2507). I thought it had something to do with syncthing at first but I can see from reading the thread that you're all using different sync protocols. This is making it really hard to work for a long time because you never know what the program will discard. Reliability is zero at the moment.

I disabled syncthing on both computers and the problem persists.

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Feb 18, 2020

Thanks @matcharles. I use Joplin for my budgetting and daily journaling and can definitely say that this issue has caused some similar headaches for me. Luckily, it's not been fatal for my uses but i can definitely see it being terrible.

I'm definitely beginning to think this is an arch / kernel specific bug. Most distros won't be running 5.5 yet unless the user explicitly installs it themselves or it offers some drastically needed features that something like Ubuntu would jump right on board with. @laurent22 , what are the modules you use for syncing in Joplin? I'd like to see if my hunch or something similar is correct.

@laurent22

This comment has been minimized.

Copy link
Owner

@laurent22 laurent22 commented Feb 18, 2020

It's mostly node-fetch and the sqlite3 that would be involved for syncing, but it could also be due to some complicated interaction between Electron and those modules.

If sync status is blank in particular, it could mean that the sqlite database is locked or the app can't read from it for some reason. While it's in this state, are you able to open database.sqlite (with an sqlite browser) in your profile directory?

@Soltares

This comment has been minimized.

Copy link

@Soltares Soltares commented Feb 18, 2020

The joplin-desktop database.sqlite appears readable while sync is spinning and sync status is blank:

[chris@spire ~]$ sqlite3 ~/.config/joplin-desktop/database.sqlite
SQLite version 3.31.1 2020-01-27 19:55:54
Enter ".help" for usage hints.
sqlite> .tables
alarms                 notes                  resources_to_download
deleted_items          notes_fts              revisions            
folders                notes_fts_docsize      settings             
item_changes           notes_fts_segdir       sync_items           
key_values             notes_fts_segments     table_fields         
master_keys            notes_fts_stat         tags                 
migrations             notes_normalized       tags_with_note_count 
note_resources         resource_local_states  version              
note_tags              resources            
sqlite> select count(*) from notes;
479
@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Feb 18, 2020

Looks like node-fetch has quite a few open http protocol issues that may be similar to what's happening here: https://github.com/node-fetch/node-fetch/issues

I'm out working right now but my brief 5.4 kernel tests weren't showing any issues so far, but they could still pop up later. If anyone else wants to test that theory too, all you'll need to do is install the linux-lts and linux-lts-headers packages and then reconfigure whatever boot loader you're using to boot it and you should be good to go

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Feb 18, 2020

My previous issue could be related too #2490

@Soltares

This comment has been minimized.

Copy link

@Soltares Soltares commented Feb 18, 2020

I'm technically on the clock too, but use Joplin to work effectively so.. :)
I took the plunge and switched kernels from 5.5.2-arch1-1 to 5.4.20-1-lts. I am immediately seeing an improvement. What only took 2-3 sync attempts to replicate the issue is now going on at least a dozen syncs with no sign of hanging! Looks like you're definitely on to something with the kernel versions.

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Feb 18, 2020

@Soltares i use Joplin mobile during my work since my work is constantly on the move, so i can't test in the field. Thanks for trying it out too and glad it's working for you too. ☺️

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Feb 18, 2020

During my test, I synced around 20 times with several test files i created, synced and deleted and had no signs of it either.

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Feb 18, 2020

@Soltares @laurent22 would either of you know how to test this better to try to get a bug report sent upstream to node-fetch since that's looking like it may be where the issue lies since this is looking less like a Joplin issue?

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Feb 18, 2020

I also found a post on Reddit where Firefox is exhibiting similar freezing issues on Arch with 5.5.4: https://reddit.com/r/archlinux/comments/f5smcx/intermittent_hanging_with_554_kernel_x1c6_intel/

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Feb 19, 2020

@dimyself, since you're the one that opened this bug report, I just wanted to inform you that Joplin is still syncing perfectly with no issues whatsoever on the LTS kernel after me leaving my laptop on all day long letting it auto sync while I was out and about. It looks like this is most likely the current solution until the devs upstream get the issue resolved.

@yewwayne

This comment has been minimized.

Copy link

@yewwayne yewwayne commented Feb 19, 2020

Having the same issue but I doubt it's network related as I'm only syncing to a local directory and letting Syncthing handle cross-device sync. The issue persists after disabling syncthing.

I'm also thinking it's not specific to the sync function of Joplin. Here's what just happened to me:

  1. Create a new note, then modify it and sync in a cycle with 5-10 second delay between each round.
  2. After 20 rounds or so with some occasional app switching, Joplin UI became unresponsive as in the youtube video, except no sync process was ongoing from what I could tell.
  3. After 2 more minutes the UI suddenly "played back" my mouse clicks in quick succession and becomes responsive again.
  4. Clicked sync, sync process seemed stuck. After a minute the sync finishes. For some reason it reports "updated 4 remote items" even though i've only been modifying one note.
  5. Joplin seems to work fine again.

log.txt of the above: https://pastebin.com/ma7wK4Sr. I noticed 2 instances where SearchEngine: Updated FTS table took over a minute:

2020-02-19 16:28:13: "SearchEngine: Updated FTS table in 83816ms. Inserted: 9. Deleted: 0"
2020-02-19 16:30:22: "SearchEngine: Updated FTS table in 63586ms. Inserted: 1. Deleted: 0"

Kernel: 5.5.4-arch1-1
Joplin version: 1.0.179 (prod, linux); Sync Version: 1; Revision: 66356d8

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Feb 19, 2020

@yewwayne thanks for bringing that up. You're not the only one that said the issue showed up with Filesystem. I think someone else brought that up above. Joplin doesn't technically save locally, so it treats Filesystem sync as syncing to any cloud platform, I'm suspecting the url is just replaced by a local directory string and is just getting checked if it exists or not.

If that's the case, the bug is still a network related bug since the module involved with syncing (or in this case a hacky way of saving but not saving locally) would still be acting up. Does that make sense?

@hpfmn

This comment has been minimized.

Copy link

@hpfmn hpfmn commented Feb 20, 2020

I could catch it today in development tools in the debugger I hit the pause button and seems to be hanging at this code:

if (!ItemChange.saveCalls_.length) {

Alas I coudln't get the backtrace... because the whole electron thing froze...

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Feb 20, 2020

Hmmm. Because that's in ReactNativeClient/lib, if that was the source of the bug and not just a symptom, changing the kernel version wouldn't solve the problem. Everything in that folder is used by all platforms which would mean the bug would occur everywhere as frequently.

Still a nice find, though. 😺

@hpfmn

This comment has been minimized.

Copy link

@hpfmn hpfmn commented Feb 20, 2020

I don't know if it might be related in any way to this? electron/electron#21415

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Feb 20, 2020

I think the bug you linked could be related to some other issues here but probably not this specific one. The person that opened that bug report up was on 5.4 and Slackware, so not the same as the rest of us, but still could lead to more info.

I'm still thinking this is an upstream bug related to node-fetch and not a Joplin one, so if more people could test out the 5.4 kernel suggestion I made, that would definitely help make sure that's a legitimate fix. Thanks

@tvannoy

This comment has been minimized.

Copy link

@tvannoy tvannoy commented Mar 22, 2020

5.5.10-arch1-1 still has the same issue. Opening the joplin web clipper in Firefox does indeed fix the issue.

I am using file system sync with syncthing handling the actual networked synchronization, like @yewwayne @matcharles

I built a kernel with this patch applied, but the problem still persists. I think the hangup seems to happen less often with the patch applied, but it's hard to tell. With the patch applied, synchronizing seems to work fine when the note has been changed, but if I try to synchronize about 3-4 times without making changes, the synchronization hangs.

If somebody else on Arch wants to try the kernel I built, I can provide the package archives. This is the first kernel I've patched, so there is a chance that I messed something up. makepkg reported applying the patch, though, and the source file shows the changes, so I'm pretty sure the patch got compiled in.

I guess for now I'll just settle on using the LTS kernel.

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Mar 22, 2020

Don’t share custom kernels, @tvannoy . It’s not a good thing for anyone because every system is different and won’t need the same modules. This also isn’t Arch Specific but kernel specific. I need to test that patch myself, though, just have been mostly busy with the virus stuff, my roommates, work and helping out with GSoC. Ha

Also, when you say Package Archives, are you referring to the PkgBuild or what?

@tvannoy

This comment has been minimized.

Copy link

@tvannoy tvannoy commented Mar 22, 2020

@bedwardly-down good point; I was referring to the tar.xz files, but the PKGBUILD would be more useful since that isn't so system-specific. But of course the PKGBUILD isn't useful for people on other distros.

It'd be interesting to try that kernel patch along with Electron 8.

@Narga

This comment has been minimized.

Copy link

@Narga Narga commented Mar 23, 2020

I experienced with this problem too until I found this issue on Github at here. I'm using Arch Linux with XFCE4 too, my solution is copy my current edit content then quit and re-open Joplin again. Since several recently version, it's happening frequently, I tried to debug but not found any valuable information. May I guess the GUI is main problem because I tried to disconnect from sync, just use Jopline as standalone software, but this problem still happened.
I know my comment hasn't much information but I want to confirm this problem on Arch Linux.
Note: Joplin on Windows 10 is working flawlessly.

@nshtg

This comment has been minimized.

Copy link

@nshtg nshtg commented Mar 23, 2020

@Narga
You can use linux-lts as kernel (5.4.x is fairly recent too). Fixes the problem for the moment.

@m-angelov

This comment has been minimized.

Copy link

@m-angelov m-angelov commented Mar 23, 2020

The enable-disable web clipper trick still works for me.

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Mar 23, 2020

The enable-disable web clipper trick still works for me.

Does that work only with firefox or chrome based browsers too?

@m-angelov

This comment has been minimized.

Copy link

@m-angelov m-angelov commented Mar 23, 2020

@bedwardly-down that's the thing - I don't use any browser extension. I just enable-disable the service in Joplin. See this video and it should be clear what I'm doing: https://my.pcloud.com/publink/show?code=XZPh8MkZyOJogIQdym0fjtsTHsQAsLI5wK6k

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Mar 24, 2020

I see. That's pretty interesting @m-angelov . I wonder what would cause that to be a viable fix and if that's the only thing that can be done to fix it. Hmmm

I can also verify that that works. Thanks for sharing. :D

@wisp3rwind

This comment has been minimized.

Copy link

@wisp3rwind wisp3rwind commented Mar 24, 2020

@bedwardly-down that's the thing - I don't use any browser extension. I just enable-disable the service in Joplin. See this video and it should be clear what I'm doing: https://my.pcloud.com/publink/show?code=XZPh8MkZyOJogIQdym0fjtsTHsQAsLI5wK6k

Same here.

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Mar 24, 2020

What I'm noticing from just a visual standpoint: Web-Clipper Enable / Disable seems to reset Electron's rendering. Have you noticed that the UI and everything flashes before getting back to normal function?

@lnicola

This comment has been minimized.

Copy link

@lnicola lnicola commented Mar 24, 2020

If it reloads the UI, it might explain why it fixes the issue.

@fireglow

This comment has been minimized.

Copy link

@fireglow fireglow commented Mar 24, 2020

So is this a bug in electron, then?

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Mar 24, 2020

I'm not looking at it from the code but yes, @lnicola

It's most definitely Electron, @fireglow. If the patch listed earlier that is supposed to be getting pushed to the Kernel isn't working like suggested above, this could be the only other fix for the time being.

@lnicola

This comment has been minimized.

Copy link

@lnicola lnicola commented Mar 24, 2020

As far as I can tell, this was caused by some kernel changes that might have been buggy. They're pretty low-level, but they might manifest in lost wakeups in applications, so we're talking about an interaction between the kernel, Node and Electron.

There is an kernel patch that might help. It's not merged yet (maybe it slipped between the cracks?), and someone reported it didn't fix the issue.

@fireglow

This comment has been minimized.

Copy link

@fireglow fireglow commented Mar 24, 2020

@bedwardly-down @lnicola okay, thank you for summarizing

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Mar 24, 2020

Like I've said before, it may be a good while if at all before this patch gets merged and it might not even fix the issue. I also know that with everything going on with GSoC and the dev team's priorities for Joplin, a Linux bug like this is not a priority for them at all. Since it only affects us and is an upstream bug, most likely if someone were to make a Reset UI option in a PR, it probably won't get merged anytime soon.

For the next three or so months, most fixes are going to be critical ones, new features that the community have been asking for, and student project stuff.

@fabianski7

This comment has been minimized.

Copy link
Contributor

@fabianski7 fabianski7 commented Apr 1, 2020

I've been using joplin for a few hours with the latest kernel version available for archlinux (5.5.13-arch2-1) and so far this problem hasn't happened.

Before, I was using the LTS version.

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Apr 1, 2020

It’s not happening on all systems but does happen on quite a few. I haven’t tested it on 5.5.13 yet.

Here’s the changelog: https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.5.13

It’s one of the smallest kernel ones I’ve seen but i wonder if the busy work includes epoll stuff since that is a part of the sync_state() stuff, me thinks.

@m-angelov

This comment has been minimized.

Copy link

@m-angelov m-angelov commented Apr 1, 2020

Today I got 5.5.13 and unfortunately the bug is still persisting on my system.

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Apr 1, 2020

Also, depending on how things go, 5.6 just officially released, which means 5.5 may soon become the LTS release.

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Apr 2, 2020

@m-angelov @lnicola what do you guys think about me looking into getting a non-Electron-based Linux build project going? If 5.5 were to become the LTS and / or mainline kernel and these issues just keep popping up, attempting to remove Electron altogether while making sure all of the other features are still functional might be the best option.

@lnicola

This comment has been minimized.

Copy link

@lnicola lnicola commented Apr 2, 2020

@bedwardly-down I'm not sure what the alternative is. Does Joplin have a web version that can run in a browser? One solution for a port would be to spawn a server and display the application in a web view, kind of like an "Electron lite" approach. But I don't think it's really feasible, and at that point it might not even be Joplin anymore.

@roman-r-m

This comment has been minimized.

Copy link

@roman-r-m roman-r-m commented Apr 2, 2020

@lnicola there's this unofficial project: https://github.com/foxmask/joplin-web
I set it up but found too slow to use and I do not even have too many notes. But to be fair it was running on raspberry pi so that might have contributed too.

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Apr 2, 2020

@bedwardly-down I'm not sure what the alternative is. Does Joplin have a web version that can run in a browser? One solution for a port would be to spawn a server and display the application in a web view, kind of like an "Electron lite" approach. But I don't think it's really feasible, and at that point it might not even be Joplin anymore.

Not the web version or “electron lite.” There are other languages that compile native binaries for all platforms that would require porting large chunks of Joplin’s code base out of JavaScript and ReactJs but can also take the parts that aren’t fully portable in their current state in a plugin sort of way.

@userid

This comment has been minimized.

Copy link

@userid userid commented Apr 2, 2020

I met the same scene when I doing re-encrypt the whole notebooks (15621 notes, 55611 items).
even after I changed the webdav server to a nginx running on a LAN linux, the sync is still slow, it stop after syned 100 items and sleep for several minutes , meanwhile there is no access log on nginx, then it go on syncing.
I was running Arch Linux with kernel=5.5.13.arch2-1.

After seem this issue, I switch to linux-lts=5.4.28-2, it works much faster.

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Apr 2, 2020

The Haxe language is an alternative that was created around the same time as many other web development languages when Adobe dropped support for Actionscript with Flash. One of the core benefits to the language is that it's compilable to C++ and other languages depending on what libraries are used and how they are written. It defaults to compiling to Javascript and most libraries are fully compatible.

@tvannoy

This comment has been minimized.

Copy link

@tvannoy tvannoy commented Apr 2, 2020

@bedwardly-down I'd support creating a native Linux build if that's what this ends up coming down to. It seems like the issue is likely an upstream issue, though; it's hard to say if finding and fixing things upstream would take more time than porting Joplin to something that isn't Electron-based.

@bedwardly-down

This comment has been minimized.

Copy link
Contributor

@bedwardly-down bedwardly-down commented Apr 2, 2020

@tvannoy very true. The biggest issue here would be how big the codebase is for Joplin vs how many people could put time and energy into porting. I have this fear that if Electron were to drop Linux support, Joplin would follow suit. The latest Apple releases are making Joplin support on Macs and iOS devices even more difficult, so I would not be surprised on anything.

In other news, I was just made an official member of the Joplin Team: https://discourse.joplinapp.org/g/Team

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.