Update 1: I'm honored that by default I see a duplicate of my Sony layout, except it looks a lot better on my Nexus 7 with the thumb nails of my books next to each entry. It also allowed me to choose which of the 3 reading apps to use when opening the book to read. Excellent!

Update 1: I'm honored that by default I see a duplicate of my Sony layout, except it looks a lot better on my Nexus 7 with the thumb nails of my books next to each entry. It also allowed me to choose which of the 3 reading apps to use when opening the book to read. Excellent!

You might also notice that if you group by authors then sort by series, you will have something very close to what you described in this post, a list of books by an author ordered by series & series index.

You might also notice that if you group by authors then sort by series, you will have something very close to what you described in this post, a list of books by an author ordered by series & series index.

One item that I noticed is that unlike my USB connected devices, tags surrounded by brackets [] are sent to my Android device.

I was going to test at work and then realized that our University LAN isn't going to allow me to do this. When I get off work I'll setup the proper port forwarding so I can connect to my home machine for further testing.

One item that I noticed is that unlike my USB connected devices, tags surrounded by brackets [] are sent to my Android device.

Interesting point. We want to make the guarantee that you see the same metadata on the device as on calibre, which is why there is no tag processing. Should we make an exception in this case and remove the bracketed tags (this would be in the app)? Does leaving the tag in the group list actually hurt anything?

Quote:

I was going to test at work and then realized that our University LAN isn't going to allow me to do this. When I get off work I'll setup the proper port forwarding so I can connect to my home machine for further testing.

This will be an good test. I assume you will use some dynamic dns service. We will find out whether the app's name resolution works.

Question: what is the use case? If you connect from work, you won't be able to talk to calibre at home unless you have very long arms. Are you connecting to see if you can, to download news, or do you have something else in mind?

Interesting point. We want to make the guarantee that you see the same metadata on the device as on calibre, which is why there is no tag processing. Should we make an exception in this case and remove the bracketed tags (this would be in the app)? Does leaving the tag in the group list actually hurt anything?

It doesn't hurt anything. I was just pointing out that bracketed tags are being sent to the device. The reason bracketed tags exist is so folks can mark books in the tag area and not have those tags clutter their ereader's collection area. It doesn't bother me. I had 2 bracketed tags indicating books that were on my son and daughter's devices. Possibly some folks use them extensively, but this is not a deal breaker for me.

Quote:

Originally Posted by chaley

This will be an good test. I assume you will use some dynamic dns service. We will find out whether the app's name resolution works.

I was going to use the raw IP number, but I do have a dynamic dns service setup for my NAS so it will be simple to tack a port onto it and see if it works.

Quote:

Originally Posted by chaley

Question: what is the use case? If you connect from work, you won't be able to talk to calibre at home unless you have very long arms.

I have no use case in mind. I was just going to see if it could connect and transfer books using my very long arms to control calibre at my house. I'm not interested enough to bother with remote access so I think I'll pass.

Quote:

Originally Posted by chaley

Are you connecting to see if you can, to download news, or do you have something else in mind?

I have no use case in mind. I was just going to see if it could connect and transfer books using my very long arms to control calibre at my house. I'm not interested enough to bother with remote access so I think I'll pass.

This brings up another question. Kovid mentioned that it would be nice somehow to start transfers from the device instead of from calibre. I can see how to do this technically, but the user interface parts are complicated. I can also see why people would want this. They have presumably figured out how to turn on the driver, and it would integrate very nicely with browsing the on-device book collection.

One way to do it would be using the to-come content server interface. You could browse your books using the same interface the app presents for books on the device (to the extent possible), select, and download books. We would support (somehow) an ondevice indication. The advantage of this solution is that the content server exists and is made for this purpose. The disadvantage is that the content server expects page-oriented fetches, where our UI really requires having all the information in hand before we display anything. We can of course have two UIs, but that is not an optimal solution.

Another way to do this would be to permit you to talk to calibre over the device interface instead of the content server. The problem I have is to decide how it works. It is easy to imagine adding the equivalent of calibre's "in library" to our UI -- some sort of checkmark on the display. The more interesting question is showing books that are in the library but not on the device. We would need to show both OnDevice and InLibrary, which isn't hard but will take some thought. However, do you see a list of *all* the books in your library? Does it support searching? Does our grouping interface work? Is any of this possible with reasonable performance?

I think we could make the performance reasonable if we limit the number of books we will show, and let you (force you, perhaps) to make a search to respect that limit. We would also probably be required to use a reduced metadata set such as title, author, tags, series; and no cover thumbnails. We certainly don't want to send full metadata for 20,000 books. The first problem is transfer time, and the second is local storage to manipulate the information.

Any thoughts? Would accessing calibre when connected as a device be useful? Or is the content server sufficient?

Hello,
I installed Calibre Companion on my Galaxy Tab 7.7 but it never gets past the "Syncing with calibre, Updating booklist and metadata" page. The IP address and post is correct - I can open the library easily on two other computers over that address.

I have around 600 books in calibre - should it take more than 10 minutes to synchronise?
I'm using Mac OSX and version 0.8.64 of calibre.

Hello,
I installed Calibre Companion on my Galaxy Tab 7.7 but it never gets past the "Syncing with calibre, Updating booklist and metadata" page. The IP address and post is correct - I can open the library easily on two other computers over that address.

I have around 600 books in calibre - should it take more than 10 minutes to synchronise?
I'm using Mac OSX and version 0.8.64 of calibre.

Many thanks!

First, the time to sync depends on the number of books on your Tab, which in this case is zero. The connection startup negotiation should finish in seconds. The number of books in your library doesn't affect this.

Now to the problem: You say that the IP and port are correct and that you can open the library with other computers.

First question: when you connect with other computers, what are you connecting to? Calibre's content server?

Second: why did you enter an IP address in the app? Doing so is normally unnecessary. If, however, you have one of the wireless routers that blocks multicast or if you have a firewall on your computer that blocks access port-by-port, then you will need to enter the address and port.

Third: assuming it doesn't work when you enter nothing in the IP box, what port did you use? It must not be the port of the content server. Instead, it should be the port you see in calibre's Smartdevice plugin customization panel. By default, the smartdevice driver uses a random port number. To use a fixed port you must change values in device customization. In calibre, go to the device customization panel for the Smartdevice driver (Preferences -> plugins -> Device interface plugins -> Smartdevice app interface). Check the box "Use a fixed network port". This screenshot shows you the device customization dialog.
Change the default port number (9090) if you wish. Note down the port number you use. Be sure that the port number in the app and in calibre are the same. Also be sure that your firewall is not blocking that port.

Fourth: assuming that the port numbers are the same and things are still not working, then we need to get some information by running calibre in debug mode. Start calibre, then click the small down arrow next to preferences as shown in this screenshot.
Click on "Start calibre in debug mode". Let calibre restart and answer OK to the dialog that confirms that calibre is in debug mode. Using your Tab, attempt to connect to calibre. Wait at least 30 seconds, then close calibre. You will get a window containing calibre's debug log. Post that debug log here. While you are looking at it, verify that smartdevice interface is starting and that it is using the port you assigned.

When I do these steps, I see the following log (this isn't all of it).

1)
Yes, I was connecting over the calibre content server on port 8888. I have port forwarding set up on my Airport Extreme router, and port 8888 is always forwarded to the MacBook running calibre.

2)
Regarding why I entered an IP address, I thought that when I saw the instruction to always enter a port number, it made sense to enter the IP address on which calibre is running. I use static IP addresses on my home network, so calibre will always be accessible on the same port.

3)
I followed your instructions in 3) above and set the SmartDevice App interface to port 8888 (and calibre's content server to 8877 instead). Then I restarted calibre in debug mode and got no connection (the IP address was removed as per your instruction). See the first debug log below.

4)
However, when I added the IP address as well as the SmartDevice App's port number, BINGO! I get the message "Device: SmartDevice detected".

It's working now, news that calibre has downloaded according to a schedule I set up is sent automatically and deleted from calibre, all per my wishes. The only difference now is that there are no wires! Purrrr-fect!

My girlfriend and I thank you very much for this wonderful program - now we'll be able to read ebooks with even less hassle than we currently do!

It's working now, news that calibre has downloaded according to a schedule I set up is sent automatically and deleted from calibre, all per my wishes. The only difference now is that there are no wires! Purrrr-fect!

My girlfriend and I thank you very much for this wonderful program - now we'll be able to read ebooks with even less hassle than we currently do!

Cheers,
Alan

Excellent. Glad you got it sorted.

I thought that you might have used the content server port because from your description the app clearly connected, but then just as clearly did nothing. The reason that nothing happened is that the app is passive, driven by calibre, while the content server is also passive, driven by the client. Both ends were waiting for the other end to do something that never happened. This will be common enough where we need to find a way in the app to detect connections to a passive somethings that don't speak the protocol. This needs some thought ...

If I could add a feature request, I would suggest allowing CC to sort books into separate folders by author name, as calibre already does, rather than lumping them all into the same folder.

Also, whenever CC is snychronising, it is too easy to click outside the onscreen white box, therefore cancelling the current operation in mid-flow. If there could be a 'cancel' button, but not just by clicking in the wrong spot, that might be a good too.

This brings up another question. Kovid mentioned that it would be nice somehow to start transfers from the device instead of from calibre.

I can see folks valuing this ability.

Quote:

Originally Posted by chaley

One way to do it would be using the to-come content server interface. You could browse your books using the same interface the app presents for books on the device (to the extent possible), select, and download books. We would support (somehow) an ondevice indication. The advantage of this solution is that the content server exists and is made for this purpose.

The fact that the content server exists is a big plus. Two UIs wouldn't have to be a bad thing if clearly labeled up front as to their function. One Button to enter Local connection a Second button to enter Mobile connection. The mobile connection could be setup to access the Calibre content server and possibly public OPDS catalogs such as Project Gutenberg, Feedbooks, Manybooks (see Moon+ Reader) or even have the ability to add your own catalog so folks could access their books via catalogs setup on their own NAS and not have to have a separate computer running calibre.

Quote:

Originally Posted by chaley

Another way to do this would be to permit you to talk to calibre over the device interface instead of the content server. The problem I have is to decide how it works. It is easy to imagine adding the equivalent of calibre's "in library" to our UI -- some sort of checkmark on the display. The more interesting question is showing books that are in the library but not on the device. We would need to show both OnDevice and InLibrary, which isn't hard but will take some thought. However, do you see a list of *all* the books in your library? Does it support searching? Does our grouping interface work? Is any of this possible with reasonable performance?

Good questions. If you could implement something along these lines I'm sure many folks would be very interested. But if you implemented a subset of what you could do with calibre locally, there would always be folks whining about what it can't do and why can't I do this and that... It might be a support nightmare. But it would certainly be a challenge.

Quote:

Originally Posted by chaley

Any thoughts? Would accessing calibre when connected as a device be useful? Or is the content server sufficient?

I think using the content server might be best. Any possible support nightmare would be limited by the fact that the content server is a different beast. If you gave it a decent front end with a nice search feature in addition to the new feature to get free books from public OPDS catalogs folks would be very happy. Even the folks that never use the content server would benefit from the possible PD books available. Maybe even have access to Mobileread from this Mobile connection view.

Feature suggestion: When I am in FBReader (not my reader of choice) and select a book I am presented with what essentially is a book jacket similar to what calibre allows you to insert into your book. First the book Cover, then Book Info (grabbed from the metadata) including Title, Author, Series, Series index, Tags, Language and Description. Following this is the path and name of the book as it sits on the Android device.

If you could insert a book jacket similar to this into what you have now, folks would go bananas. They are always looking for a better way to view book info prior to reading. You could eliminate the need for folks to insert books jackets or create catalogs.

If you presented this pseudo book jacket to the user after s/he selects a book, with navigation Read or Back buttons, this would greatly add value to your user. If they choose Read then you have the same pop-up that asks which reader they wish to use. If they choose Back you return them to where they were prior to selecting the book. I believe FBReader creates a temp file in cache to accomplish this feat.

Feature suggestion: When I am in FBReader (not my reader of choice) and select a book I am presented with what essentially is a book jacket similar to what calibre allows you to insert into your book. First the book Cover, then Book Info (grabbed from the metadata) including Title, Author, Series, Series index, Tags, Language and Description. Following this is the path and name of the book as it sits on the Android device.

If you could insert a book jacket similar to this into what you have now, folks would go bananas. They are always looking for a better way to view book info prior to reading. You could eliminate the need for folks to insert books jackets or create catalogs.

If you presented this pseudo book jacket to the user after s/he selects a book, with navigation Read or Back buttons, this would greatly add value to your user. If they choose Read then you have the same pop-up that asks which reader they wish to use. If they choose Back you return them to where they were prior to selecting the book. I believe FBReader creates a temp file in cache to accomplish this feat.

We are going to do something like this to show "full metadata". Introducing that view between the book list and opening the book is a good idea, avoiding any long-push vs short-push differences.

Another thing I want to do (but is low priority) is to have a way to remember which reader app to use for which format. I am not sure how this would work. Android might or might not be able to give us the list of possible apps (this is Steven's department ).

Started using this last night and I did hit one problem but it seemed to have been caused by my over-eagerness. With my other devices I'm used to transferring lots of books and I tend to scroll through the library, highlight a few, send to device, scroll, highlight a few more, send to device - which adds them to the job queue - and so on. This works fine for my USB connected devices but I guess it caused problems here because after a while CC crashed and then I couldn't restart it (it would crash immediately). In the end I had to do a clear data on it and that allowed me to restart. Since then I re-added the books more carefully and it's been fine so far.

Not sure if I have a lot of feedback about the UI etc. So far it's just great to be able to transfer the books. Oh, I suppose it would be nice to be able to remember the preference for the app opening the book.