Quote:
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.