search

Casvt / Kapowarr

Kapowarr is a software to build and manage a comic book library, fitting in the *arr suite of software.
https://casvt.github.io/Kapowarr/
GNU General Public License v3.0
447 stars 17 forks source link

Bug: App thinks covers are for TPBs, marking them as downloaded #69

Closed Serneum closed 1 year ago

Serneum commented 1 year ago

Description of the bug

When importing an existing library that stored the series covers as a JPG file, Kapowarr seems to think that it has downloaded some comics.

As an example, I have Venom: Lethal Protector II (2023) and NewThink (2022) downloaded. For Venom, I have no issues downloaded, but have a cover.jpg and Kapowarr thinks that I have the TPB downloaded so I have all five issues. For NewThink, I have four of the five issues downloaded and a cover.jpg file. Kapowarr shows all five issues as downloaded because it thinks the cover.jpg is a TPB

To Reproduce

  1. Add a new volume
  2. Map a comic volume to a volume directory on your machine
  3. Add a JPG file to the volume directory
  4. Refresh and scan the volume the directory

Expected behaviour

Kapowarr should ignore the jpg file and not treat it like a TPB

Screenshots image image

image image

Version info Kapowarr version: v1.0.0-beta-1 Python version: 3.8.16.final.0 DB version: 6 Database location: /app/db/Kapowarr.db Data folder: /app

Running in Docker via Docker Compose

Casvt commented 1 year ago

For now, cover files are just completely ignored. They wont be registered in Kapowarr and it will just leave them alone. This fixes your problem. It is, however, not the best approach.

This has to do with renaming mostly. If the volume folder is renamed (the volume folder regex is changed or a custom folder is set), or the root folder is changed, the cover file won't be moved/renamed. It doesn't exist to Kapowarr, so it also doesn't do anything with it. The cover file will be left behind.

It can be seen as a file that can't really be mapped to any issue and also shouldn't be named like one; it's more of a "volume file" than an "issue file".

Something similar will happen when support for metadata export is added. Metadata files will be generated for volumes. These files also don't map to any specific issue but rather map to the volume in general. This makes it exactly the same type of file like the cover file.

I should add internal support for "volume files": files that concern the volume in general and should be moved alongside the rest, but should not be mapped or renamed to a specific set of issues. I'll make an issue for it.