eric99

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 🤞

@Federico Simionato I already mentioned that the unexpected greyed-out note menu (and corresponding malfunctioning shortcuts) can be fixed with CTRL-R. In case you don't know yet, this trick is also a work around for the notebook permission denied problem: 1. Select your notebook in the left toolbar 2. Press CTRL-R 3. Enter your search string which will now return the correct result list So it seems that a notebook selection ends up in an inconsistent state (perhaps caused by a race condition as it doesn't always happen). This causes a permission denied problem when searching later on. By CTRL-R the inconsistent state is corrected by refreshing the internals and searching works normally again

And if you login with a new account?

Another way to get duplicates (in the windows client) is to accidentally double click an enex archive. It will immediately be imported in your default notebook without confirmation 🙄 I prevent this kind of accidents by associating .enex files to a non-invasive app like notepad++ instead of evernote.

And this problem may be just the tip of the iceberg: the grayed-out menu may reflect the internal note status that got stuck in "Busy state" or something. Maybe this corrupted note state is used internally for synchronization, RTE etc. causing data loss in the worst case. You can't know for sure until this bug is fully analyzed. That is why seemingly harmless bugs should also be taken seriously.

My fault, I wasn't specific enough. For me, the problem is mainly that the delete button doesn't work either, due to the disabled notes menu.

If I spot a bug, I try to reproduce it as simply as possible and then indeed send a ticket. That's how I did it with these 6 regression problems too. I hope they even read it as it contains the detailed reproduction steps.

Obviously, in this particular case the issues in this horrible release are reported by the majority on this forum, but I'm glad you touch this topic because this indicates that users might have a false sense of safety because they don't fully understand how and when race condition bugs really occur. To illustrate this with an example: would you stay with a bank if a money deposit, very sporadically, leaves your account but never arrive at the recipient due to the fact that you type a little bit to fast or click the buttons in a slightly different order or a network glitch or whatever? And a few days later you receive an apology letter, ‘sorry we lost your €10000 and there is no chance that we can recover it, but we will offer you a full year without banking costs as compensation'. Fortunately, banking transactions are designed so that this can never happen. Race conditions were taken into account in the early design, not just as an afterthought when symptoms appear later when it's actually too late, because these issues need fundamental fixes. Now back to evernote: do you accept that 0.1% of data will be lost due to a race condition? The problem with race condition bugs is that the seemingly harmless symptom you see is only the top of the iceberg. You only know the full impact when you've diagnosed it completely. That's the reason that race condition bugs should always be investigated to the bottom. And what worries me most, seeing bugs like this, how many similar sporadic race condition bugs are there in more critical parts designed by the same developers?

Perhaps then the 'expert' group is not a good statistical population and I hope this will not influence management too much in their assessment of the problem. Sure, as a developer of life critical devices I know where to look and how to quickly trigger this kind of race condition bugs but I think in this case it's not that difficult to reproduce these issues by trying harder with different search strings, notebooks, longer result lists etc. It even occurs in the web version which I tried on different computers. For example, have you really tried to reproduce the disabled note menu and delete button issue I just mentioned before: https://discussion.evernote.com/forums/topic/146555-👉-input-needed-– what-issues-did-you-experience-in-the-last-couple-of-days/?do=findComment&comment=693413

What I still don't understand is why all these issues haven't been found by their SQA and automatic testing. I discovered the 6 problems in less than 10 minutes with a simple smoke test. Do they know their own product?

Thanks for testing. Have you already submitted a ticket for this?

I'm also curious if you can reproduce this specific bug: These two issues are related: the note menu in the top menu bar is sometimes completely grayed-out for some notes - deleting a note by pressing the delete button doesn't always work (delete doesn't work because the note menu is completely disabled) How to reproduce this: 1. select all notes with the 'Notes' button in the left side bar 2. from the top of the note list, with the arrow keys, scroll a few notes down, then a few notes up and repeat this a few times. Then check the note menu in the top menu bar for each note you've scrolled through: several of them are grayed-out and therefore can not be deleted anymore You can unblock this by a forced reload ctrl+shift+R This looks like a race condition bug where the note state sometimes doesn't get updated properly while scrolling through the note list.

This is typical behaviour for race condition bugs, but all the problems are still there, just try a little bit harder with other notebooks, search strings and result lists: https://discussion.evernote.com/forums/topic/146555-👉-input-needed-– what-issues-did-you-experience-in-the-last-couple-of-days/?do=findComment&comment=693114

It works on my A50. Do you know the installed version? Have you already tried to restart your phone completely?