Home / GitHub Page

Enex import log

I’m trying to write a python script that will generate a valid enex file. When I try to import the .enex file it creates, joplin creates a notebook having the filename of the enex file I imported, but tells me “No notes in here”. Is there a log created somewhere that might have some diagnostic information about the import attempt?

Should have provided some context:
Ubuntu Pop!_OS 19.04 GNOME 3.32.2 Joplin 1.0.160

new data:

The import attempt results in perpetual “please wait” screen. Quit and restart sometimes restores but not always. Sometimes I have to get rid of the two files described below before I can return to normal operation. Some useful error messages? A log somewhere?

... .config/Joplin$ file Singleton*
SingletonCookie: broken symbolic link to 12156505047090017206
SingletonLock:   broken symbolic link to herodotus-18703

You can see the info about debugging here specifically about using the command line flag --open-dev-tools when opening the application, if there is going to be useful debug output (for this issue) I would guess you’ll see it there.

1 Like

Many thanks @CalebJohn! This is very helpful to know. I’m still pretty unfamiliar with Joplin and have still a lot to learn. Now though, I’ve got some feedback. If only I understood what it means!

In trying to debug my python script I’m comparing an enex file, star.enex, which is an xml export file generated by EverNote. willietest.enex is generated by my script. Joplin imports the former successfully and fails on the latter with the error included below. willietest.enex validates against EN enex dtd, the base64 strings decode to the images I expect; nevertheless, something there is that doesn’t love this file.

(I don’t know what the protocol of this forum is with respect to uploaded files. The two I’ve mentioned are small (less than 500kb each), contain no sensitive information, and can be provided in the unlikely event that someone is interested in my little problem.)

Note that the import mechanism correctly parses the CData section of the incoming html, and correctly generates the equivalent MD. But the end result is that the sqlite db gags on what it’s given, but I haven’t yet figured out what it is that tastes bad.

Any hints or observations would be welcome.

/tmp/.mount_JoplinwuJ1E9/resources/app/lib/import-enex.js:260 Error: Error: SQLITE_CONSTRAINT: NOT NULL constraint failed: notes.updated_time: INSERT INTO `notes` (`id`, `parent_id`, `title`, `body`, `updated_time`, `source`, `source_application`, `created_time`, `user_created_time`, `user_updated_time`) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?): 38a88c203f7b4f499eff0a32f7f641fd,39e3219b3dd64ad18b02342ad04d3a5b,
   Here awa Willie
  ,Music > Tunes > Here awa Willie - Dec 23, 2015, Dec 23, 10:24:35 AM

[Here awa Willie - The Traditional Tune Archive](http://tunearch.org/wiki/Here_awa_Willie)

[](:/ac4dc7bfface47d0b3c515518aaee481)[](:/6f2bd702be542f87eb225f861fee6e7d)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Found in Google Books:

**The World's Best Music: Famous Songs and Those who Made Them, Volume 4 **

 By Helen Kendrick Johnson, Frederic Dean, Reginald De Koven, Gerrit Smith

[](:/bcae40e843a687d2635e363ebf018be9)

http://digital.nls.uk/special-collections-of-printed-music/pageturner.cfm?id=94598516,NaN,joplin-desktop,net.cozic.joplin-desktop,1565307661082,1565307661082,1565307661082
    at DatabaseDriverNode.sqliteErrorToJsError (/tmp/.mount_JoplinwuJ1E9/resources/app/lib/database-driver-node.js:22)
    at JoplinDatabase.sqliteErrorToJsError (/tmp/.mount_JoplinwuJ1E9/resources/app/lib/database.js:26)
    at JoplinDatabase.tryCall (/tmp/.mount_JoplinwuJ1E9/resources/app/lib/database.js:89)
    at process._tickCallback (internal/process/next_tick.js:68)
processNotes @ /tmp/.mount_JoplinwuJ1E9/resources/app/lib/import-enex.js:260
_tickCallback @ internal/process/next_tick.js:68
async function (async)
processNotes @ /tmp/.mount_JoplinwuJ1E9/resources/app/lib/import-enex.js:230
setInterval @ /tmp/.mount_JoplinwuJ1E9/resources/app/lib/import-enex.js:435
setInterval (async)
(anonymous) @ /tmp/.mount_JoplinwuJ1E9/resources/app/lib/import-enex.js:434
emit @ events.js:182
SAXStream._parser.onend @ /tmp/.mount_JoplinwuJ1E9/resources/app/node_modules/sax/lib/sax.js:190
emit @ /tmp/.mount_JoplinwuJ1E9/resources/app/node_modules/sax/lib/sax.js:624
end @ /tmp/.mount_JoplinwuJ1E9/resources/app/node_modules/sax/lib/sax.js:667
end @ /tmp/.mount_JoplinwuJ1E9/resources/app/node_modules/sax/lib/sax.js:154
SAXStream.end @ /tmp/.mount_JoplinwuJ1E9/resources/app/node_modules/sax/lib/sax.js:248
onend @ _stream_readable.js:628
onceWrapper @ events.js:273
emit @ events.js:187
endReadableNT @ _stream_readable.js:1092
_tickCallback @ internal/process/next_tick.js:63

The error makes it look like note.updated_time is null.

Here is a relevant bit of import code

if (!note.updated_time) note.updated_time = note.created_time;

So it seems that something is not set properly in your enex (either updated_time or created_time).

Again, thank you @CalebJohn for your invaluable hints. Some progress. Adding the created and updated elements to my xml did the trick. Joplin does not expect all the available elements in the enex dtd, but I’ve yet to find any documentation that describes what the minimum required set of elements is. With the addition of those two, the note is successfully imported. The new problem (for which I’ll compose a new query) is that though the resources for the note are imported, they are stored in the resources directory without their appropriate file extension, the markdown includes no filename, and the resources are thus rendered from the md with just a “J” icon.

Two steps forward, one step back. Thanks for your help.
J

The problem with enex import is that Evernote doesn’t really supply a spec (because it’s a proprietary format), my understanding is that the Joplin importer was created by basically trial and error with bug fixes as people with strange notes popped up on the forum. Point being that there is no riggorus documentation for the importer because it’s not really possible (given the Evernote side of things) and not that useful to most people that are only using it to import. You are a very special case in that you’re trying to create enex files using some form of Joplin spec.

Is there a reason that you’re trying to use enex specifically? Because Joplin supports other import formats, notably jex, which are easier to work with.

If you can’t change formats then I recommend you read the Joplin enex import code in lieu of a spec.

As before, thank you for taking an interest. XML has never been for me anything other than a pain in the neck. I’d rather work with almost any other data format. jex looks ideal, but unfortunately my use case is like this:

I’ve just recently escaped from Apple to linux, after long years of bondage. Much about the Mac I will not miss, but some things, very much so. I used DevonThink for a number of years and have a lot of data bound up in it. Joplin seemed to be the ideal thing to switch to, but how to get from one to the other? Devon products are wholeheartedly apple-centric.

DT is a powerful program and you can throw almost anything at it and it won’t complain: midi files, pdfs, URLs, webarchives, text, image, video, you name it. What makes this possible is some kinda database (with “AI” (woo woo!)), and RTFD which is, unfortunately, very much a mac thing, but nevertheless a good idea. The version of DT that I have (I’m reluctant to pay $80 for an upgrade) supports export as some sort of db dump, RTF and RTFD documents, webarchives (another apple thing), and as “website”. The last seemed most approachable. DT stores the resources it finds in the same folder with an html file for each note. The html renders the record as best it can, often not very well. However, I knew I could scrape the html with python’s BeautifulSoup, and base64 encode the remaining resources. enex seemed to support this use case and there is a public dtd for it.

Your mention of jex suggests adding yet another step: figuring out turndown and turning the html into markdown first, but I’m reluctant to add another step and mindful of my “sunk costs” so far in this doomed enex approach. If anyone has any other options, suggestions, observations, I sure would love to hear about it, because even if I can make this work, it will still be less than satisfactory