I'm getting errors "Row too big to fit into CursorWindow" while trying to sync my notes (which I maintain in the Joplin Windows app through OneDrive) in the freshly installed Joplin Android app.
After the sync on Android finished with the "row too big..." errors, most of the notes on Android are shown as "encrypted", making it practically impossible to productively use the Android version. Only a small portion of my notes are shown correctly on Android.
This error has been reported multiple times in the forum, without a fix.
I don't know how to work around this error. Some of my notes are quite old, a lot of them were imported from Evernote a while ago.
I read in the previous problem reports that this problem may have to do with the size of the notes: So, inspecting the Joplin folder on OneDrive, it turns out that most of my notes (.md files) are below 1 MB in size. I have only 3 .md files that are larger than 1 MB, one is 1.6 MB, one is 2.3 MB, and one is 4.9 MB.
Since there seems to be no way to sort all notes by size in Joplin on Windows (in order to try to delete the largest ones), I don't know how to circumvent this issue, which blocks me from using Joplin on Android.
I'm currently trying to circumvent this issue by deleting some really large PDF attachments (one about 100 MB, others about 20 MB) that I found in "Tools" > "Note Attachments". Dropped my OneDrive folder after that. Started a resync from Joplin on Windows. That will take a few hours. Will report results tomorrow.
You are right, it did not help. Still getting the errors when trying to sync from Android.
Now trying a different method: I deleted two .md files on OneDrive manually (in the \Graph folder), which are the by far largest ones there - one is 4 MB, the other is 1.6 MB. I don't even know to which notes they belong, since they are encrypted. Then I did a resync on Windows.
Now trying to do a fresh sync from OneDrive, on the newly installed Joplin on Android, which will take a while. It seems to get across the original "Row too big.." errors, so there is some hope.
I'm wondering why .md file sizes of 4 MB or 1.6 MB may cause this issue, since I read in previous reports that the limit is about 50 MB.
Since I deleted those two large .md files on OneDrive, but kept copies: Would it be save to paste them again into \Graph on OneDrive, then resync from Joplin on Windows, just to look up to which notes they belonged, using your filter, and maybe save their content outside of Joplin?
I would then delete them again on OneDrive, to prevent the Android sync errors.
Update: I tried that, but Joplin on Windows does not find those files after resync through the suggested filter on id.
Probably have the files restored alone without corresponding database updates is not sufficient.
Android sync is still running, so far no errors. Keeping fingers crossed...
Update: With the above deletion of the two largest .md files on OneNote, the Android app synced successfully from OneNote. Unfortunately, since those files were encrypted, I don't know which notes I deleted through that workaround. But that's a small problem compared with the issue that the Android app did not work at all before.
Maybe try to set their timestamp to something recent? That way they should be picked up by sync
Otherwise, since you know the ID, you should be able to find them in the desktop app (although if you've deleted them first, the deletion may have been synced)
Changing the timestamp in the .md files was an excellent tip.That brought those notes to the top of the list in Joplin for Windows, after a re-sync, allowing me to inspect them. Thanks for your help.
Since I can't introspect my sync target directly (Joplin Cloud) I exported to both markdown + frontmatter and RAW - Joplin export directory
I then sorted by size.
In the MD directory, the largest .md or .html files were 3.2MB (md), 1.5MB (html) and 246KB (md).
In the RAW directory though the largest .md files were 3.2MB, 2.5MB, 1.5MB, and 246KB.
Why the discrepancy? OCR rendering of a PDF. Here's the top set of lines from the 2.5MB file ...
[redacted-filename].pdf
id: 6fdb241ef3b94e928b5638e7bdab9570
mime: application/pdf
filename:
created_time: 2024-11-06T14:33:55.538Z
updated_time: 2024-11-06T16:32:31.035Z
user_created_time: 2024-11-06T14:33:55.538Z
user_updated_time: 2024-11-06T16:32:31.035Z
file_extension: pdf
encryption_cipher_text:
encryption_applied: 0
encryption_blob_encrypted: 0
size: 7108096
is_shared: 0
share_id:
master_key_id:
user_data:
blob_updated_time: 1730903635538
ocr_text: [and then all the OCR text]
Could perhaps OCR text be a source of unexpected behavior? None of these markdown files are spectacularly large, ultimately, but I can see internally referenced markdown blobs exploding in size if PDFs are being saved as such. (And of course, webclippings can get big.) Is this markdown being stored in the database as a data blob? Can the database handle an arbitrarily large markdown file? Is the DB on a phone more fragile than the DB on the desktop? (I suspect that is probably true.) Is that OCR being synced?
I am in the process of (a) turning off the OCR stuff and (b) temporarily deleting these resources. But then I need to wait (I think?) a day for the revision history to clear out and then I will try again to see if that resolves the issue.