Using Overdrive for covers?

[ldolse]

It wasn't something I was figuring would be ready immediately anyway, still a fair bit of cleanup to do.

I noticed you're making progress in trunk on the metadata infrastructure modifications, one of my next steps was to figure out how to tie this in with the generic identifiers you've just added to trunk - I assume this was the field you were planning to use for ASIN, ReserveID, and other platform specific identifiers.

[Starson17]

Originally Posted by ldolse

apparently this website is fairly unique in it's ability to trip up mechanize, because none delete cookies or manipulate them the way I'm trying to do.

I've been reading your posts, and what you were doing didn't quite seem to match up with what I'd seen done in the recipe code. That's why I started with "I don't know if you will find it to be of any value." Still, I thought there might be something there you could use.

[kovidgoyal]

Yes, the identifiers table will be used for all identifiers in the future, including ISBN

[ldolse]

I started looking at tying in the title/author cleanup functions we discussed earlier - I don't see how to import those functions while metadata.sources.base isn't actually integrated into the codebase. Tried creating a separate class just to call the generic functions in the plugin, but it wants a variable set of arguments to initialize the Source() class that have nothing to do with just passing title/author over for cleanup, and seem to only be setup to be passed from metadata.sources.test at the present time...

Is there a quick and dirty way to just get those functions imported to my plugin, or do I need to duplicate the code until the new framework is ready? ( I suppose another option might be to move them outside of the class definition in metadata.sources.base)

[kovidgoyal]

from calibre.ebooks.metadata.sources.base import MetadataSource

s = MetadataSource(None)

Now just use the methods of s like you would any other class

[ldolse]

Didn't realize it was as easy as passing 'None' - very cool.

I just started playing with the functions - I notice they strip periods from authors/titlenames - was this done because periods specifically misbehave with some services? I would think that most services should be able to handle them, and in some cases expect them - Overdrive seemed to expect them as an example - the search returned no results when they were stripped.

I don't feel particularly strongly either way with regard to stripping/them them, just curious. I'm thinking maybe the best approach would be to trust the original input at first, and only try normalizing it if there's a failure/lack of returned results.

[kovidgoyal]

I don't feel particularly strongly either way with regard to stripping/them them, just curious. I'm thinking maybe the best approach would be to trust the original input at first, and only try normalizing it if there's a failure/lack of returned results.

That would be slow. Are you saying overdrive needs periods in the title or in the author tokens? You can change it to strip trailing periods, instead. That should take care of it.

[ldolse]

Overdrive needs periods in author initials.

J. R. R. Tolkien returns results.

J R R Tolkien returns nothing.

I'll change it to remove trailing periods, that will probably be fine - will test some 'Jr.' examples to see if that makes difference, but common abbreviations are probably something that makes sense to strip from the list of tokens anyway.

[kovidgoyal]

Wait, IIRC the current code remove initials so an author value of J. R. R. Tolkien will return only the token "Tolkien"

[ldolse]

It didn't do that - I had it printing out debug statements to see exactly how it cleansed it - it created an iterable something along the lines of [J, R, R, Tolkien].

I can definitely get in line with Stripping out single character initials completely if you want I'll include that in the other modifications - that would help for the cases where an AND search gets tripped up because it expects 'J.R.R.' vs. 'J. R. R.'

[kovidgoyal]

Are you sure you're runinng from updated source, the relevant lines are

                    if len(tok) > 2 and tok.lower() not in ('von', ):
                        yield tok

Then length check means initials and most connectives are stripped out.

[ldolse]

Apparently it's not working - those lines are in my code, but here's the debug output I created which parses the iterable returned by get_author_tokens and then builds the query string:

author token is: J
author token is: R
author token is: R
author token is: Tolkien
final author query string is J+R+R+Tolkien

I haven't done any debugging of the function itself, was just getting it hooked into the plugin thus far.

[ldolse]

Is there any reason print statements won't work from inside ebooks.metadata.sources.base? Just added some to see what was going on and I'm not getting any output...

[kovidgoyal]

Make sure you are starting calibre as

calibre-debug -g

Other than that, there should be no problems.

[ldolse]

I'm not calling it from the GUI, calling the plugin directly from the CLI:
calibre-debug -e ./src/calibre/ebooks/metadata/overdrive.py

Print statements in the plugin are showing up fine, the ones added to the get_author_tokens function in ebooks.metadata.sources.base are the ones that aren't showing up for me...

Wasn't sure if it had something to do with passing 'None' as the only argument when referencing the class.