eric99

Yeah, I built in some extra checks in my own HTML export tool and it discovered 28 Untitled Notes in my latest enex export I'll try to find out which hidden characters are the culprit and how they end up in the title

Just FYI, this is the offical ENML doc: https://dev.evernote.com/doc/articles/enml.php#added Now that I've written my own html exporter, I'm even more impressed with the ENEX format, a very strict note description format, with no ambiguities like the free style markdown dialects in other note taking apps.

Thanks for testing! I suggested this to diagnose the problem but I'm glad that it helps you with your export 🙂 What do we learn from this? The most probable conclusion is what john/T already suggested: the title contains hidden characters which were removed in the duplicated note. To prove that theory you could manually remove the title in the original note and type it again. Then export to check whether the exported title is still empty. Maybe this problem should be discussed with @Federico Simionato before destroying the traces ?

Some additional tests to pinpoint the problem more precisely: Does it occur if you export that particular note only? And what if you export a duplicated note of that note? If it still occurs, you can delete the title manually, retype it again and try the export again. If it still occurs after that, you may gradually strip down the note until it doesn't occur anymore ... edit: I've just checked all my enex files from the last year and didn't find any problem ( I do a global search in all my files at once)

I can't reproduce this, on my 10.61.4 windows client it's instant...

yes, and not only much better communication, but also a much more efficient way to fix bugs 👍 Trust is coming back 🙂

Yeah, in previous versions I also got this message when there was actually data-loss. The message "All changes have been saved" seems very optimistic, it is displayed without an actual database commit. This misleading message is the reason users keep editing without realizing that data loss is building up.

Great! 10 notes made in less than 5 seconds, tagging, moving and deleting notes back to normal speed as well 😃

Agreed, but only if they fix the 2 year old html bug first (ticket 3309909)! Especially now with potential data loss issues, HTML makes it much easier to recover a single note than a full notebook import via ENEX Maybe we need a thread to list the bugs that definitely need to be fixed before legacy is discontinued. I am still willing to pay, but EN must deliver what they promise

close, it´s "Not a Number"

On my Android client it takes 3 minutes... What the hell is it doing, is it mining bitcoins or something?

On which device(s) did the data loss occur and under what circumstances? My Android client also loses photos when 4G data connection is used

Is note creation much faster with a disconnected network?

Yes, the new stuff will definitely be a lower priority. The developers have other problems to solve 😏

Why does the public API specification need to be changed? The whole purpose of an API is precisely to provide a stable, consistent interface to a service that can sometimes change internally over time. So the public EN API can still hold, but of course the API's underlying implementation needs to be adjusted a bit for RTE. The API can be extended with the new V10 functionality such as Tasks, Calendars etc. as this does not break existing external integrations (Open Closed principle).

Can you please explain in more detail why Devonthink needs legacy? Isn't it just using the evernote API then?

which minimum log level do you need for the windows client? Will there be more specific logging in the next release to facilitate data loss debugging?

Exactly, and even now you can just subscribe for a single month to do all this manipulating of humongous notes. I don't get all the fuzz about it...

In the windows client I see some data loss too: Reproduction steps: create a new note type a few lines of text (in the bottom right corner I see the notification that everything has been synced) after editing, switch immediately to another note go back to this note: Much of the note's content is gone edit: I also noticed that the evernote client takes 40% CPU resources intermittently every few seconds, even while 'idling' edit: this was 100% reproducible until logout/login, since then I can't reproduce it anymore. I'm trying to figure out what I did before to get my evernote client in that state. Perhaps this has to do with the performance issues that will be resolved next week, but of course poor performance should never affect the correct functioning of a program...

One issue not resolved in V10.60 is the slow creation/deletion of notes which still takes 5 to 40 seconds. This was almost immediately in 10.58.8. Is this a known issue? edit: the extreme delays of 40 seconds seem to be related to server problems. Disconnected, note creation takes 5 seconds, still very slow...

If there's one thing I don't like, it's the bloated messy search results list

since when is obsidian open source? there are only a few developers for the core product...

Impressive, this has all been resolved: searching in a notebook is denied with the pop-up message: "Permissions lost, you can no longer access notebook XYZ" sometimes global search in all notes returns the full note list instead of the filtered one. deleting a note by pressing the delete button doesn't always respond the note menu is sometimes completely grayed-out for some notes when scrolling to the bottom of a result list with length > 128 ( 2^7 ), it always jumps back automatically to the top of the list. So the notes at the end of the list are unreachable sometimes a global search does return a result list, but then after just waiting 10-30 seconds, it spontaneously starts repeating the search with intervals of a few seconds. This happens only when the result list sort-order is set to 'relevant' I still need to further check the note creation / deletion performance which was affected as well.

I further found that typing an additional CTRL-R after the results list is displayed, fixes the result list limitation of 128 notes and probably the result list oscillation. So it's possible that all the reported search problems may have a single root cause (race condition causing an inconsistent internal state resulting in a variety of weird symptoms).

I have added it to my ticket for additional diagnostic information. I hope it gets to the developers 🤞