2024-07-07 - Android - four elements are not decrypted

Coffee · 2024-07-07T17:46:10.393Z

Operating system

Android

Joplin version

3.0.7

Desktop version info

Joplin 3.0.12 (prod, win32)
Joplin 3.0.13 (prod, win32)

Sync target

Joplin Cloud

What issue do you have?

Forked from

2024-04-29 - Problems synchronising with the Android app and the Joplin Cloud Support

My 2024-07-07 - 19:40 pm fork of this is: t.b.d.

Today I picked out a second problem case and examined it more deeply with the help of the Joplin debug tool plugin 0.2.0, both on Android and on Windows: The message "Some elements cannot be decrypted" on my Android and the four IDs that are mentioned there.

2024-07-07 - störende Meldung - IDs1080×2099 150 KB

Using the Android Joplin Debug Tool 0.2.0, I was able to determine the three notes to which these four graphic elements belong. I was unable to find these elements with the Windows Joplin Debug Tool 0.2.0 – I suspect that they no longer exist under Windows and in the Joplin cloud.
I had somehow repaired the three notes recently and was able to remove them from my conflicts at that time. Unfortunately, the same notes have broken again and reappeared in the conflicts.

I will now repair these three notes again or recreate them from the information that can be found:
First, I create a completely new note in the same folder as the defective note and use the same name plus the name extension - new from saved data.

Then I copy the MarkUp content of the defective note manually into this new note in edit mode and replace the MarkUp text of the defective graphic with the MarkUp text of the still functioning note from an earlier version.

I hope that this problem will no longer occur. The reason for my hope is that I followed the advice to disable the OCR function. I even suspect that the current version of the OCR function not only generates a lot of load and thus causes conflicts. I suspect that the current version of the OCR function can also generate errors.

The reason for this suspicion is the strange markup text that I found in the faulty note.

In the good, restored note, this markup text reads

![32ddce2402b93faafeb7e27624585c09.png](:/582e16f384034024bc6979f5a5e5ccf7)

In the damaged note, this markup text reads

![](data:image/svg+xml;utf8,%0A%09%09<svg%20width="1700"%20height="1536"%20xmlns="[http://www.w3.org/2000/svg"> <path d="M1280 1344c0-35-29-64-64-64s-64 29-64 64 29 64 64 64 64-29 64-64zm256 0c0-35-29-64-64-64s-64 29-64 64 29 64 64 64 64-29 64-64zm128-224v320c0 53-43 96-96 96H96c-53 0-96-43-96-96v-320c0-53 43-96 96-96h465l135 136c37 36 85 56 136 56s99-20 136-56l136-136h464c53 0 96 43 96 96zm-325-569c10 24 5 52-14 70l-448 448c-12 13-29 19-45 19s-33-6-45-19L339 621c-19-18-24-46-14-70 10-23 33-39 59-39h256V64c0-35 29-64 64-64h256c35 0 64 29 64 64v448h256c26 0 49 16 59 39z](http://www.w3.org/2000/svg%22%3E%0A%09%09%20%20%20%20%3Cpath%20d=%22M1280%201344c0-35-29-64-64-64s-64%2029-64%2064%2029%2064%2064%2064%2064-29%2064-64zm256%200c0-35-29-64-64-64s-64%2029-64%2064%2029%2064%2064%2064%2064-29%2064-64zm128-224v320c0%2053-43%2096-96%2096H96c-53%200-96-43-96-96v-320c0-53%2043-96%2096-96h465l135%20136c37%2036%2085%2056%20136%2056s99-20%20136-56l136-136h464c53%200%2096%2043%2096%2096zm-325-569c10%2024%205%2052-14%2070l-448%20448c-12%2013-29%2019-45%2019s-33-6-45-19L339%20621c-19-18-24-46-14-70%2010-23%2033-39%2059-39h256V64c0-35%2029-64%2064-64h256c35%200%2064%2029%2064%2064v448h256c26%200%2049%2016%2059%2039z)"/>%0A%09%09</svg>)

personalizedrefriger · 2024-07-08T03:47:37.516Z

Coffee:

![](data:image/svg+xml;utf8,%0A%09%09<svg%20width="1700"%20height="1536"%20xmlns="[http://www.w3.org/2000/svg"> <path d="M1280 1344c0-35-29-64-64-64s-64 29-64 64 29 64 64 64 64-29 64-64zm256 0c0-35-29-64-64-64s-64 29-64 64 29 64 64 64 64-29 64-64zm128-224v320c0 53-43 96-96 96H96c-53 0-96-43-96-96v-320c0-53 43-96 96-96h465l135 136c37 36 85 56 136 56s99-20 136-56l136-136h464c53 0 96 43 96 96zm-325-569c10 24 5 52-14 70l-448 448c-12 13-29 19-45 19s-33-6-45-19L339 621c-19-18-24-46-14-70 10-23 33-39 59-39h256V64c0-35 29-64 64-64h256c35 0 64 29 64 64v448h256c26 0 49 16 59 39z](http://www.w3.org/2000/svg%22%3E%0A%09%09%20%20%20%20%3Cpath%20d=%22M1280%201344c0-35-29-64-64-64s-64%2029-64%2064%2029%2064%2064%2064%2064-29%2064-64zm256%200c0-35-29-64-64-64s-64%2029-64%2064%2029%2064%2064%2064%2064-29%2064-64zm128-224v320c0%2053-43%2096-96%2096H96c-53%200-96-43-96-96v-320c0-53%2043-96%2096-96h465l135%20136c37%2036%2085%2056%20136%2056s99-20%20136-56l136-136h464c53%200%2096%2043%2096%2096zm-325-569c10%2024%205%2052-14%2070l-448%20448c-12%2013-29%2019-45%2019s-33-6-45-19L339%20621c-19-18-24-46-14-70%2010-23%2033-39%2059-39h256V64c0-35%2029-64%2064-64h256c35%200%2064%2029%2064%2064v448h256c26%200%2049%2016%2059%2039z)"/>%0A%09%09</svg>)

This, after removing some invalid/duplicate SVG syntax, renders to:

download icon1700×1536 69.7 KB

This makes me suspect a problem with the Rich Text Editor save logic — it converts notes from Markdown to HTML, then back to Markdown when saving.

Things for me (or someone else looking into this) to investigate:

How does the Rich Text editor handle the case where attachments are not downloaded? Could this be the cause of the issue?
- At present, the Rich Text Editor should prevent editing notes where not all note attachments are downloaded. However, it's possible that there is a bug in this logic. Possible fix: Allow editing notes where attachments aren't downloaded; restore the original Markdown for these images when saving.
Could the changing resource IDs also be caused by the Rich Text Editor?
- One possibility is that 1) somewhere, resource IDs are being replaced in notes and 2) when the note is edited in the Rich Text Editor, the "downloading" icon is saved instead of the resource.

Coffee · 2024-07-08T06:33:15.167Z

personalizedrefriger:

This makes me suspect a problem with the Rich Text Editor save logic

ok ...

Coffee · 2024-07-08T08:10:41.335Z

Coffee:

I hope that this problem will no longer occur. The reason for my hope is that I followed the advice to disable the OCR function.

@personalizedrefriger
This hope has already been disappointed today.
Two copies of this newly created note have appeared in the Android conflict folder.
No conflicts can be seen in Windows yet.

OCR was no longer activated – so it can't really be the cause of this problem.

At first glance, I cannot see what the conflict is supposed to be. Both conflicts - notes and their yesterday newly created original - note look the same at first glance - the attached images can be seen correctly in all three

What is totally baffling me right now is that I can watch as 4 more new conflicts are displayed for attachments

Screenshot 2024-07-08 102239404×722 69.4 KB

My 2024-07-08 - 10:40 pm fork of this is:

2024-07-08 - NEW - Konflikt beim Anhang ... cc274.png Support

Operating system Android Joplin version 3.0.7 Desktop version info Joplin 3.0.12 (prod, win32) Joplin 3.0.13 (prod, win32) Sync target Joplin Cloud What issue do you have? 2024-07-08 - NEW - Konflikt beim Anhang 3f28df6105ad9d4a5d8727f8c23cc274.png Forked from 2024-07-07 - Android - four elements are not decrypted - #4 by Coffee I took a closer look at the first of these attachments – Conflicts – using the Debug Tool plugin on Windows and Android. I cannot understand what the conflict i…

Coffee · 2024-07-08T12:51:57.283Z

Coffee:

Today I picked out a second problem case and examined it more deeply with the help of the Joplin debug tool plugin 0.2.0, both on Android and on Windows: The message "Some elements cannot be decrypted" on my Android and the four IDs that are mentioned there.

Now that I have deleted the elements
cb2ea0c071a442538409cc8be4f363f1
a30652dd097546779ff227b1ee025a48
69e7bcab0f204ab6a7ec0b64c11700f5
from Android using the debug tool,
deleted all notes referring to it from Android and Windows,
deleted all items from both recycle bins,
synchronised multiple times
and selected "Retry all" for the "cannot be decrypted" error message,
all four "cannot be decrypted" error messages disappeared.
The last item
1f0d03a175134342a61c93e82da9b1fc
I can still find with the Android Debug Tool, but presumably the "cannot be decrypted" error message only appears if more than one element of this type exists.

Coffee · 2024-07-08T12:59:29.841Z

Coffee:

I can still find with the Android Debug Tool, but presumably the "cannot be decrypted" error message only appears if more than one element of this type exists.

Once again, I was mistaken in my assumption.
Another sync later, and the error message for the one element popped up again.

Screenshot 2024-07-08 145424373×660 57 KB

Coffee · 2024-07-08T16:07:41.856Z

Coffee:

1f0d03a175134342a61c93e82da9b1fc

Now I have also manually cleaned up 1f0d03a175134342a61c93e82da9b1fc and all associated conflicts - notes in Android and Windows using the same procedure.

Coffee · 2024-07-08T16:21:53.251Z

personalizedrefriger:

This makes me suspect a problem with the Rich Text Editor save logic — it converts notes from Markdown to HTML, then back to Markdown when saving.

Today I noticed something else while cleaning up the last undecryptable element. This time I documented it in a txt file because the anomaly seems to have arisen in a new Joplin note when I documented it today.

The graphic IDs of the broken graphic elements were not so strangely long in the original note in question. They looked quite normal. Only when I copied the normal-looking non-functioning graphic IDs into a new Joplin note for documentation purposes did they become these strangely long graphic IDs again until a later editing time.

In case it helps you with the analysis, I attach this txt file here.
2024-07-08 - 1740 - Perso 2024 Reparaturdaten.txt (3.3 KB)

personalizedrefriger · 2024-07-10T20:11:08.383Z

personalizedrefriger:

Possible fix: Allow editing notes where attachments aren't downloaded; restore the original Markdown for these images when saving.

Related pull request (only for Markdown notes): Desktop: Fixes #10733: Fix not-yet-created images lost while editing with the Rich Text Editor by personalizedrefrigerator · Pull Request #10734 · laurent22/joplin · GitHub

Note: This pull request does not completely fix the issue -- only the part where items were replaced with a "download" icon.

system · 2024-08-09T20:11:55.824Z

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.