Support for galleries containing pages from other galleries

[tsudoko]

Would be mostly useful for magazine series.

Hacky implementation with basic usage instructions here. It's compatible with the current database format and fairly easy to edit.

Known current issues/TODOs:

• no web UI for editing the gallery file
• no information in the web UI which galleries the images are picked from
• all source galleries combined (not just the chosen pages) need to be smaller than tempmaxsize

I'm not sure if this is a good starting point, I mostly wanted to get it working as soon as possible while still being backwards compatible with the current database format. Any feedback appreciated, I don't even know if this is a feature anyone else wants to have.

[Difegue]

Hey, this is great! (It's the first time I ever got any substantial fork/code modification to this project too so that makes it double nice)

The implementation is a pretty good starting point, although I'm not sure creating a bogus .gallery file containing the gallery/page breakdown is the way to go.

I'd personally stuff that data into a hash in the database with its own ID - that hash would have a flag indicating it's not really an archive but a composite.
This would allow the web UI to recognize it and feature options for editing it and showing which galleries it's picking images from.

As for the tempmaxsize issue, it could be solved by only extracting the needed pages from the archive files. This is already done in some fashion in the generate_thumbnail function in the Archive Utils, which only extracts the first page in an archive.

As for whether the feature is useful, well I'd say if you're willing to put in the time/code to make a good enough first implementation, I don't mind merging it and ensuring it doesn't break on future updates. ✌

[tsudoko]

I'd personally stuff that data into a hash in the database with its own ID - that hash would have a flag indicating it's not really an archive but a composite.

That was the initial idea, I went with gallery files because it seemed like the fastest way to get a minimal working implementation without worrying too much about how the code interacts with Redis etc.

As for the tempmaxsize issue, it could be solved by only extracting the needed pages from the archive files.

Wouldn't that still cause some pages to be removed if the temp folder was already close to tempmaxsize? It could be prevented by extracting the pages to a single directory made specifically for that one gallery, but that would potentially create duplicates, since the same file could exist in multiple directories. Alternatively, pages could just be read directly from the archive files without extracting everything, but that would be extremely slow for compressed archives without indexes (e.g. tar.*).

I'll take a better look at the whole codebase tomorow and start working on a proper implementation.

[Difegue]

tempmaxsize has a mechanism to "spare" the last created folder in temp, so that's not an issue. I don't think duplicates are really a problem here either.