ryot
ryot copied to clipboard
IgnisDa
Resolve bug with fractional mangas being marked as completed
Broke out the functionality of is_metadata_finished_by_user into multiple functions including a new one to handle marking manga as completed. In the event a fractional manga exists when checking metadata sites like anilist they will list it as having 250 chapters when its really 245 chapters + 5 specials which are fractional ie 25.5/50.5/75.5 etc...
When marking these as completed we needed to change the logic to accommodate this so ive gone ahead and added a function which operates by adding a forward iterator for every occurrence of a non-whole number ie
1 = 1
2 = 2
2.5 = 2+1 = 3
3 = 3 + 1 = 4
3.5 = 3 + 2 = 5
4 = 4 + 2 = 6
This will allow this function to work within our current bag generation functions.
Note: We are using btree to store the manga_chapters so that the numbers will be placed in order when performing our for loop since there is no guarantee the user marked read progress in order.
To test this you can technically use any manga since we dont have a way to detect if manga have fractional releases but the manga Attack on Titan is a good example:
https://anilist.co/manga/53390/Shingeki-no-Kyojin/
States 141 chapters:
While having 139.5 numbered releases with 3 fractional releases https://mangadex.org/title/304ceac3-8cdb-4fe7-acf7-2b6ff7a60613
To test it you can test normal functionality by going to an attack on titan entry in ryot at marking chapter 141 as read and have it mark all previous chapters as read.
To test the fractional releases you can
- mark chapter 1 as read
- mark chapter 1.5 as read
- mark chapter 140 and all previous chapters as read
This should add up to 141 chapters read which is correct and when you put a breakpoint in the is_marked_finished function you should see is_finished being set to true when you refresh the page.
It works the way you described but after completing 142 chapters, if I set chapter 1 as read (which means I am re-reading it from the beginning), the In Progress collection is not applied. Should that not be the behaviour?
Youre correct ill have to rethink how we handle this as the current implementation dont allow re-watching
Resolved it by changing to vector and changing to logic to accommodate re-reading. I forgot about this functionality during initial implementation good catch!
So i did the following on a fresh instance:
- mark chapter 1 of death note as read.
- mark chapter 108 of death note as read (with "Mark all unread volumes/chapters before this as watched" checked)
media is correctly marked as finished
- mark chapter 1 as read again
media correctly gets added to "in progress" collection
- mark chapter 1.5 as read
- mark chapter 108 as read with the checkbox checked
the chapters in between are not marked as read. So the history says: 1, 2, 3, ..., 108, 1, 1.5 and 108.
This is incorrect. It should be 1, 2, 3, ..., 108, 1, 1.5, 2, ..., 107, 108 (right?)
This will probably require changing the logic of https://github.com/jacob-tate/ryot/blob/320af6a29f9c80893f86ac6f7128e6f5a6c0d779/apps/frontend/app/routes/actions.tsx#L272-L324
It might be easier if this logic is moved to the backend since the is_metadata_finished is already implemented there. Would you like to take a shot at implementing it? I am also open to any alternate solutions you might have since the progressUpdate logic implementation in actions.tsx is becoming pretty convoluted.
It might be easier if this logic is moved to the backend since the is_metadata_finished is already implemented there.
I agree this is probably the best move since the logic is getting pretty complicated and can result in some odd behavior sometimes when marking large sets as read it requires multiple refreshes to see the entire list. As for the bug you described id have to look more into the logic to find where this is occurring but its probably work refactoring it into the backend.