[Bug]: Note backed up by evernote-backup is missing pics compared to same note backed up manually with Evernote

[Tone2608]

evernote-backup version

1.9.3

What OS are you using?

Windows

OS Version / Linux distribution

Windows 11

Bug description

I found that when importing enex files from evernote-backup into UpNote, some of the pictures did not come through.
Example: Evernote note had 5 pics but after running evernote-backup and importing the result file, it only had 3 pics. Same note imported after manual export from Evernote came through with all 5 pics.
Note name is "2019/20 - Street Glide Pics".
Interestingly, when importing my entire notebook, Evernote-backup correctly titled 3 notes that are titled as "Untitled Note" when using Evernote manual backup. So it seems you are doing something "better" than what Evernote does... thanks.
Test Notebook.zip

Log excerpt

I am not able to use Verbose mode:
D:\Evernote\Backup>evernote-backup export Newback2 --verbose
Usage: evernote-backup export [OPTIONS] OUTPUT_PATH
Try 'evernote-backup export --help' for help.

Error: No such option: --verbose Did you mean --overwrite?

[Tone2608]

Has anyone had a chance to look at this bug report? I am waiting on my Evernote export to hopefully have a more reliable result once this is resolved or explained. Any effort to look into this is much appreciated!

[Houska1]

I'm not an evernote-backup developer, and I don't use Upnote, but this made me curious.

Both versions of the enex (evernote-backup and manual) for me import back into evernote with all 5 images visible. I can see no visible differences between them there.

I looked also at the xml code in the 2 exports. The only differences I see is that the evernote-backup export has images base64 encoded at 120 character line length, and the evernote manual export at 256 character line length. And that the evernote manual exports include a <source-url> tag referring to an en-cache: url, which is something new to me. But neither of these seems to create a difference when I import them back enex->evernote.

So can you share more of e.g. which image is getting lost when imported into Upnote? This may be some weird aspect of how Upnote is interpreting (nearly) identical enex rather than a flaw in evernote-backup how it is exporting it - which of course doesn't really help you solve your immediate problem but might help figure out what it would take for evernote-backup as intermediary/translator to step in to address it.

[Tone2608]

Thank you Houska1 for your research on this issue! The pics that came through on UpNote were Pics 2,3,5. So that means image 1 and image 4 were lost in the import process. I should have done what you did in trying to import them back to Evernote, so thanks for that additional info that they import there just fine.

Knowing what you're saying, I suppose I can open a case with UpNote support and ask them to have a look at it to see why they're passing up the 2 images. If you have any other ideas or need more info, just let me know. Otherwise, I'm hoping the devs here can have a look to see if it's something they're doing incorrectly or inconsistently during export that would throw off the UpNote importer. Thanks again for your help!

[Houska1]

@Tone2608 It's tricky since Evernote has not published a complete official specification for its enex format (it's xml, which is open, but I'm referring to how EN encodes it's "stuff" in it), so anyone attempting to read it (like UpNote) have to just make assumptions what they might expect. That means that it's hard to assign responsibility for import-export glitches like this, especially with a 3rd party tool (evernote-backup) in the middle.

If you're at all techy enough to be willing to get your hands dirty editing the xml in the enex file (a good text editor, like Notepad++ on Windows, will do it pretty easily), here are two self-help ideas to help diagnose, so you can then figure out who needs to change something.

1. (On re-read, actually this one doesn't need editing with a text editor). Create 5 duplicates of your note, keeping only one of the images in each one. Try to export those with evernote-backup and import into UpNote. Therefore identify if it's those images themselves that fail to import, or something about how they are combined into one note that creates the problem for UpNote.

2. Edit a copy of the manually exported enex and in the 5 resource tags (one for each image), remove the <source-url> tag located inside their <resource-attributes>. This <source-url> tag is not included in the evernote-backup export and is the only structurally meaningful difference between these 2 files. I don't see why UpNote would need it, but see if it makes UpNote choke if you remove it from the (otherwise functioning) manually generated enex.

I have a hypothesis that somehow the problem is caused by flaws in UpNote's matching of the <resources> in the enex file (in your case the images, all somehow named image.png by the way) with their corresponding locations (as <en-media> tags inside the note's <content>. I may or may not be right about that. But a starting point for how this is supposed to work is at https://discussion.evernote.com/forums/topic/146906-how-does-evernote-map-the-image-resources-in-enex-file/ and https://dev.evernote.com/doc/articles/enml.php

[Tone2608]

Thanks so much Houska1 for the detailed comments and ideas you provided. Unfortunately it is kinda over my head to deal with XML code, so I have opened a case with UpNote Support to have them take a look. If they provide a solution, I will comment here on this thread. Otherwise, hoping the evernote-backup devs will offer their thoughts.

[Tone2608]

So it turns out this was a bug in the software I was using UpNote and NOT evernote-backup. The developer of UpNote has informed me it will be resolved in their next build release. Special thanks to @Houska1 for pointing me in the right direction!