Tim Hudson

So, for current Windows 11 users, the interim solution is to buy a Mac, purchase all new software in Mac versions and then migrate all data to the new machine in order to successfully do screen captures in Evernote.

Thanks for your response. I hadn't thought about the internal links issues - that will cause me some major hiccups. Also hadn't thought about the Upload Limit. My export files total 10.2 GB so that would be a problem. I received an email from EN support this morning and they said they are aware of the issue and are actively working on it, so that is good. I will sit tight Thanks again for your response!

I've done this - there is no change in behavior. My thought is that there is something in my account data that gives the Windows Desktop client issues when doing a search. The web client works. Creating the test notebook and notes in my Evernote Free account and then searching works. No one else has been able to replicate my issue. Their clients/databases work fine. I really hate to do this, but I'm beginning to think after I backup all my data via "Export Notebooks" that I will have to delete all my notes FIRST so they are gone from the EN servers, then repeat the procedure you recommend above and then import all of my data back in. I have no way of knowing if importing will bring whatever corruption there might be back to my account. And I'm REALLY worried that I won't get all of my data back. And after doing all this work, it still may not solve my problem. If it were just this little test case, I would have blown it off and let EN deal with it. But it impacts NUMEROUS search procedures that I am trying to do. Searches that I thought were functioning, I am now finding they are leaving notes out of the searches, leaving notes in the searches that should have been excluded - just a mess.

This link might provide some useful information. I'm coming to believe that this is the way it is expected to work by EN as they replied to a support ticket of mine with that conclusion. https://www.evernote.com/shard/s79/client/snv?isnewsnv=true&noteGuid=e07a20f1-fed2-cd16-a09b-1641f493c1f5&noteKey=X2hskNkDZnp3WNMsU5lzABB9u35Xrfzqsrj2s_UqtvTR-9JOm9SG5z-Kjg&sn=https%3A%2F%2Fwww.evernote.com%2Fshard%2Fs79%2Fsh%2Fe07a20f1-fed2-cd16-a09b-1641f493c1f5%2FX2hskNkDZnp3WNMsU5lzABB9u35Xrfzqsrj2s_UqtvTR-9JOm9SG5z-Kjg&title=20240126%2B-%2B26Jan24%2B-%2BEvernote%2BScreen%2BCaptures%2Bin%2BWindows%2B10%2Band%2BWindows%2B11

If I wait for a period of time on my desktop clients, then the search is not successful. Only if I do it right away after a complete signout (Remove data from computer) and sign back in does it find the note. Then shortly thereafter it disappears as a "found note". Now on the web client, it reliably finds the note. And as mentioned above, I tried the test on my Evenote FREE account and the search is successful. The "found note" does not disappear. Therefore, the appearance, at least to me, is that my data in my account is somehow corrupted and impacts the desktop client search functionality. (I have NUMEROUS other search issues, especially with INTITLE, that might be explained by whatever is going on here). I could be wrong, but the only place the error/issue occurs is on my desktop client in my PERSONAL account. I have a support ticket filed to see if EN support can give me any ideas - how to uncorrupt my data or if that is not the case, how to resolve, what appears to be, my isolated problem that others cannot reproduce. I am currently exporting all of my notebooks in the event a total reconstruction of my account is needed. I'm on pins and needles with that if it is required as I have a lot of notes that I can't afford to lose, but way too many to do anything other than an ENEX export by notebook. Hopefully EN Support will have a working solution.

Mike P - I had another separate issue with Local Notebooks - EN support had me delete the EN folder in %AppData% on my Windows computers and re-install EN. While this did not resolve my problem, I re-did their instructions and then followed with a complete uninstall of EN (as you had suggested) with RevoUnInstallerPro v5.2.5 and after signing back in my problem with the Local Notebooks got resolved. It did NOT resolve my Search issues described above (including the disappearing Search Note issue). One additional comment - I have an EN Free account, so I recreated the test notebook and test notes and I WAS able to find the intitle:201 note AND it did NOT disappear - mirroring your test results. I'm beginning to conclude that I have some corruption in my EN account data - if so, it may lead to some answers for this and other issues I have been having that other folks haven't been able to duplicate.

I have just updated to v10.75.2 and this issue has been resolved.

Mike P. - Just a reply comment (and I really appreciate your replies/comments). As I mentioned, I have an installation of Evernote on three different computers - one has Legacy (which we will ignore in this conversation), one with Windows 10 as the operating system and one with Windows 11 as the operating system. I have the disappearing search note issue occuring on both of these computers. So while a complete uninstall could be an answer, it seems odd to me that the same error occurs on both of my computers. As I mentioned in my edited note, it was recommended to me to tag Federico Simionato on the video comment, so I am going to see if he reviews it and has any comments - therefore I am going to wait on the total uninstall to see if that happens - don't want to create too much of a moving target. Again, thanks for all of your comments.

Google's search doesn't work exactly as you said - it gives the option to search for the search term as entered or to search with included results: But I'll go with the assumption that there was a conscious change by the Evernote developers between Legacy and v10 to perform the intitle search as you described.

Agreed. If you read the post, all of these results were as expected - they matched what I was seeing in the web-based client. The issue was that these results in the Windows Desktop client were found immediately after performing a sign-out, clearing the data from the computer, signing back in and performing the tests. HOWEVER, after about a minute and a half, doing a reverification, the results went back to the erroneous results previously reported. intitle:201 went from finding the 2019 note to not finding the note. intitle:201* went from finding the 2019 note to not finding the note after about a minute and a half - like it was reading data from one place immediately after the sign-out, clear data, sign-in and test and then went back to reading different data a minute and a half later and obtaining different results. Like it was in the process of downloading data back onto my computer and once the downloaded data made it to my machine, search results changed. The enclosed video shows that a change occurs about 1 minute and 30 seconds into the video, where a search changed from finding a note to then showing not finding a result with no intervention on my part - I did the search and then just sat there, recording my screen, watching my screen and Evernote changed the results on its own, right there in front of me. That was totally UNEXPECTED behavior on the part of the Evernote Windows Desktop client. I have no explanation for it. I was totally baffled when I saw it. It may be a corruption in my Evernote data that makes its presence known as it gets downloaded back onto my computer, but I don't have a clue as to what to look for.

I just found something that is very interesting. I sign out - clear the data from my computer - sign back in. If I quickly do the searches that I was having issues with, the searches work properly. By the time I have checked them all and then go back to reverify, the searches do not work anymore again. I have repeated this process three times now. Same results. e.g. intitle:201 finds the 2019 note intitle:201* finds the 2019 note -intitle:201* finds the 2020 note intitle:20 finds both notes -intitle:20 finds both notes intitle:20* finds both notes -intitle:20* finds no notes The results are just like the web version - however, within about a minute or so, the results go back to the erroneous ones shown in the table. e.g. on the second time through after about a minute, searching for intitle:201 shows no notes found, intitle:201* shows no notes found, and so on. In fact, if I do the sign-out, clear, sign-in and search for intitle:201 it will show the 2019 note for about a minute and then it will disappear - showing no notes found. I've attached a video clip (hopefully it works) - at 1:29 the note disappears Note search disappearance.mp4 ***EDITED*** I just updated to v10.75.2 Windows Desktop and still have the same issue occuring (disappearing search result). I am a member of Harmon Enterprises Academy and was suggested to tag @Federico Simionato

Just as an FYI, I signed out of Evernote and selected the option to remove my data from the device on my Windows 11 PC. I signed back in and performed the tests again - I got the same results. ***UPDATED*** - I just signed out of Evernote and cleared the data on my Windows 10 computer. After signing back in, I again get the same results.

If I could engage you in a conversation on one more example: Based on what you were saying, the Web results are correct. It appears a philosophy change occurred between Legacy and v10 in an intitle search regarding whether the note contains the search string as a standalone word, vs. the note containing the search term in a word that starts with the search term. The results from the Windows desktop version (whether Win 10 or Win 11) and the iOS version make no sense to me. Thanks in advance for listening.

So what you are saying is that in the positive, searching for "tomat" is the same as searching for "tomat*" but in the negative, searching for "-tomat" is not the same as searching for "-tomat*". Interesting - had never seen that explanation before. Thanks

Not sure how you could get "worked as expected" when the web version doesn't work. For example: On the web version: For a note with tomato in the contents of the note, but untitled Searching for tomat finds the note Searching for -tomat also finds the note These are mutually exclusive search requests, yet EN finds the note in both cases. Working properly for a search for "tomat" would mean that EN would not find a note that only had the word "tomato" in it. Without the * at the end, it is supposed to find "tomat" separated by "white space", not "tomato". Searching for "tomat*" should find notes with "tomato", "tomatoes", "tomatosauce", etc. On the web version: For tomato in the title and potato in the contents of the note: Searching for intitle:tomat finds the note Searching for -intitle:tomat finds the note These are likewise mutually exclusive, yet EN finds the note in both cases. Working properly for a search for "tomat" in the title would mean that EN would not find a note that only had the word "tomato" in the title. Without the * at the end, it is supposed to find "tomat" separated by "white space" in the title, not "tomato". Searching for "intitle:tomat*" should find notes with "tomato", "tomatoes", "tomatosauce", etc. in the title. So those are searches on the web version - the contents of any local information should not impact the web version results. In addition, I have a second computer, running Windows 11. and it is also running desktop version 10.74.1 10.74.1-win-ddl-public (20240130023748) Editor: v176.52.0 Service: v1.90.1 © 2019 - 2024 Evernote Corporation. All rights reserved On the Windows 11 computer ("confirmed" meaning I have re-tested these cases on the Windows 11 computer and found the same results as on the Windows 10 computer - thereby, to me, this would indicate an issue with "local" data is likely not the cause - but I will try the clearing of the local data on the Windows 11 computer when finished here - if the results change, I will then perform the clearing on the Windows 10 computer): For tomato in the contents of the note, but untitled Searching for tomat finds the note (confirmed) (same on iOS 10.68.0 (1216171)) Searching for -tomat finds the note (confirmed) (same on iOS 10.68.0 (1216171)) these should be mutually exclusive searches , yet EN finds the note in both cases. Working properly for a search for "tomat" would mean that EN would not find a note that only had the word "tomato" in it. Without the * at the end, it is supposed to find "tomat" separated by "white space", not "tomato". Searching for "tomat*" should find notes with "tomato", "tomatoes", "tomatosauce", etc.. For tomato in the title and potato in the note content Searching for intitle:tomat finds the note (confirmed) Searching for -intitle:tomat finds the note (confirmed) these should be mutually exclusive searches, yet EN finds the note in both cases. Working properly for a search for "tomat" in the title would mean that EN would not find a note that only had the word "tomato" in the title. Without the * at the end, it is supposed to find "tomat" separated by "white space" in the title, not "tomato". Searching for "intitle:tomat*" should find notes with "tomato", "tomatoes", "tomatosauce", etc. in the title. Searching for intitle:tomato finds the note (confirmed) Searching for -intitle:tomato does not find the note (confirmed) these work as expected - i.e. the note with the independent word "tomato" in the title was found with intitle:tomato and the note with the independent word "tomato" in the title was not found with -intitle:tomato Searching for intitle:tomat* finds the note (confirmed) Searching for -intitle:tomat* does not find the note (confirmed) these work as expected - i.e. the note with the word in the title that starts with "tomat" was found with intitle:tomat* and the note with the word in the title starting with "tomat" in the title was not found with -intitle:tomat* For the untitled note with tomato in the note content Searching for tomat* finds the note (confirmed) (same on iOS 10.68.0 (1216171)) Searching for -tomat* does not find the note (confirmed) (same on iOS 10.68.0 (1216171)) these work as expected - i.e. searching for "tomat*" should find a note with "tomato" in the note and searching for "-tomat*" should not find a note with "tomato" in the note. Another set of cases (on both Windows desktop and web UNO): Two notes - one with 2019 in the title and in the note content, one with 2020 in the title and in the note content Searching for intitle:202 finds the note with 2020 in the title and the content (confirmed) Searching for intitle:201 does not find the note with 2019 in the title and the content (confirmed) Searching for intitle:20 does not find either the 2020 note nor the 2019 note (confirmed) Searching for intitle:20* does not find either the 2020 note nor the 2019 note (confirmed) Searching for intitle:201* does not find the 2019 note (confirmed) Searching for intitle:202* finds the 2020 note (confirmed) These two seem to be correct in that the 2020 note does not contain the independent word 202 and the 2019 note does not contain the independent word 201 Searching for -intitle:202 finds the note with 2020 in the title and the content as "202" is not in the note as a standalone word (confirmed) Searching for -intitle:201 finds the note with 2019 in the title and the content as "201" is not in the note as a standalone word (confirmed) However, Searching for -intitle:201* finds the note with 2019 in the title and the content (confirmed) - the search should not have found this note But searching for -intitle:202* does not find the note with 2020 in the title and the content.(confirmed) - works as expected So two different computers with version 10.74.1 Windows Desktop (one running Windows 10 and one running Windows 11) get identical results for these tests, but the results are different on the web version. That would seem to indicate to me that the codings are different between the Web client and the Windows Desktop client, but there is likely not an issue with local data causing this behavior. As a general statement, on the iOS version, the tests with 2020 and 2019 notes generated results even more bizarre. So as not to confuse the above even more, I will hold off on discussion those.