EN iOS 8.24.5.370551- search for "todo:false" and "stack:"

[Holg 0]

Hi all,

I assume that most of you rely heavily on the search abilities of EN - which is working great on my macOS app.

Recently I started more and more to use Evernote on iOS (iPad) and I had to learn that the search function is not working reliable there. I found posts from  2015 which describe exactly the problem but according to an EN post this should have been solved already years ago.

I use searches to organise my personal and also professional work like the following:

• - stack:JOB todo:false => get all notes that are not in my JOB notebooks, grouped in the stack JOB that have tasks that are not completed -> should bring me list of notes with personal tasks
• stack:JOB todo:false => get all notes that are in this my JOB notebooks, grouped in the stack JOB that have tasks that are not completed -> should bring me a list of notes with tasks in my job

In macOS this is working reliable - on EN for iOS this is not working at all.

Even using only a search "todo:false" does not bring any result. Queries like "todo:*" show me some, but not all, notes with tasks. I even tried "en_todo_false" without any success.

 

Now my question .. is the search working different on iOS (which would be bad but this I could handle) or is this simply a defect? If so, this might be a blocker of using EN to organise my tasks at least on iOS.

Hope4help!

BR,

Holg

[CalS 5,280]

5 hours ago, Holg said:

Now my question .. is the search working different on iOS (which would be bad but this I could handle) or is this simply a defect?

I would say that a search in the same context on any platform that does not return the same results on all platforms is a defect.  A big defect.

Not sure it is your case, but I noticed some time back that not all PDFs are created equal when it comes to search.  Filed a ticket and it was determined that the EN server OCR engine was not 100% accurate with certain fonts.  So searches on my PC and IOS do not match.  Just tried the search from when I found the error and am missing 73 notes on IOS.  So the problem still exists.  To me this would be a red flag bug, an ERROR in search results being a good sized crack in 100% reliability of second brain.  Interesting set of priorities that such a defect still exists.  🤷‍♂️

[PinkElephant 8,072]

It clearly is desirable that a search on one platform delivers the same result as on another.

From my understanding, if a pdf does already come with an index (as from local OCR) it will not be OCRed again by the EN server. If not it will be indexed on the server, and the result copied to those clients that hold a local search index. So inside of EN there should not be 2 diverging search indexes. Outside of EN results may differ, like Windows index or Mac Spotlight (that is only indexing the notes titles at the moment, if I am not mistaken).

Of course a local index may have a deficiency, that can be healed by using the advanced hidden options in the help menu. But from my understanding, if the local and the Server index are harmonized, plain search results should be the same.

If the more complex Search Options are the same on the desktop and web versions, I have not yet tested. Maybe I should, one day ...

[CalS 5,280]

17 hours ago, PinkElephant said:

Of course a local index may have a deficiency, that can be healed by using the advanced hidden options in the help menu. But from my understanding, if the local and the Server index are harmonized, plain search results should be the same.

Not so much.  A paragraph from the dialogue with EN in August 2018 re differing search results related to PDFs.

The issue you're seeing is related to server-side search, which seems to have an issue with recognizing the wrong font when scanning PDF files. The text in the PDF is printed in a monospaced font, so the letters are wider, but the OCR sometimes incorrectly recognizes it as a non-monospace font, so it sees the gap in position and thinks there's a space there.

Net of it all the PC works fine but IOS/web searches aren't accurate if the above condition is met.  OCR on the server is deficient. 

[Holg 0]

Hi,

my problem was not related to PDF or any other attachment. I had this problem with text ony.

BR,

Holger