Support for CBZ conversion

[Casvt]

You're doing great, but wait one second.

The base is good, but purely focused on converting to cbz. I think that now, while we are still laying down the infrastructure for file converting, we should already make it future proof. Some things:

1. People will want to convert to a different format. So the 'conversion function' will already be too specific because it's only for CBZ and thus not scalable for other formats.
2. The setting to convert to cbz after download will be too specific because people will want to convert to a different format after download.
3. Not all formats can be turned in to other formats (e.g. RAR is closed source so it might only be possible to convert FROM it and not TO it). So the user will want to set multiple rules (e.g. convert to cbz, otherwise zip, otherwise folder, otherwise keep current format).

All in all, I think we need to future proof the conversion infrastructure, so that later on we only have to add a class to support a new conversion and everything else is handled for.

I can see what I can do this evening to start working on the infrastructure. Then you can 'fill' the system with conversion methods.

[Berserkir-Wolf]

My logic behind the cbz specifically is that it will tie in with the metadata discussions - archive tags are a thing, after all. CBR doesn't support them, while CBZ does (which would allow us to add metadata to the issue file directly).

[Casvt]

My logic behind the cbz specifically is that it will tie in with the metadata discussions - archive tags are a thing, after all. CBR doesn't support them, while CBZ does (which would allow us to add metadata to the issue file directly).

I understand. That would be one of the advantages of converting to CBZ. But other people will want to convert to something else maybe, and I'm just suggesting that we already build the infrastructure for that, so that when the time comes, it's very easy to add new conversion methods.

[Berserkir-Wolf]

I agree with the idea of building it to be extendable. I'm leaning towards setting it to have a variable to pass to it that sets target filetype, source filetype(s) being anything not already target. Just hardcode the variable initially, which would allow for switching it to selectable later on.

[Casvt]

I'm thinking the following. Give me a few hours and you'll see it in my commits to this branch.

A class for each conversion (e.g. a ZIPtoCBZ class, etc.). Then a function that takes the source file and desired target formats in a list where the order of the list is preference. The function checks which conversion is possible, going for the one that is most desired (based on order of format list). The function grabs the class for that conversion and let's the class do it's conversion.

This function can be called by the PostProcesser or by the API. The postprocesser will fetch the format preference from the settings and call the function with that list and the file that is being processed.

We also allow the user to convert the files of a volume from the UI. A list with all files of the volume are shown and at the top an option to set the conversion preference. Then the API request is made which calls the conversion function for each file with the preference list from the UI.

With this setup, we can easily expand. Just add a new class for a new conversion and you're done. Everything else will get 'updated' automatically to support this new conversion method and everyone is happy with little effort.

[Berserkir-Wolf]

I figured build the functions to act from the API, callable by the additional button (to start - allowing for manual triggering while testing). Then it can be linked into the postprocessor flow, once it's functional.

With your suggestion, would it then be a list in the "unzip" section for desired filetype, and a switch for "convert to desired type after download"?

[Casvt]

Okay see the commit. I propose that I make the backend and you the frontend.

In converters.py, we have the different converter classes. In conversion.py, we have the backend interface. The convert_file function is the function that I described in my prev. comment. The preview_mass_convert will generate a list with the proposed conversion based on the format list given. mass_convert will actually do it, given that the input is the same ofc as with preview ofc.

These changes are reflected in api.py. Functions in files.py are removed.

---

How I see the frontend (what you can do):

We will have two settings: one with the format preference and one for if we want to convert after processing. The available formats to choose from are dynamic and are loaded from an API request (I'll make an API endpoint for it). It should look a bit like the service preference option (but you can add and delete options too; and don't forget a default option at the bottom for "no conversion"). We POST the settings with just a bool for post-download processing and a list of string values for the format preference.

The post processing is purely in the backend so you don't have to worry about that.

For manual converting:

I'm thinking a similar interface to the renaming window. You click the button and a window opens with the proposal (loaded from API endpoint). You click the green button and it makes the POST API request with the list of files to convert. Maybe as an extra feature show the format preference at the top just to remind the user how they set it in the settings.

---

I'll prepare the API so that you can work on the frontend without having to wait on the backend. Wait a commit or two for that.

---

Sound good?

[Berserkir-Wolf]

How are new settings handled automatically? Trying to run it without the migration in place comes up with 'key error'. If I remove it,When attempting to save it, it says no setting matches.

Might take a little bit for me to do the UI stuff - my js/html/css is rusty as hell. Happy to crack into it though.

[Casvt]

Renamed the branch. Now available at conversion_support and PR #103