I recently purchased an android phone, and was excited to see an android app that ostensibly would sync with my calibre library through the web service that's built into calibre. For readers' edification, this is the app:https://market.android.com/details?i...breLibrary.apk

The app performs very well, syncing just fine, with minimal setup, with calibre...with one little problem: it would only show .epub, .pdf, and a few other lesser formats. This was dismaying to me because I am a kindle owner, and the vast majority of my 1000+ ebooks are in .mobi format. After much back and forth with the app's author, basically, it came down to this, according to him:

Understand, I am NOT trying to get any of the authors here to do the guy's work for him, I'm simply asking if he's correct in that statement. If he is, is there a good reason that calibre doesn't include other formats in the xml push? I'm asking as a layperson with no knowledge, so if someone tells me that there is a good reason, I'll accept it and move on. I'm hoping, however, that it's a legacy issue that might be updated in a future release.

To be clear, I'm just wondering if, and or why, the xml push doesn't include the other formats. It clearly DOES include them in some other manner, because they show up just fine in any web browser used to access the server.

If kovid or someone other developer thinks it would be helpful to see the emails, I'd be happy to provide them, or open a ticket if one of you thinks it would be helpful.

Steps I took to confirm various aspects of my post, here:

1. I used calibre's built-in test function (in the web server section) to ensure that, in fact, all of my books are being pushed, including .mobi and .epubs. There were, of course.

2. I checked that this was so in my android's browser. It was so.

3. I tested the app author's statement that his app was showing the xml scrape that calibre is putting out, by going to http://server:8080/stanza/ in my browser, where server is my local access to it. He was correct, the stanza server was only displaying epubs et al.

I feel compelled to say that the more I think about this, the more I begin to think that this is a case of the app author simply being unwilling to do the work necessary to pull ALL of the information that calibre is pushing -- because clearly, calibre is doing IT'S job within the webserver, by serving up all formats for perusal.

I'll leave my post up, however. Perhaps it will engender a good answer for someone else trying to write such an app.

3. I tested the app author's statement that his app was showing the xml scrape that calibre is putting out, by going to http://server:8080/stanza/ in my browser, where server is my local access to it. He was correct, the stanza server was only displaying epubs et al.

Stanza is a epub viewer thus the epub scrape for stanza. Maybe the app developer should develop using http://server:8080/mobile instead.

Stanza is a epub viewer thus the epub scrape for stanza. Maybe the app developer should develop using http://server:8080/mobile instead.

Which is what I mean when I say that this is a case of, perhaps, the guy not having the time or desire to pull all the data...which is unfortunate for him, because he's limiting half his potential market. Without wanting to start a format war...there's lots and lots of kindle users.

Ah, well.

Edit:

In his defense, that's not an actual access address, so I don't know that it's quite THAT simple.

Which is what I mean when I say that this is a case of, perhaps, the guy not having the time or desire to pull all the data...which is unfortunate for him, because he's limiting half his potential market. Without wanting to start a format war...there's lots and lots of kindle users.

Alternatively you could do a bulk mobi to epub conversion and have both formats in your library.

Alternatively you could do a bulk mobi to epub conversion and have both formats in your library.

ehhhh...with one library @ 1.04gb and the other at over 3gb...doubling the sizes of them is not something I want to do...particularly for no other reason than to go onto my phone...even with a 32gb micro sd card.

It just seems to me that a well-written app would take this into account. The information is THERE...it just needs be scraped. It makes me wish I was a developer because lo...here's an unaddressed niche...

I get enough income from calibre, and I like to write powerful software, that is likely to remain useful for decades. Mobile phone apps just dont fit the bill.

Ah, well...I certainly think you've hit the target with calibre. I was thinking just that earlier when I was reading the 'when will you convert to python 3' thread. People were discussing timelines of 5-10 years, and I thought, "Yeah...I'll be using calibre that long."

I wasn't aware of the OPDS address in Calibre when I wrote the app - and being a nook / epub user I never really cared lol, but you should know even the opds display doesn't show .LIT files for some reason...

I've sent gweminence (well I assume you're the one I've been emailing with since midnight last night ;-) a test build that uses the opds interface to see if it works for him.

The reason the lit file shows is because OPDS is offering the thumbnail. It's not actually providing the link to the .lit file. My app sees that something is offered, displays the thumbnail but unfortunately didn't realize there was no actual download link so the download button craps out.

And really, most of the props should go to Kovid - he did all the hard work!