Maximum file size? (or: only partial file contents shown)

[alphapapa]

I have a 3.1 MB Org file that works fine in Emacs, but Orgzly only shows headings down to about 46% into the file (the final heading that Orgzly shows indicates 46% into the file in Emacs).

Is there a maximum file size in Orgzly?

What would happen if I edited and saved this file in Orgzly? Would it truncate the file? Is it safe to view and sync this file in Orgzly?

Thanks.

[nevenz]

How many total notes is that?

Do you have any large notes in there too (large content size from heading to the next one)?

Do you display notes' content in the list too, or just headings?

[alphapapa]

There are 151 top-level headings and 927 total headings in the file.

Yes, the notes are fairly large as they're captures of web page articles using code from eww-readable.

Do you display notes' content in the list too, or just headings?

I'm not sure exactly what you're asking, but the first thing I did after opening the file in Orgzly was to collapse all headings so only the top-level headings were shown. Then I scrolled to the bottom and noticed that the last heading displayed was not the last heading in the file.

Thanks.

[nevenz]

Yes, the notes are fairly large as they're captures of web page articles using code from eww-readable.

There is a limit of 1.5M characters per note. Could you be hitting it? Though things should be breaking on notebook import in that case, perhaps they're not for some reason.

I'm not sure exactly what you're asking, but the first thing I did after opening the file in Orgzly was to collapse all headings so only the top-level headings were shown. Then I scrolled to the bottom and noticed that the last heading displayed was not the last heading in the file.

OK cool, I'll try to reproduce it like that.

I was asking if you had "Display content" option enabled or disabled. It controls the display of content in the notes list.

[alphapapa]

There is a limit of 1.5M characters per note. Could you be hitting it?

I don't think so. I just ran this code from the first heading in the file:

(save-excursion
    (message "%s" (cl-loop while (org-at-heading-p)
                           collect (length (org-get-entry)) into res
                           do (outline-next-heading)
                           finally return (sort res '>))))

And the highest number is 617094.

I was asking if you had "Display content" option enabled or disabled. It controls the display of content in the notes list.

Ah, yes, it is enabled.

Thanks.

[nevenz]

I was asking if you had "Display content" option enabled or disabled. It controls the display of content in the notes list.

Ah, yes, it is enabled.

Actually it doesn't matter, if you are collapsing all at the beginning content shouldn't even be displayed, just titles. Which is what makes this even weirder.

Not sure how to debug it. I assume you can't send that file. Maybe if you replace characters in titles and content with random ones, or something like that. It would be interesting to see if it continues to happen then.

[alphapapa]

Not sure how to debug it. I assume you can't send that file. Maybe if you replace characters in titles and content with random ones, or something like that. It would be interesting to see if it continues to happen then.

Well, that idea sent me off on a rabbit trail, but I ended up with some Emacs code that does that. :) I'll upload the file with the replaced words. The words are replaced with words of the same length, so the filesize is the same (well, somehow it got about 200 bytes larger, but I think that's close enough).

Oh, and GitHub refuses filenames that end in .org, so... :roll_eyes:

testarticles.txt

Thanks!

In case anyone finds the code useful: https://gist.github.com/alphapapa/2d141b60ccbe92f1b90000debde2ddd2

[nevenz]

And you do see the same thing? What's the last heading you see from Orgzly?

Thanks a lot for taking the time to debug this BTW.

[alphapapa]

Oh, sorry, I thought you meant that you would test the obfuscated version on your end. I'll test it as well. :)

[nevenz]

Oh, sorry, I thought you meant that you would test the obfuscated version on your end.

I did, but can't reproduce the issue. I see Nub Puebla Glen as a last heading.

[alphapapa]

Thanks, I will report back.

[felixwiemuth]

I have an org file with ~29k lines and ~2m characters which I use on a daily basis and it basically works fine, i.e., all content is shown, it is efficient to use (except that it takes around 30s to synchronize on a Pixel 4a).

However, I regularly notice some strange behaviours, which I briefly want to note here, as they could be related. They could also be independent bugs, in which case I could try to investigate them more closely and create separate reports.

1. (1.8.5, maybe before) The app sometimes (recently more, maybe because of growing file size) crashes during or after synchronizing.
   • E.g. the note is already shown but stuck (can't click anything) and a few seconds later the app crashes.
   • The file synchronizes while open, one clicks on the "fold all" button, the app crashes.
2. (1.8.4 or 1.8.5 or both) Rarely I noticed a random line (a heading) to vanish from the file, also on the synchronized local storage. I noticed this by looking at the diff after a sync conflict on a different device (conflict from syncthing, not orgzly, so it should not be relevant that there was a conflict). I am quite sure it came from the phone's version of the file.
3. (1.8.4 and 1.8.5) Sometimes, when opening or browsing the note, in the top bar an error is shown: "Couldn't read row 1051..." (I think there is not enough space to show the whole message). Here the file had only 14k lines, so probably also under 1.5m characters. I did not notice any practical problem related to this error message. After opening the file again, it doesn't show the error anymore. Looking at item 2 though, I wonder whether it could be that these are the situations where lines vanish from the file.
4. (1.8.4) Some headings are displayed slightly vertically shifted (maybe by half a line height) in relation to the bullet on the left. After some folding and unfolding, it displays normally again. I wasn't able to identify under which circumstances this happens.