Thread: Autoconverting when copying to device
View Single Post
Old 04-24-2021, 05:12 AM   #12
davidfor
Grand Sorcerer
davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.
 
Posts: 24,907
Karma: 47303748
Join Date: Jul 2011
Location: Sydney, Australia
Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos
Quote:
Originally Posted by kovidgoyal View Post
I did think about it and I dont think its do-able with a reasonable amount of effort. The problem is state. In order to be able to remove multiple update metadata jobs safely one has to be sure that none of the other jobs in the queue rely on the metadata being up-to-date. And the jobs system doesnt have that kind of metadata about jobs. Its fairly trivial to just delete all metadata update jobs except the latest, however, guaranteeing that is safe is far from trivial.
Looking at it, the update metadata job is queued after a book upload or delete. And run immediately. It could be done that if the next job in the queue is a book upload or delete, the update metadata could be skipped. That way, what we currently see as:

Code:
upload book
update metadata
upload book
update metadata
upload book
update metadata
upload book
update metadata
convert
upload book
update metadata
upload book
update metadata
Would become:
Code:
upload book
upload book
upload book
upload book
update metadata
convert
upload book
upload book
update metadata
And it should be driver specific. Then the drivers that need the update metadata after each book upload could still do it. I think that for devices using the drivers based on the USBMS driver that are only sending files without updating anything else on the device it would be safe. It would be drivers that do something more that would need care. It would not be a problem for the KoboTouch driver, but might be for others that a using database or something else. It could be a flag in the driver that turns on doing this. With the default at the top of the driver class hierarchy being "off" so that there is no change in behaviour unless the driver maintainer decides it is a good idea.

I think that would work as long as you can see what is the next job and its type or something similar.
davidfor is offline   Reply With Quote