I POSTED THIS ON GITHUB 2 DAYS AGO, BUT HAVE NOT YET RECEIVED A REPLY, SO I'M POSTING ON THE JOPLIN WIKI:
Name of github post: Import of Evernote #8843
I am trying to import an Evernote enex file containing about 6000 notes, but the import stops when it gets to 2964. I have run the import twice, and each time had the same problem.
Environment:
Joplin version: 2.12.15 (prod, darwin)
Platform: Macbook Pro (macOS)
OS specifics: Ventura 13.5.1
Steps to reproduce:
1. Open Joplin
2. Click File/ Import/ ENEX - Evernote Export File (as Markdown)
3. Select .enex file of cheeg notebook that was exported from Evernote on 8/5/23.
4. Import begins, import screen says: Importing from "users/cheeg/Library/CloudStorage/OneDrive-JPL/Desktop/Evernotes Backup, 8:5:23/cheeg's notebook, 8:5:23 export, EN XML format.enex" as "enex format. Please wait...
5. Import screen shows values labeled loaded, created, updated, skipped, resourcesCreated and notesTagged, that increment as the import proceeds. When the "loaded" and "created" values get to 2964, I get the circling icon that indicates it's still working on the import, but nothing happens. Eventually (after 10 minutes or more), I try to close Joplin, but it won't close until I do a "Force Quit" operation.
'
Describe what you expected to happen:
I expected the import operation to continue until it said loaded: 5738, and then the import operation should end. I was able to successfully import a smaller notebook with 268 notes, and that's what happened when the import was finished.
I also attached the requested logfile to github report, but I don't see any way to do that on this wiki.
If you see something I'm doing wrong, please email me at casey.heeg@jpl.nasa.gov, or respond below. Thanks!
I don't assume you can share that file with 6000 notes? As often the issue is that if we cannot replicate it, it's very hard to figure out what might be the issue.
Thanks Laurent,
It looks like the note that's causing the import to stick is one called "Piega Speakers", but I'm not sure how to fix it. Here is the error message:
MenuBar.tsx:269 Error: "Piega Speakers": This resource was not added because it has no ID or no content: {"id":"d41d8cd98f00b204e9800998ecf8427e","dataFilePath":"/Users/cheeg/.config/joplin-desktop/tmp/
Did you have a chance to look at the logfile I uploaded to github? After the error I copied above, there is a lot more, but it's very hard to decipher.
PS: unfortunately, I can't share the file with 6000 notes, as many of them are confidential (which is why I'm seething with rage at Evernote for locking me out of my account!)
Also, I have not tried v13 yet, but will when I have some time. I'll let you know tomorrow if any good comes from it. Thanks again!
Hi Laurent,
I don't know if this is progress, but it's something. I opened up the enex file in a text editor, and located the note "Piega Speakers". I wasn't sure where the html entries before and after the note began and ended, but I took my best guess and deleted it, then saved it as a new file. I then tried to import that file into Joplin, and instead of stalling at 2964 notes, it stalled at 2961. Hopefully, this will tell you something useful, other than that I don't know what I'm doing...
I have observed two problems which result in similar hangs.
In ENEX files, Evernote generates items which contain:
<![CDATA[photoname.jpg]]></en-note>
I don't know if this is invalid code generated by Evernote, or if it is a problem in Joplin, but these always fail during import to Joplin. Changing these items to the following fixes the problem:
photoname.jpg</en-note>
When importing a large number of notes, Joplin seems to hang at various points. This only seems to happen with a large number of notes and it seems to be related to the position of notes within the ENEX file. I see it happen every 2000-5000 notes. I have not been able to produce a small example of the failure. I have been able to work around this by splitting the ENEX file after the last note that is properly imported, so it does not seem to be related to the format of a single note. I suspect there is some issue with the way the input data is buffered.
In my 75,000 Evernote ENEX file, I found about 90 examples of this format. I don't understand XML well enough to figure out if this is invalid or not. But Joplin would fail on each of these.
The fix in #8699 allowed Joplin to continue processing when it ran into this error instead of hanging. But the change I mention above allows Joplin to import the note correctly.
As I said, I don't know if this is a problem in Evernote or a problem in Joplin.
Thanks for the responses, @bgoodmansf ! I think you hit the nail on the head, regarding the failure of my import at a note which was trying to attach a screenshot. I will try your fix this weekend, and let you know how it goes. BTW, the problem of stalling the import at about the 3000th note DOES seem to occur in Evernote too (at a different # note, but close), not just Joplin, I exchanged email with a tech support person at Evernote, who said this has been a recurring problem with files that have a large number of notes, and they are working on solving. it (don't hold your breath!) Content removed from original enex file.txt (27.8 KB)
. He also suggested breaking my notebook into several smaller ones, and exporting them separately. If your fix doesn't work, I'll try that.
Laurent, thanks for getting back to me; attached is a text file of the note I was talking about,which seems to be the place where the import got stuck. It does have the following message at the start of the Content section: <![CDATA[<?xml version="1.0" encoding="UTF-8" standalone="no"?>
I'm not sure if that's referencing a screenshot of some other error source, but hopefully it will mean something to you.
@allysfay I don't think you're having problem #1 with the CDATA text. That problem occurs when a second CDATA term is specified in the note.
I put the proper beginning and ending for an ENEX file around your note clipping and it imports correctly now: ImportFix.zip (9.4 KB)
I suspect you may be having problem #2 which is probably related to the position of the note within the ENEX file. This is a much harder problem to debug.