Add support for multiple chapters in one file

[mjgalindo]

Having hundreds of chapters in a kindle becomes very difficult to handle. Sending them in ranges would make a lot of sense for longer series.

[weigler]

This is a good idea... receive the volume and not each chapter.

[JohnEdwa]

Doing it by volume would only work if the source gave that information which most don't.

But I totally agree, there should be a way to bundle the chapters together before being sent, especially when there are more and more mangas with very short chapters - the ridiculously named "A Story About Treating a Female Knight Who Has Never Been Treated as a Woman as a Woman" for example has usually 4-8 pages per 'chapter'.

[aplanas]

There is a limit, tho, as amazon have a size limit for documents send by email. Also @JohnEdwa is right, most of the sites do not provide volume information, or provide it in random ways (partially hinted in the name of the chapter)

I can sacrifice cache reuse in favor of conglomerating several chapters, but to make it practical (no surpassing the size limit) I need first to decrease the weight of each image.

Overall this makes sense to me, but this will require some time.

[JohnEdwa]

It would make sense to swap the hardcoded 30 sends/day limit to mo of a 'credit' system where what and how you send makes a difference depending on how intensive it is. For an example, 30 chapters of Berserk is around 700 pages while the same for Female Knight is around 180 - and if ask to combine the Female Knight all into one (as it should still fit the 50MB amazon limit), it is sending just one file, but having to process the 30 chapters and 180 pages, so should it count as 1, 30, or something in-between? There are also some extreme examples where a 'chapter' is actually just one page. If I can ask for 700 pages of berserk, shouldn't I be able to combine hundreds of 'chapters' to one file with this one?

[aplanas]

@JohnEdwa that is a very interesting proposal. The limit is there because the server have some limitations. So is not fair consider a 30 pages chapter the same as a 10 pages one.

But I can see a big issue. One is that this is very hard to communicate to the user, as kmanga have no clue about the size of the chapter (and knowing it before hand will impose a big load to the original source, as I need to make at least one more request per chapter, per manga, per site)

If I use some kind of 'you have 5M of images for today' is a bit fuzzy measure, as this limit can be from the input (before the image is resized), for computing (during the resize) or for output (once the MOBI is created)

But I will think more about this idea.

[JohnEdwa]

Hmmmh, true, the lack of information is an issue.

I think basing it on the before sizes would be the fastest as that way you can detect when something is going to be too much the moment you've downloaded enough chapters without having to process them. The point is, after all, to get a reasonable amount of chapters into one file and not a 'who gets closest to 49.999MB' competition.

As for how to handle the credits, one way I thought of handling the ambiguity could be allowing storing and going negative up to some reasonable limits, as most people have multiple days without having anything sent after all. So let's say you get 100 credits/day but you can hold 500 and go -500 negative. When your credits are between 0-200 you can ask to send stuff, but if what you ask happens to be bigger than what you have left for that day, it uses your banked credits. If it's really big, you go to the negative and can't ask anything until you've refresh enough.