Jump to content

John in Michigan USA

Level 2
  • Content Count

    96
  • Joined

  • Last visited

Community Reputation

32 Good

2 Followers

About John in Michigan USA

Profile Information

  • Subscription
    PREMIUM

Recent Profile Visitors

3,565 profile views
  1. 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.!
  2. Six years ago I gave them a 5 star review. Since then, I've updated the review each year. Any year that included one or more long-standing, reported and well-documented bugs, I deducted a star from my review, and wrote about the problem in the review. I am now at 1 star, been there since last year. What's worse: at least 1/3 of these bugs are regressions -- by which I man a bug that occurred in a feature that as working fine in the previous version, a bug that could have been solved by simply rolling back the change(s) in the relevant code section(s) so that the feature resumes working again. Any team with basic source control and non-spaghetti code can easily do this. Plus, they should be doing regression testing, so that when a change causes a previously identified bug to re-occur, the team spots that right away instead of waiting for users to leave/complain. <insert broken record emoji>
  3. Downgrading brings back memories....what I remember from 2+ years ago is, downgrading won't destroy or prevent access to existing large notes, but it will prevent you from creating new ones over the size limit. It may let you edit, but it presumably won't let you save if the edited note is too large. So far, reasonable...but the limit can cause some very subtle problems! For example, if you cut a large embedded object from a note, get distracted by a notification or something, then paste it in a different part of the note...and the note auto-saves in between the cut and the paste, it might not let you paste, as technically you are making the existing copy of the note, which is under the size limit, into an oversize note. Or, if you use the EN app control to start a voice (or worse, video) recording...if you accidentally exceed the size that can be saved into a note, it will show you an error message (reasonable) but it will also send whatever you recorded into the bit bucket! Many people have encountered this...support assures is, there is no temp file of your recording. You'll have to re-record whatever it is. Without the size limit, this bug usually only happened when your device was slow, or if the user on a fast device doesn't wait 10-20 secs after stopping the recording for the file to attach itself and appear in the new note. Even on a fast device, if you try to make any other changes to the note before the recording fully saves, the save sometimes fails in which case your recording is lost. With the size limit, it must means there one more condition (size) that could trigger this bit bucket bug...and NO it hasn't been fixed to the best of my knowledge. Another scenario had to do with pasting objects that are file-less images (ie. you copy an image into the buffer without first downloading it) into a note. Sometimes the paste operation would convert let's say a X MB .png into a 5x MG generic image object during a paste operation. I think that scenario was patched re certain image types, but I highly doubt all the various possible large, file-less paste objects where addressed systematically. This bug could still be lurking, waiting for you. It could cause your note to exceed the size limit inadvertently...or to exceed the upload limit inadvertently. I haven't reproduced these scenarios in a while; but when I do anything mission critical, even with Premium, I assume they're still out there...waiting to strike!!! Good luck and do keep us posted. This makes me want to try Notion. Is there a referal a friend or similar program from them?
  4. @rimboma After today's auto-update from G Play Store, which didn't help my Pixel 2 XL, I tried @Vrykolas tip . Didn't help. Thanks anyways.
  5. Yeah that tall cursor is misleading, it make it look like if you continue typing, the new characters will be size 36 when (I'm assuming) they'd be normal sized. A minor bug, but yeah, add it to the long list :-)
  6. @rimboma it would be interesting to know your detailed version number from your most recent activity log. Under the "Device and Install Info" section you will find lines similar to: Evernote version: 8.x(yyyyyyy) Evernote revision: 8.x_zzzz Evernote type: public (or something else) This information would help determine if your issue is related to @Bill Clarke 's problem.
  7. @EdH that Table of Contents hack is slick! Good thinking. My thought: There is also a GUID (a.k.a. Shard ID?) in the shareable link generated by (Windows client) selecting the note then Ctrl+/. I doubt that this GUID is the same as the one generated by Ctrl+Alt+L The former lets anyone with the link see the note, the later would require the user to be logged in. Either one might be useful to @mikeinnyc. Ctrl+/ would presumably generate the same GUID as you'd see if you generated a TOC that included the given note.
  8. Lately there's been a great deal of confusion about exactly what version of the Android app is beta. If I am looking at my activity log, will it always include the string 'beta' someplace in the version info? Specifically, what part of the activity log? If my activity log says: Evernote version: 8.9(1082733) Evernote revision: 8.9_2452 Evernote type: public Then is it safe to say, I'm not running the beta app?
  9. @Lexbrkly It might be interesting to check your activity log and post the build number and revision number of 8.9 that you have. Here's what I found when I did this.
  10. @gazumped Play store now offering ver 8.9 updated April 4, 2019. I haven't paid much attention to this since I left the Beta, so I don't know if it is normal for EN to release an update without incrementing the version number (as it appears 8.9 was first released on March 28). Also on 3/28 at 18:58, Alexis M wrote an update to my ticket 2804215 stating that version 8.9 [specifically, what the activity log calls ver 8.9(1082733) Evernote revision: 8.9_2452 ] was Beta. The activity log I just generated on my Pixel 2 XL which is running the GA app says 8.9(1082793) Evernote revision: 8.9_2461 i.e. only minor changes between the two. So it appears EN took Beta software with known, show-stopper issues, and pushed it into production. This is still shocking; I wish it was a surprise. @Bill Clarke do you happen to have an activity log from the version of the app you were using when you reported this problem? It would be interesting to know the build number [ the 7 digit number in parentheses ] and the revision number.
  11. Although my symptoms are different, I have noticed the same confusion about version number 8.9 and/or beta software. See my comments here and here. Hat tip: @Dave-in-Decatur
  12. Although my symptoms are different, I have noticed the same confusion about version number 8.9 and/or beta software. See my comments here and here. Hat tip: @Dave-in-Decatur
  13. @Dave-in-Decatur thanks for the links, I will start following those discussions too. It looks like Evernote on Android is having a version contamination problem. Astoundingly, this appears to have been going on for quite a while.
  14. Me too. I followed the instructions and left the Beta program months ago, yet somehow auto-update keeps handing me Beta software. This has happened on my new phone and my old tablet. I now have zero (0) mobile devices on which I can use Evernote effectively.
×
×
  • Create New...