Inability to IMPORT ISBN13 records

I have recently performed a rather exhaustive attempt to import records which only have ISBN13 chars. Is this a known limitation of the import system?

>1 JoeB1934:

Not being LibraryThing staff, but knowing something about debugging, can you give more details? What you tried to import, how you tried to import it, how it failed? Also, computer, OS version, ideally the text encoding of the import, source of the data.

Have you looked at the data yourself to look for oddities, or did you just take it from somewhere?

I am sure all details will be appreciated.

>2 waltzmn: Can I attach files to my post? If so, I can attach the libby file with title, author, and ISBNs.

I can also attach the Goodreads export after the libby file was successfully imported.

I did two attempts in LT. First, just using the libby file. Second the import of the GR export.

The complete exercise I did before this post is contained in 'How to import an ebook'. Which is in Frequently asked questions.

First off, yes, Librarything does handle ISBN13. Most books only come with ISBN13 now.

What it sounds like it that your import file is incorrectly formatted and is being rejected. It MUST match the headers in the same file EXACTLY. Did you edit the libby export file to match the \ sample import file, removing all extraneous columns and data?

GoodReads is different in that they've built a specific import protocol for that platform to import here. They did not build that platform for Libby.

If this was done correctly, then I have to ask what sources were you using to import, because it might be the sources were rejecting your ISBNs.

>4 gilroy: I agree that LT does handle ISBN13, but I am trying to show that as part of the IMPORT process something is missing. Yes, I did properly format what I call the Libby import file. In an effort to display the problem I did an import of the file into an empty LT library (JFBCore), as well as my total library.

The total import file has 146 books and there were four books added to the empty library. All other books were labeled as not found.

EXAMPLE OF 4 BOOKS NOT FOUND Notice that LT attempts to find a book with 10 chars similar to the 13 char ISBN, but dropping the 978 leading chars
This is simply an example of the total books not found, which numbered about 140

TITLE' AUTHOR (last,first)-----------------ISBN' in File--------------------------LT ISBN Searching For
The Secret History Tartt, Donna------------9780060786472---------------------0060786477
The Round House Erdrich, Louise----------9780062204943---------------------0062204947
Arthur & George Barnes, Julian--------------9780307264664-------------------0307264661
Black Water Rising Locke, Attica-------------9780061901898--------------------006190189X

EXAMPLE OF 4 BOOKS FOUND Notice that the GHOST Walker is a 10 char ISBN in the file. I have no idea how the other 3 books were found
These are the ONLY books added to the library.

Title Author ----------------------------------------------ISBN' in File------------------------LT ISBN for Book found
The House At Sea's End Griffiths, Elly--------------------9780547506968
Origin a novel Brown, Dan------------------------------ 9780739319307------------------- 739319302
The Shadow of the Wind Ruiz Zafón, Carlos------------ 9780786558186------------------- 786558180
THE GHOST WALKER Coel, Margaret--------------------- 1596071826----------------------- 1596071826

If the LibraryThing staff want to pursue this I will be happy to send the relevant import file and they can reproduce these results, or show in what way the import file needs to be altered.

I apologize for the very rough table outlines as I don't know how to format this post accurately

To add insult to injury Goodreads imports all of these records from the same Libby file with field titles as they require.

Good to see you ignore my last question.
What sources did you use?

>6 gilroy: looking at the JFBCore Library, it looks like the options included

• Amazon.com books
• Milwaukee County Federated Library System (Wisconsin)

which don't seem to show a result for three of those (amazon shows one)

>6 gilroy: Amazon, Overcat, Brooklyn Public Library

I added BPL because most of my libby books came from there

>7 IrrationalDM: I didn't in any of my experiments use Milwaukee.

However, using the field tags required by Goodreads, which only uses Amazon all books, but one were imported successfully.

Would someone please explain the reason why the LT is doing searches for funny 10 char ISBN when the import is actually 13 char ISBN.?

And the odd 10 chars seem to be built from 9 of the 13 chars with an added single char

>10 JoeB1934: ISBN-10 can be converted to ISBN-13 by prepending 978 and recalculating the checksum i.e. the last digit. You can reverse the process as well (as long as the ISBN-13 starts with 978). The ISBN's in your examples are the equivalent of each other. Either of these may be used in records.

I spot checked some of your examples. Overcat finds them fine with either ISBN. Amazon.com didn't, but noticeably these were all audio books which Amazon does not list by ISBN.

After this discussion I decided to summarize it all by clearing out JFBCore and doing a series of imports. I assume anyone can look at that library.

I have two different import possibilities.

First is the original Libby reading file that started this exercise.

Second is a Goodreads export of the books from the Libby file after importing into GR. GR successfully imported the libby file in its entirety. For your interest the stats in the GR export are as follows:
88 Books have 10 char ISBN and 13 char ISBN
16 Books have no ISBN values
42 Books have only 13 char ISBN
146 Books Total

If I import this file into the Wishlist collection of the blank library the result is:
22 Books with no ISBN
2 Books with 13 char ISBN
97 Books with 10 char ISBN
121 Books Total all tagged as Libby using Goodreads Export

I used Amazon,Overcat,Library of Congress for this. Since GR uses Amazon, by definition, why not a match.

Then I did another import into LT using the same original Libby file as for GR except I used the prescribed field names for LT

The import screen says:
Books in file 146
Books already in your library 67
Valid ISBN's 146

I placed this import into the To read Collection and said to import duplicates again to get everything.
I also placed a tag in each book imported as Libby original file with LT field names.

In spite of these promising stats the actual result was only 5 books imported into To reads.

I really want an explanation so I can look forward to more confidence with outcomes in LT imports.

A separate point that deserves an RSI is the content of the LT import page. It is simply pathetic with the lack of important details. Like what is the title, author and ISBN of the import record being analyzed.

I had to do character searching in the import file to find what book was included in the 10 char search. I would also like to stay on the import page when the import was initiated, while adding stats to the progress. Do I need to say GR does this reasonably well?

>1 JoeB1934: I'm seeing a bunch of imports to both your JFBCore and JoeB1934 accounts in the last few days. I see that you used helpful tags for most of them, so let's review a few:

Looking at your JFBCore account

The 5/30 import with the tag, "From Libby in LT format": the import file only has the 'TITLE', 'AUTHOR (last, first)', and 'ISBN' columns. Your import file has to follow LT's custom .csv import file exactly, using the same name/order/spelling of the columns, no more and no less.

The 5/31 import with the tag, "Libby original file with LT field names": same issue as above but only with the 'TITLE', 'AUTHOR (first,last)', 'ISBN', and 'DATE READ' columns rather than LibraryThing's full .csv import file format.

The 5/31 import with the tag, "Libby using Goodreads Export", looks like it imported most of the records but the ones it missed (about 22 if I'm counting correctly) were not found in the data sources you selected (Amazon.com, Overcat, Library of Congress).

Looking at your JoeB1934 account

The most recent import attempt you made on 5/25 had the same issue as the first two examples above: you just need to follow LibraryThing's sample .csv file format exactly (essentially copying the top row and following the format). I hope this helps.

If you have further questions, I'm happy to troubleshoot with you. You can always send an email to info@librarything.com, as well. Just let me know.

(I'm not seeing any bugs here, so closing as not a bug.)

>15 kristilabrie: are you saying that i must have every field in the sample file as well as the order? i have always understanding about the names in the correct value and sequence.

what exactly is wrong with the 5/31 file? Must i have all of the fields?

Regardless of that LT proceeded to attempt to find the books and failed all the time using what seems to be unfindable 10 char ISBN. The 10 chars were all related to the related 13 char values.

With regard to the 5/31 import from GR all of the missed books have to exist in amazon because that is the only source they use.

I am in a doctor waiting room so I can't do all the checking I need to do, but please tell me exactly how my LT import field names I use are incorrect.

Yes, you must include all the columns

>16 JoeB1934: "are you saying that i must have every field in the sample file as well as the order? "

That is how Universal Import works.

Basically you have two options for import (outside of some migration cases like the GR import):
- List of ISBNs or a file with ISBNs inside of it (LT parses the file and submits all ISBNs to your configured sources)
- The Universal import which requires the file to have the specific format as defined in the example - no extra columns, no reordered columns, no missing columns.

>15 kristilabrie:
Wouldn't it make sense if the import just failed immediately if the column headers were wrong? Instead of running anyway and leaving the user wondering why things didn't work right?

>19 r.orrison: How would the importer differentiate between a badly formatted file for the Universal Import based on the sample (which needs to be thrown away and rejected outright) and a file which needs parsing for ISBNs? The latter can look like a badly formatted version of the first easily enough without you actually trying for it.

>20 AnnieMod: Good question. Maybe have two separate importers (or at least two interfaces for the importer) - one for structured data that checks that the structure is correct, and one for unstructured data that's only parsed for ISBNs? That way if you're intending to be importing a CSV file with meaningful columns, you'll be told if the columns aren't right.

>21 r.orrison: Or a checkbox "import as is" or something like that which will always just import whatever is in the file and bypass the ISBN lookups (thus even allowing ISBNs in the file)... If not checked, it does what it does now (parse of ISBNs or try the universal import way). If checked, it verifies that the file is the expected format and imports as is (ISBNs and all) and just rejects it if the format is wrong.

That will mean that for most people nothing will change but for the ones that want better control, they can now have it.

>22 AnnieMod: Agreed. We need a way to import a .csv with ISBNs that doesn't trigger ISBN lookups - I often have major corrections from the ISBN lookup result in an export file, and it's really pointless to have to *delete* the ISBN to get the correct data to import.

A separate .csv and goodreads import that uses the required columns (and fails with other formats) and a "we will import all detectable ISBNs" in a variety of text-parseable formats seems like a good solution that wouldn't require a huge overhaul.

LibraryThing admin has elected to close out my reported bug, with the explanation that I used an incorrect import format file structure. I performed a series of imports to test that concept and will report on that below.

Before doing so, I finally realized that, in a major sense it isn’t a bug. To revive an old saw from my 40 years' experience in software development days “That isn’t a bug, it’s a feature”.

The LT developers have chosen their method for validating the ISBN values by determining it to be present in at least one of the myriads of library records. The fact that my import ISBN list can all be confirmed by doing a Google search is neither here, nor there. LT doesn’t do it that way.

By providing a way to avoid this through the blank ISBN approach they have legitimately placed the burden on me to fill in the missing ISBN values manually.
Now, on to my series of import experiments. The table below summarizes that analysis.

Import Method Number of books matched
(1) Libby Export File (the original source) 153
(2) Import of Libby file using complete Sample format 110
(3) Import of Libby file using only Title,Author,ISBN 97
(4) Import of libby file into Goodreads using T/A/I 146
(5) Import of total GR export file into LibraryThing 132

With these results in mind, in the future I will the method (4) and (5) to minimize the amount of manual ISBN format I need to do.

My last comment is a plea for an improved LT report on the failure to find a match. I have presented this as a requested RSI. Does this error information help you at all? It sure is inadequate for me.

Lookup queue
You have 64 ISBNs in your lookup queue, including 64 failed and 0 active. (clear queue)
Finishing estimate: between 10 minutes and 20 minutes.
ISBN: 0062987712 failed
ISBN: 0062987712 failed
ISBN: 006300335X failed

Now I will return to what I value most about LibraryThing, which is the chance to find and discuss books with many other members.
Do any of you want to recommend a book to read? Of course, my TBR list is already huge.

>19 r.orrison: It would make sense if we could add better messaging throughout the import process, yes, we're aware of its limitations.

>20 AnnieMod: How would the importer differentiate between a badly formatted file for the Universal Import based on the sample (which needs to be thrown away and rejected outright) and a file which needs parsing for ISBNs?
Another idea just came to me: How about after quickly checking just the first row of the file, if the headers don't match ask the user if they want to search the file for ISBNs?
E.g. "The submitted file is not a correctly formatted CSV file for full data import. Do you want to search the file for ISBNs and do the import solely on the basis of any ISBNs found in the file?" (If that's how it works.)