John in Michigan USA

OK here's what I posted on FB re this video. First comment: I was very encouraged by @Ian Small's prompt reply:

Maybe it could attach the original headers (or even the full source!) to the note as a text object? That way they'd be preserved, and searchable. I like the idea of being able to forward something by email to EN without having to save the original in my email system in case EN mangles it when turning it into a note.

I just made some feedback I'm quite proud of on the Facebook version of this announcement. Should I re-post my feedback here, or are people able/willing to follow the link and tell me what I got wrong over on Facebook?

Must have missed that. Got a link?

Thank you for all that detail. My thoughts: In EN for Windows, restoring the database files themselves (everything under C:\Users\<userid>\Evernote\Databases) does preserve note history, it restores the database to exactly where it was when the backup was made. Can restore to a temp location and tell EN client to use that location while you restore what is needed. I looked quickly at the enex format spec and didn't see anything about history. Are you saying the enex format preserves note history? Good to know. Also, I just re-ran a test that I haven't done since Jan 2017. Turns out EN for Windows does preserve note history after you move the note to a different notebook. Great news! I wonder when that changed? Will it change back? Anyways, thanks for pointing that out.

I forgot to say, I haven't tried exporting a note, or saving it in enml, but I doubt either of those formats keep note history.

An advantage of keeping your own backup of Evernote is, when you move a note from one notebook to another, the note history doesn't come with it, and is therefore no longer available to you. Evernote will NOT restore this note history, even if you undo the move. But, if that note history was important, you could restore (or extract) from your backup of the local EN database.

So far we've seen mostly UI presentations. IMO the improvements with the highest return, BY FAR, are to be found in the area of code quality, regression testing, operations, etc. I hope that gets covered.

Have you opened a ticket? If you get a chance, can you post the version info (from the activity log, not the settings) here?

That kind of backup is secure vs. equipment failure (yours or theirs) but the most common use of backups is to recover from user or admin error, e.g. accidentally deleting something or discovering a bug that causes corruption. In which case, unless you are lucky and discover the problem before sync happens, relying on Evernote's backups to help you recover is no good. They will only 'restore' your account to the most recent version of it, which would be the corrupt version in this scenario.

Hi @NanetteK, I have this type of problem too. Unfortunately, Evernote's text editor has many issues, particularly with cut-and-paste. I use the Windows and Android apps, and sometimes the Web, but the iOS folks have similar problems. Cut-and-paste that involves checkboxes are particularly a problem. They've been promising fixes for ages, and there have been a few, piecemeal fixes, but there have also been new bugs introduced into the editor. To make your problem more clear, at minimum, you should include information about what device you are using, and the version numbers of all relevant software/apps, including the Operating System. Additionally, it looks like the problem you are having is the kind that is hard to describe in writing. Perhaps you could try making a video of the problem happening on your device? Upload the video to YouTube, then post the link here in the forums. I can't say if that extra effort will result in a fix, but it will make very clear exactly the problem you are having.

Had to factory reset my Pixel 2 XL for reasons unrelated to Evernote. After re-installing all my apps, I am running EN 8.9.1. The saved search problem is back. Exact same symptoms as ticket #2804215 which forum users can read about at:

My saved searches have also gone missing, except for some (not all!) of the shortcuts that point to saved searches. HATE THIS.

If I read correctly, the OP has access to both Mac and Windows clients. The GIMP has Linux, MacOS and Windows flavors. Re the Applescript approach: you would probably have to include a step to access the EN API, in order to tell EN to sync the changes?

Hi, I think this is a windows problem. But the image capture started on Android, so I've included that info too. EN 8.9.1 on Android 9 on Pixel 2 XL. EN 6.17.7.8474 (308474) Public (CE Build ce-62.1.7539) on Win 7 To reproduce: EN for Android: Use the plus icon to create an new image note. Capture 1 image, include a few lines of text if you like. After sync, the note size reported by EN for Windows is 923 KB Using EN for Windows, right click the image and rotate counter-clockwise. The note size is now 1.1 MB. Using EN for Windows, right click the image and choose Annotate. Using Annotate tool, crop the image to about 50% of it's original size. Apply the changes. On the menu, pick Save and Exit to return to EN for Win. The note size reported by EN for Windows is now 2.4 MB! I definitely recall this being a problem in the Windows client several years ago, but I've searched the discussion forums and can't find any mention of it. Is this a known issue? Time & mood permitting, will open a ticket...

The GIMP has nice features for batch editing, and fully supports command-line options. Perhaps there is a way to use the API, or (!) a screen scrape from the Web client, to automate the process of correctly sizing images and sync'ing those changes.

Please can there be coverage of the effort to: address the backlog of bugs (real acknowledged ones, not necessarily complaints about how things are designed, or feature requests) improve regression testing tighten up the beta process so changes aren't released straight into production better version control

Yeah there are different display modes (not just formatting of results, there are different controls available) depending on how you search. In most cases, there's no clear UI design rationale for using different modes. For example: I'm very thankful for reminders, but they weren't part of the EN design concept. They were shoe-horned in shortly after I starting using EN. That would date them to 2011 or 2012. Some search results modes were updated to deal with reminders intelligently, other modes were not. With well designed code, search results are rendered by the same object (block of code), regardless of how you search. So, changing that code to handle reminders would have solved the problem in all search results. This is more evidence the EN code base needs to be re-worked. No wonder it is so hard for them to make changes without introducing more bugs!

We've been asking for better communications. Here is a start

Shouldn't it sort properly, whether it is sync'd or not?

Several people here point out that, although search is now working again (huzzah!!!) the fix appears to have triggered some other problems, like search string highlighting, clever release notes that are now too clever, and more sub-version confusion / fly-by-night updates. I also found that they took away a feature that displays items with current reminders at the top of the results. I wrote about that here.

@Shane D. Thank you very much for following up! I say cautiously that it appears to be fixed. It appears that the fix was accomplished by removing another, possibly less important feature: the ability to highlight reminders in the search results. I've detailed this in an update to "EN support ticket #2804215 screen shots and annotations" (look for the paragraph dated 5/17/2019.) If I had to chose between saved search working and the reminder highlight, I'd chose the former. Ideally I shouldn't have to chose. Thanks again for your excellent follow-up Shane.

Hector, Thanks for the update, it does mean a lot to know that Evernote is still aware of this issue and the problems is causes for users. It would help a great deal if someone from Evernote could address the question: when these problems were first reported, why not roll back the changes to the last known good version (probably < 8.9) -- if not for everyone via Play Store, then why not at least offer users a manual way to download and install the last known good version. Evernote could post the 8.8.x .apk file someplace, so we don't have to rely on services like https://evernote.en.uptodown.com/android/old who offer a complete set of past .apks, but leave us to take it on faith that the .apk's are...unmodified, shall we say... I look forward to your response.

Fair point, should have thought of that.

I tried this and it gave me an extra $10 credit. I haven't set up billing yet, so if you haven't got your $5 maybe they don't do it unless I covert to a paying customer? Which I will likely do. Thanks.!