I attached a pdf of 44mb and when I sync in Android it says something like ‘resource not available for [id].md’ but i synced from another laptop and it worked perfectly. Small files around 3-4mb work nice.
If you use encryption, the limit is 10MB.
If you use OneDrive, the limit is 4MB.
Other than that I’m not aware of any limits, so I hope that somebody else has a better answer. More info might help other to answer the question (what sync target are you using, encryption on/off).
wow, really? that’s sad because I attach a lot of pdfs and documents higher than 10mb :S
are there any plans to update the file size limit? maybe switching to another library?
Just installed Joplin, set up WBDAV sync with my OwnCloud server, and am very excited to have an alternative to Evernote (which I have used for over 10 years, generating thousands of notes). However, the crash on mobile caused by the 10MB limit is a show-stopper for me, since it also apparently prevents my other notes (with attachments under 10MB) from syncing.
Would it be possible as a temporary work-around, to have the mobile app first check the file size, and not attempt to upload when it would cause a crash? Obviously, the long-term solution is to fix the 10MB limit, but if this will take a while, at least preventing the crash would enable me (and others migrating notes with such attachments) to use your well-developed product. Thanks!
Did this limit recently change? I remember having the issue previously, but today am able to open an 18MB attachment on Android that I added on macOS (v1.0.201).
Now it allows any size of resource, but will add a warning in the log if you upload a resource larger than 10MB. There are other mechanisms in place to prevent the app from crashing on certain devices when downloading large attachments (namely it gives up downloading if it made the app crash more than twice).
Ok I think I got confused as we have several different checks for out of memory issues. The one I had in mind is the one to handle decryption crashes, which are hard to prevent, so if it crashes more than twice the data won’t be decrypted again:
And the issues you mentioned above, we don’t currently handle. It’s the fetching lib we uses that crashes for large resources on older devices. I guess the same logic as for decryption should be applied - if it fails more than twice, stop trying.
Exactly. But I had a look at it at some point and couldn't find how to prevent it from doing this unnecessary serialization. Maybe the package has been improved since then and there's a way now.
It’s interesting that the other users who said they had the app crash (supposedly due to a large attachment) were all using dropbox with encryption enabled.