@werdenfelser Would you be able to check in the Joplin UI if the note in question has an note history currently? If it does, can you check whether the oldest revision in the list contains any of the duplications, or if the revision resolves to a title and body which looks correct?
I can't find any such note history in the UI -- at least not with Windows. I'll look later at the UI on Linux.
Do you mean you don't know where to find the note history in the ui, or you have checked the history for the note and there were no entries? If the latter, then the result is as I expected. If you don't know where the history ui is, you have to press the (i) button on the note, then click Previous versions of this note.
The timestamp in the note history item you sent over happened to be approx 90 days before you said the issue fixed itself. So I believe that the very large revision was the only remaining revision for that note, and by chance, that item happened to expire and got deleted, ultimately resolving the issue by itself.
FYI I have created PR Desktop, Mobile, Cli: Fixes #15811: Add safeguard to prevent revision chains being broken by revision cleaning, where old revisions still exist unexpectedly by mrjo118 · Pull Request #15812 · laurent22/joplin · GitHub to address this issue. It won't fix existing revisions which have existing duplications like this, but it should prevent revisions from becoming like that going forward.
Sorry about that, I had never used that before! The note definitely has a history and the oldest revision is from April 4, 2026. In the revisions list it also has a number "(+67435)" (number of changed characters)? But it only shows a blank page or is it still loading and loading? There are for sure lots of entries in the revision history as it's a note I change very extensively, albeit not lately.
Yes, I wanted a long time, but the screen did not show any text from the revision. Or am I misunderstanding what I should see on the revision screen?
Could you send a screenshot of the full dropdown of the history entries for that note? If there are too many entries to fit, just scroll to the bottom of the list and show as many entries as you can.
You mentioned that there was more than one very large item on the server, so it could be that these very large items were tipping Joplin over the edge, but after deleting one of the entries the memory consumption is now low enough to not crash.
Regarding the entry showing blank in the ui, it is either because it is too big for Joplin to handle, or because the computation of the revision text failed (which results in an empty result). I don't particularly care about seeing the contents, just knowing the timestamp and size, which is shown in the dropdown.
So I uploaded the screenshot. The largest file on the WebDav-Server ist about 49MB big, Then there are 2 with about 24MB und 12MB.
Thanks. Well it's clear that the crash has fixed itself due to at least one of the large revisions being deleted by expiring.
Any chance you could send over those remaining 3 large files as well (zipped) for further investigation? No need to check the full contents, just so long as it says "Gerade am Wickel!" anywhere in the title_diff near the top, then it can be assumed it's for the same note.
Okay, I'll upload a ziip file with those 3 largest files from the WebDav folder.
Gerade-am-Wickel-20260705.zip (1.5 MB)
Thanks. I had a look at those files and made some observations:
- The 12mb file is dated 21/04/26 and the title_diff has "start1":32,"start2":32,"length1":8544,"length2":4}]"
- The 24mb file is dated 03/05/26 and the title_diff has "start1":32,"start2":32,"length1":17084,"length2":4}]"
- The 48mb file is dated 09/06/26 and the title_diff has "start1":32,"start2":32,"length1":34007,"length2":4}]"
- None of the parent ids for each of those revisions match an id of any of the other large revisions provided
Overall there seems to be a pattern (content and file size being doubled at certain points), but the results are inconclusive regarding what caused the issue in the first place. My best guess is a single revision had a faulty merge, made by the revision cleaner, and subsequent revisions intermittently duplicate contents depending on whether a merge of previous revisions evaluated successfully. It may be that the diff algorithm used to merge revisions has a certain level of error correction, but when it reaches a point that it can no longer be corrected, then the merge evaluates to an empty string (as I have observed with faulty merges) and at that point an almost full merge is created, which ends up duplicating the contents. What is strange is that the start1 and start2 values are 32 rather than 0 on these revisions though, unlike the largest revision which was previously sent.
I don't think I can meaningfully take this any further, so I just have to hope that my code fix would stop the issue manifesting for clean revision chains.
@werdenfelser To avoid the possibility of developing future crashes from the broken revision chain for that particular note, I would suggest to delete all revision for that note, so the revision chain can start again with a clean slate. To do this, on the revision viewer screen for the note, click the delete history button next to the dropdown.
Okay, that's fine with me, because I can't really imagine needing an older revision in this case. So I just deleted the history. So I guess we'll just hope that the root of the problem has been alleviated and that by deleting the history, I will have no more problems with that note, right?