CC V3.5.1 .2 and .3 have been published

[chaley]

CC production release V3.5.1/V3.5.2/V3.5.3 has been published on Google Play. It will be published on Amazon sometime in the next few days.

V3.5.3 fixes a crash on Gingerbread and when selecting a FBReader plugin as the default reader.

V3.5.2 fixes a crash when sorting on a custom column that is not present in all books.

For those of you in the beta program, the production release contains a few changes since V3.4.4l.

• Changed the sync books option to add a second connect option asking if you want to sync books instead of always syncing
• Tapping the cover in book details grows the cover to full size (unless it already is). Tapping it again shrinks it back to what it was.
• FBReader PDF and DJVU plugin support
• Updated translations for French and Spanish.

The full change log since V3.4.4 is here.

[Agama]

Thank-you for this update. I can confirm that the FBReader PDF support works perfectly.

[chaley]

Originally Posted by Agama

Thank-you for this update. I can confirm that the FBReader PDF support works perfectly.

I just saw a crash in the developer console that happened when someone (you?) tried to set the default reader to an FBReader plugin. I will fix that.

If this is you, can I wait for a few days to make another release? I would like to be sure that there aren't any other time bombs waiting for me. In the mean time you would need to tap on the reader line.

[kaufman]

One thing about the new release. CC was running a bit slow on my system for the last beta. I was going to do the uninstall/reinstall to see if it was my fault for all the db changes I had forced CC to make.

The release version is not showing the slowdowns at all. If anything, it seems really fast.

[Terisa de morgan]

Thank you very much. I've just got the new release and I'm very happy with it. My library looks like I like and it's very nice.

I've seen some problem with Spanish translation (aside of it isn't finished, although I suspect I'm going to have a lot of time at work ), and I'll try to correct them.

[chaley]

Originally Posted by Terisa de morgan

Thank you very much. I've just got the new release and I'm very happy with it. My library looks like I like and it's very nice.

Thanks.

I've seen some problem with Spanish translation (aside of it isn't finished, although I suspect I'm going to have a lot of time at work ), and I'll try to correct them.

Thanks again.

I hope that when other Spanish users (or users in other languages) see the translation and see untranslated phrases, they will take an interest and sign up to help. That is one reason I made the Translation Credits dialog so visible, to help people discover that helping with translations is possible and easy.

[chaley]

Originally Posted by kaufman

One thing about the new release. CC was running a bit slow on my system for the last beta. I was going to do the uninstall/reinstall to see if it was my fault for all the db changes I had forced CC to make.

The release version is not showing the slowdowns at all. If anything, it seems really fast.

Not sure why there would be a difference, but I will happily accept it.

[kaufman]

So, I just got my new phone, and when I restored settings from my old phone, it looks like it restored everything except "Move Disconnect to menu". I used to have it off, and when I restored it it was on.

[chaley]

Originally Posted by kaufman

So, I just got my new phone, and when I restored settings from my old phone, it looks like it restored everything except "Move Disconnect to menu". I used to have it off, and when I restored it it was on.

Don't see any reason why some settings wouldn't get saved/restored. However, that one was a later addition and it changed the internal type of the option from boolean to int. Perhaps your backup was made before the type change? That would cause that option to be skipped.

I also note that the restore process will stop if any option is malformed in the backup. It should instead skip that option. I will fix that.

[kaufman]

I also ran into something else when I was loading up my new phone. If I said "send over 6000" books", it would think a long while, start sending, and then fail out after a few dozen books by losing the connection to the device.

I got it to work by sending 700 or so books at a time. It would think less time and then start sending the books. At that point, I could queue another 700 books and send those, and so on. In the end, I had 8 jobs queued up, and they ran one after the other. I've had this issue before with new devices.

Would it make sense to have calibre internally break large send requests into a bunch of shorter ones. As far as I can see, there is no downside to the user, and it fact the entire job will complete faster because whatever preprocessing it is doing before it starts sending can be multitasked with the sending of other books.

Is this a strictly Calibre thing I should post somewhere else, or is this a non-starter and I should just drop it?

[chaley]

Originally Posted by kaufman

I also ran into something else when I was loading up my new phone. If I said "send over 6000" books", it would think a long while, start sending, and then fail out after a few dozen books by losing the connection to the device.

I got it to work by sending 700 or so books at a time. It would think less time and then start sending the books. At that point, I could queue another 700 books and send those, and so on. In the end, I had 8 jobs queued up, and they ran one after the other. I've had this issue before with new devices.

Would it make sense to have calibre internally break large send requests into a bunch of shorter ones. As far as I can see, there is no downside to the user, and it fact the entire job will complete faster because whatever preprocessing it is doing before it starts sending can be multitasked with the sending of other books.

Is this a strictly Calibre thing I should post somewhere else, or is this a non-starter and I should just drop it?

I don't know why it is disconnecting. My guess is that something is taking too long and the network is timing out somehow, but it isn't at all obvious where that is. CC has no timeouts. The calibre side does, but I don't see how they could be triggered. Preparing the books to be sent involves the driver but it doesn't involve the network.

As for calibre automatically breaking the request into smaller ones, any request to do that will end up with me because the disc-based devices don't have timeouts. They will happily wait for days for data to be written to them, primarily because they are (usually) unaware that anything is happening. I haven't looked at the send-preparation code for ages, so I can't say at the moment whether it can be done with reasonable effort.

[kaufman]

Originally Posted by chaley

I haven't looked at the send-preparation code for ages, so I can't say at the moment whether it can be done with reasonable effort.

The only reason I would say it might be worth the effort to take a look is that its going to be the first thing some people with large libraries run into when they try to connect to a wireless device. You know what they say, "you only get one chance to make a good first impression".

[chaley]

Originally Posted by kaufman

The only reason I would say it might be worth the effort to take a look is that its going to be the first thing some people with large libraries run into when they try to connect to a wireless device. You know what they say, "you only get one chance to make a good first impression".

Looking closer at this, it appears that the calibre inactivity timer might be firing. It goes off in 30 to 60 minutes. If the time to prepare 6000 books to be sent to the device exceeds the timeout value then the calibre device driver will disconnect the device. When the books are ready, the device is gone.

I have submitted code to disable the timeout by default, but that won't help anyone who has changed any other device parameters. You can turn it off yourself by going to device settings while connected.