mihon
mihon copied to clipboard
mihonapp
Error while restoring
Steps to reproduce
I'm unable to attach my backup. But all I did was restore a backup.
Expected behavior
There shouldve been zero errors
Actual behavior
But this happened
Crash logs
No response
Mihon version
0.16.0
Android version
ANDROID 14
Device
Oneplus 11r
Other details
Nothing just that. I haven't encountered any problem bc of that but wanted to share that it happened.
Sorry for wasting your time.
Acknowledgements
- [X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
- [X] I have written a short but informative title.
- [X] If this is an issue with an official extension, I should be opening an issue in the extensions repository.
- [X] I have gone through the FAQ and troubleshooting guide.
- [X] I have updated the app to version 0.15.3.
- [X] I have updated all installed extensions.
- [X] I will fill out all of the requested information in this form.
I remember once having this same issue - out of curiosity, are the manga in question still in your library? Witch Hat Atelier for example seems to have errored.
I remember once having this same issue - out of curiosity, are the manga in question still in your library? Witch Hat Atelier for example seems to have errored.
Yea. All four of them are in my library and are working fine.
I've fiddled a bit with an older backup of mine that caused the same error messages. It appears that the issue arises when a chapter is reuploaded/replaced in the source under the same chapter URL. If a Mihon user then reads that “new” chapter, an entirely new history entry appears to get created.
After adding some logging during my own backup restorations, I could see a few chapters with this behaviour, and their only differences were _id (makes sense), manga_id (strange?), date_fetched, date_upload, and last_modified (which all seem sensible to me).
I don't know how this could be “fixed” easily, unless additional logic is added at some step in the restoration. On such a conflict, maybe only the most recently modified/uploaded/fetched version should prevail? 🤔
Edit: Do you happen to remember whether any of your erroring series had chapters replaced/reuploaded?
Edit 2: If the getChapterByUrl query was called with awaitList instead, and then chapters.first() was used subsequently, the issue would be resolved, but the conflicting information would be ignored.
Edit: Do you happen to remember whether any of your erroring series had chapters replaced/reuploaded?
Not in Witch Hat and Vinland Saga but there were some chapters missing in Kingdom and Dandadan
There were 9 chapters missing in Dandadan too and they appeared suddenly
Oh, I didn't mean missing chapters or new uploads. I was talking about replacing a chapter in-place, like for example, a translation group found a mistake and decided to delete the chapter and upload a fixed version with the exact same URL.
If this hunch of mine is correct, it'll be really difficult to reproduce again, especially considering that in my tests, the duplicate chapters were given different _id but also manga_id values.
I'll try to investigate a bit more soon.
I was talking about replacing a chapter in-place, like for example, a translation group found a mistake and decided to delete the chapter and upload a fixed version with the exact same URL.
Ooh I'm sorry I don't know how to check that 😭
Ooh I'm sorry I don't know how to check that 😭
Don't worry, I think you'd basically have to remember that it happened or something, I don't think there is a direct way to check.
eu.kanade.tachiyomi.j2k_2024-01-16_12-34.zip
This is the backup file I used. I tried it restoring it again in the preview app and it shows those errors.
backups are usually in the .proto.gz or .tachibk format. did you do anything to the backup file that made it into a .zip instead?
I turned it into a zip file to share it bc I wasn't able to share it in those other formats