Is there anyway to create a list of books that will automatically be sent to my device when I next connect it? Right now I just tag books as "!send" and then send those books when I next connect, but I was wondering if there was a way to do this in a more automatic manner. E.g., if I were to send a book to the device when the device was not connected, instead of telling me "no device is connected" Calibre would remember and send it when the device was next connected.

I did a forum search, but didn't come with anything - I'd appreciate it someone would send me to the relevant thread if I've missed it.

no, there's no way.

There currently isn't any way to automatically send on connect. As far as I know, no one is working on it.

I do something similar to what you describe. I have a custom column where I keep the list of books I want on the device. I have two saved searches that I use when the device is connected, one that looks for "books_I_want_on_device:true AND ondevice:false" and another "books_I_want_on_device:false AND ondevice:true". The first finds any book that I want on the device but isn't, and the second finds any book on the device that I don't want there.

That might be kind of a neat feature. Although, I have to confess, not neat enough to convince me to dive into Calibre's source code.
Shouldn't this be relatively easily implemented when one just queues the appropriate job to be activated once a device is connected (and its book list read)? The only issue I see would be carrying that job list over across a restart of Calibre, I don't know if that's possible or done already.

@kovid & @chaley - Well, that answers my question, then!:)

And thanks, chaley, for sharing how you manage this - I might have to try that out.

Actually, this reminds me about something I was going to suggest as a tweak to Calibre's job queue. Specifically, can the queue be made pausable and unpausable?

From the gui perspective, just a button next to the queue which is play/pause to control it. When paused, the queue would, erm, pause. And not restart until it's unpaused *even if you add more jobs to the queue*.

Then each job can check whether it's doable or not when it attempts to execute.

This would let me, for example, queue books individually to be sent to the device without them being sent the instant i add them to the queue. Calibre could then, when the queue is restarted, send them all in one batch (or in a sequence of individual jobs - doesn't really matter which from a user perspective).

This would also solve the OP's problem as a nice side-effect.

Shouldn't this be relatively easily implemented when one just queues the appropriate job to be activated once a device is connected (and its book list read)? The only issue I see would be carrying that job list over across a restart of Calibre, I don't know if that's possible or done already.Some problems to overcome:

1) the job queues are not persistent. Changing this wouldn't be easy.

2) which device? How do I name it, as it isn't connected?

3) what if I have multiple of the same device (I actually do)? How do I distinguish them?

4) the 'send to device' button would need to be enabled even if a device is not connected. This creates a host of internal problems.

5) what about delete from device? It seems that deletes also should be queued.

My guess is that to do this correctly (thereby avoiding lots of bug reports and further enhancement requests), we would need to build a shadow of each device on the local disk. Calibre would operate on that shadow. When the device is connected, the shadow would be copied to the device. Getting this process right would not be easy at all, especially if 'things' happen to the device that calibre doesn't know about.

In the end, a column + search method like marie44 and I already use would almost certainly be more reliable. I admit that it has one or two more steps, but this isn't a high price to pay for something that works.

I see. I'd argue that queued device sends should just be sent to the first device connected, that would take care of your points 2 and 3. I'd argue against including deletion, since, as you mentioned, you never know the state of the device when it gets connected (I'm thinking manipulation outside Calibre). In the end, that's all rather academic, since, as I mentioned before, not only are you not interested in such features, but neither am I (apart from the point where I thought "Hey, that would be cool!".).

this is fairly trivial to implement, not as a job queue, but just store the ids in a config variable (this is exactly how the automatic sending of news is implemented today). Send the books to whatever reader is connected for the first time after the books have been marked, just as for the news.

However, I have too many other things on my plate right now to work on this.