Jump to content

Schooner

Level 3
  • Posts

    181
  • Joined

  • Last visited

1 Follower

About Schooner

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Schooner's Achievements

26

Reputation

  1. In "notes" view with "side list", note titles of longer length than column cause a perpetual mouseover popup that hides the note immediately above. Really frustrating when hunting for a nearby note - the mouseover shields the note above from selection/viewing. Workarounds: truncate long titles; expand column to max title length. I know. Better solution: kill the stupid mouseover! /Schooner
  2. Update: 10.61.5 (with prior version & data removed before install) has positively resolved data loss I referred to as "tail clipping". Have run a week now without a single instance of trouble. "Slow new-note" issue was simultaneously resolved by same update. @loriewa @coffeefirstthing are you running a "clean install" (logout with data-wipe) of 10.61.5? Your issue sounds precisely like my erstwhile issue, mine resolved instantly with 10.61.5 clean install. /Schooner
  3. Removed data & updated as suggested (my instance insisted 10.60.4 was latest, but indeed 10.61.5 available at evernote.com). Now approaching 24 hours with NO TAIL-CLIPPING / NO DATA LOSS. Yes I'm shouting. Hard to prove a negative as they say - but here's hoping it's behind us. (Also noted - "new note" stalls curtailed in 10.61.5) /Schooner
  4. Ditto in all respects. EN-WIN 10.60.4, Win11Pro. No meaningful response from tech support to prior report, have filed update with logs, no response. At all times "all changes saved" displayed - but it's clear the notes' updates fail to register. Location Vancouver BC. Database large ~35K notes. For some reason this issue affects a minority of users - wondering if it boils down to multiple servers, one of which is "bad". Workaround for now: trying to save only MSWord attachments, they don't seem to get clipped. Ludicrous but limps me through the day. Flight to Notion - fail, Notion import can't handle the database, imports <1%.
  5. I experience this constantly. Win-EN 10.59.5, Win11. Have followed all tech assist instructions down to remove/reinstall/rebuild. Have sent multiple logs immediately after "tail-clipping" incidents. Tech Service response was shockingly useless: "Our team worked hard to find a solution to the issue that you kindly flagged up. However, it was not possible for us to reproduce it successfully nor to detect a generalized issue." As the word "error" occurs many dozens of times in the logs, I interpret this to mean "Yeah your data disappeared, but not in a predictable/repeatable fashion; random data destruction fails to meet our definition of 'bug' so we're going to ignore it". The "tail-clipping" behavior is not simply "fail-to-register/sync latest text". It is "destruction of recently entered or edited data" including mere text formatting. See attached clips of an incident moments ago: ORIGINAL was amended to finish a sentence + set subtitle typeface to BOLD. RESULT shows both added new text and merely emboldened old text destroyed. Incidents of data destruction (tail-clipping) typically display "all changes saved" before EN destroys the edits. All (my) instances of tail-clipping involve editing a note, then switching to an alternative note, then returning to the edited note. It does not occur "before my eyes" while editing. (All data entry via WinEN app; history recovered via WebEN). Schooner
  6. Same experience as Hanseric: "tail clipping" and even "middle-of-text bites" out of notes, irrecoverable via history, clearly they never sync'd. Truly sickening after logging a critical conference call to find your entire record destroyed. Happens daily, typically shortly after starting the workday. Likewise I share his experience of spinning wheel lock-up (>60 sec) occasionally upon "new note" creation attempt; subsequent attempts generally succeed. I'll add one more: attempting to empty trash locks up EN fatally (have to kill EN with task manager to relaunch/recover). 35000 notes, Win11, EN 10.58.8, bromide replies to tech service case (delete user data, reinstall EN, etc.) so far provide amusement & distraction but fail to resolve the issues. Lost a ton of data on initial "upgrade" from legacy (generally in PDF & MSXL attachments). There remain innumerable trivial annoyances - these aren't worthy of mention in the current crisis, they can be tweaked in quieter times. Data loss is the sole and existential issue. Hanseric is "not sure (he) can trust EN right now": my trust is permanently destroyed - notwithstanding the soothing spin of the known evangelists aboard the forum, data loss is not a mere inconvenience, not the fault of the trusting longterm user faithfully following inducements to upgrade, not deserving of good-humored patience. It is a mission-critical failure. I structured my entire workflow - indeed my life - around EN & XL for the past 13 years. Suppose XL inexplicably performed incorrect arithmetic - even for a minority of users? Suppose it's known bugs included irrecoverably vanishing columns or pages? That's what we have here. Reliability is implicit in the Libin promise - an elephant never (that's "never", not "most of the time") forgets. Meanwhile, we're instructed that EN's priority of the moment is moving to Europe and terminating their entire US team. One hopes that - once the deck chairs have been satisfactorily rearranged - the course can be corrected in time for passengers presently aboard. /Schooner
  7. Update: followed wipeout/reload instructions assuming zero unsync'd notes - don't have time to futz around identifying rare sync conflicts etc. Tail clipping: not solved. Have established that it has nothing to do with my templates - occurred this morning with a fresh text-only note. Related issue? New-note fails - also not resolved. Click new-note, get lockup with a green circle spinning for 60-75 sec then *gone* no new note. Next attempt usually works. I've noticed both above issues seem to occur most frequently shortly after startup. I suspect the attachment-destruction issue is resolved in 10.58.8 - all such instances trace to the version I had the misfortune to install, doesn't seem to be recurring with 10.58.8. Recovery: PDFs - note history. XLSMs - likewise, but recent (frequently edited) data lost. For now, I've moved editable documents out of EN.
  8. Of course I've contacted support, with logs & details. Summary: they direct me to delete app, delete user data, reinstall after first saving all unsync'd notes as ENEX. How that relates to tail-clipping issue is not instantly obvious. In any case, I don't see how to identify unsync'd notes, if any. I have 35,000 notes in total. Pointed that out - reply is "sorry...". Additionally, the "upgrade" from legacy nearly gave me a stroke: my most crucial attachments (PDFs & MSXL files) were destroyed, now display as unopenable icons only. I don't need a repeat. Certain among the destroyed documents "disappeared" upon initial opening/editing/resaving, leading me to suspect a corrupted "reformatting" exercise was interrupted by attempted save. I'm not inclined to experiment here. Deployed Backupery, now will let it fester until a few versions forward, see if the issue goes away..
  9. It isn't happening only to me. Search "data loss" - 6 pages of posts - and comments thereto bring things up to current version/time.. Quoting a recent reply to a similar issue from Gregg-CBS I believe: "it’s 2023 and your note saving app is not doing the one thing it needs to be doing properly - saving notes - this is a massive fail." As for support requests - they have mine. And, I see, from others. /tmm
  10. Doing that with critical spreadsheets: EN archives MSXL but frequent opening/editing has been a devastating data-loss issue. But a constantly-edited "daylog" is mission critical for me, has been the fundamental purpose of EN in my workflow for 10 years. Is it a bug... or have we lost our way? The great Libin principle was the elephant - never forgets. Everything else was a slowly evolving random-walk down Feature Avenue. If EN has become something that sometimes or frequently forgets, it's finished - now that we're in the world of OneDrive et al EN risks being demoted to a webclip scrapbook. One could be forgiven for comparing it to a submarine with titanium end bells... enclosing a carbon fiber tube. Flickering lights are tolerable, but hull breach is terminal. EN can survive slowly debugging flaky tables or formatting - but data loss is catastrophic, fatal, terminal, game over. I hope the team is working on nothing else whatsoever, and working so passionately as the Three Mile Island response team: an amnesiac elephant is worse than useless, it is a looming inestimable liability. /tmm
  11. Of all the issues, this one is driving me nuts - time waster: I need view of left panel / Notes list (not preview) / selected-note content. Three panels. So - click "NOTES" in left panel, accomplished. But - as soon as I select a note from Shortcuts, I've lost my preferred "dashboard" view. "Notes" is hidden halfway down the left-hand list... annoying to hunt/click constantly. Want: option to present NOTES view as default. /tmm
  12. Notwithstanding update to 10.58.5: still having occasional "tail clipping" incidents. Win11/desktop. Details: working fast - switching between notes & between apps - return to "daylog" textual note (template based note with frequent annotations to numbered-list formatted text) in EN to find most recent sentences vanished or truncated. /tmm
  13. 10.58.5 not accessible - "update" returns "You're up to date / 10.58.3" (Win11) But: I wait with bated breath... sounds like the answer. /tmm
  14. Subject PDF: drag/drop PDF to create-note. Subject MSXLs: imported within Legacy notes. One in particular bothers me: a daily-log XL thing, updated several times a day. I suspect the system "does something" to it upon resave, but not in time for next opening. I mean - I need it in 20", it's stuck for a day and a half. Where I have multiple MSXL sheets in a single note, I notice that those I have opened since update are now unresponsive "Untitled Attachments" yet correctly labelled with MSXL symbol. Those that are mere archives are responsive, correctly named including filetype suffix, but bear no MSXL logo - just grey. I think the act of opening/editing/resaving causes some sort of action @ Evernote that is taking forever or simply failing. Wish I could read the activity logs, "Error" all over the place. Wondering if there's a massive catch-up stack from RTE/autosave competition? /tmm
  15. New install of "new" EN after clinging to Legacy. Having repeated issues with large attachments notably MS Excel spreadsheets ~13MB reporting as "Untitled Attachment", not responsive to attempted open/save/download. Similar issues noted with some PDFs. Serious data loss if this is permanent. I'm guessing it's not - some sort of re-encoding going on? Can someone explain this to me? - At least one of the botched spreadsheets magically resurrected itself a day after the botch. - The botch seems to occur upon first opening (with editing/re-save) of the attachments. /tmm
×
×
  • Create New...