Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplicate volumes as chapters after updating #3437

Open
dertasiu opened this issue Dec 4, 2024 · 8 comments
Open

Duplicate volumes as chapters after updating #3437

dertasiu opened this issue Dec 4, 2024 · 8 comments
Labels
needs-triage Needs to be triaged by a developer and assigned a release

Comments

@dertasiu
Copy link

dertasiu commented Dec 4, 2024

What happened?

When I updated my instance to the version 0.8.3, I encountered that in the series were I have one file per volume, the chapters "duplicated".
Recently, I have restored a backup and updated straight to 0.8.4.2 where there was a scanner rewrite, just to see if it is fixed, but the error persists.
Here you have an image to show what is happening:
imagen
There are 8 volumes and 16 "chapters", but when I enter in the chapters...:
imagen
As you can see, the progress is kept in one of the chapters. There are series that I have finished where now it shows me that I'm in the 50% of completion.
The thing is that, if I create a new library, it doesn't happen, I get the expected behaviour. Also, when I move the directory of a series out, reescan, and move right back in, it enters without problem, but I lose the progress, categories, etc...
Here is a quick SQL query to show that the file is "triplicated" (one of the copies is the one in the new test library)
imagen

I thought of reimporting all the progress to the new library but I don't know how to do it, because the table AppUserProgresses points to volume IDs and it is a little complicated.

What did you expect?

The behavior that is happening in the new library or when I re-import the files:
imagen

Kavita Version Number - If you don not see your version number listed, please update Kavita and see if your issue still persists.

0.8.4.2 - Stable

What operating system is Kavita being hosted from?

Docker (Dockerhub Container)

If the issue is being seen on Desktop, what OS are you running where you see the issue?

Linux

If the issue is being seen in the UI, what browsers are you seeing the problem on?

Firefox, Chrome

If the issue is being seen on Mobile, what OS are you running where you see the issue?

iOS

If the issue is being seen on the Mobile UI, what browsers are you seeing the problem on?

Firefox, Chrome

Relevant log output

No response

Additional Notes

No response

@dertasiu dertasiu added the needs-triage Needs to be triaged by a developer and assigned a release label Dec 4, 2024
@majora2007
Copy link
Member

Try just deleting a few of the duplicate chapters via the ... menu then rescan and see if they come back.

@dertasiu
Copy link
Author

dertasiu commented Dec 5, 2024

Hi! I just tried it and they come back

@majora2007
Copy link
Member

What are the underlying file type? What do the file paths say for chapter 1.0 and 1? Is there metadata in the file?

@dertasiu
Copy link
Author

dertasiu commented Dec 5, 2024

The file type is a CBZ, besides another ".opf" file that Calibre generates in the same directory and Kavita ignores it thanks to the library exclude filter "*.opf"
They point to the same file, different ID:
imagen
imagen

About the metadata, is generated with Calibre, embedded with the plugin "Embed Comic Metadata", and stored in ComicInfo.xml inside the CBZ file.
Now that I look at it, the file also has a Zip comment in JSON.
In ComicInfo.xml the "Number" is "1.0" and in the JSON comment the "issue" is "1.0".

I have attached the metadata:
Metadata.zip

@majora2007
Copy link
Member

Kavita (nor any other program to my knowledge) supports Zip Comments (ComicBookLover) metadata.

ComicInfo is what you want to look at. For future reference, you are MUCH better off using Manga Manager for tagging metadata as it can scrape from AniList and will give a much richer expression of metadata than Calibre.

I'm not 100% sure and I'm still on a break from Kavita, but I would say it's likely the 1.0 in the Number field. Make that 1, delete the volumes and rescan. Kavita should fix it all up.

@dertasiu
Copy link
Author

dertasiu commented Dec 5, 2024

I've tried Manga Manager with the automatic import function but it doesn't import the "Number", only the series.

I just tried to change the "number" with Manga Manager and when I reescan the series Kavita doesn't detect any changes.

The main problem I'm facing is that, if I delete the volumes and reescan them, it imports them ok but I lose all the read progress and the collections that the series were in. Also, if I make a new library, it imports them ok.
In fact, I think that, maybe, the scanner now interprets the "1.0" as a "1" and that is the root of my problem. I have no inconvenience with that, besides losing all the read progress and collections.

¿Do you know if I can easily export this Kavita data to the new library? At least the read progress 🙏
With that, I can recreate the library, import the read progress and call it a day, because I haven't seen more problems than that in the new version, in fact it looks very good to me and I'm thrilled to start using it again.

@majora2007
Copy link
Member

@DieselTech

@Howchie
Copy link

Howchie commented Dec 17, 2024

Just wanted to add I had this issue a few times and it even occurred on "random" volumes of series where the filenames themselves were identical formats except for the number. No embedded metadata as I use komf. I haven't noticed a pattern of when or why it occurs, and for me deleting and re-adding didn't resolve the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-triage Needs to be triaged by a developer and assigned a release
Projects
None yet
Development

No branches or pull requests

3 participants