Entry with multiple chapters with same number doesn't save each one individually (due to same group?)

[ScherisMarie]

https://mangadex.org/title/df805b8c-0c05-40f2-8f92-0f096ca346e4

If you watch what it's doing in Finder/Explorer/etc., you'll see that with the code as of 3883aa49d52e2c7c3f914f43a6e5fdd3aeebbedf, instead of downloading each instance individually, it overwrites the existing files.

In this case of this manga, it'll get overwritten twice due to three "Chapter 1"'s existing.

(It can be worked around by killing the script once it downloads the one you want, so there's a temporary workaround for the time being.)

EDIT: I think this is because the same group has three different versions, so the script sees the same c## [GROUPNAME] format and thus overwrites?

[frozenpandaman]

Will be able to look into this soon. I'm moving in a couple weeks so am pretty busy. Thanks for reporting this!

[Chrysana]

Fwiw, a good example of this issue is https://mangadex.org/title/4259cfdd-2a81-41aa-91d0-a5d44275d6cc/azur-lane-comic-anthology

Available chapters: 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2.5, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3.5, 3.5, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4.5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5.5, 5.5, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6.5, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7.5, 7.5, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9.5, 9.5, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10.5, 10.5, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12.5, 12.5, 13, 13, 13, 13, 13, 13, 13, 14, 14, 14, 14, 14, 14, 15

Download folders separated by volume would also help alleviate this

[frozenpandaman]

lol oh boy that example…

@Chrysana, thanks – hard to have a one-size-fits-all solution because most of the time chapters keep on increasing with each successive volume, but other series "restart" the chapter count from 1 in each volume. Like in the example above.

Maybe if there is volume information, the folder naming could include that info so they'd get sorted properly? But then you want the I/O to be able to reflect that too, and annoying the API doesn't return chapters like this in any coherent order IIRC…

Anyway, leaving this open for more thoughts for now. Hopefully not toooo huge of an issue because numbering like this seems pretty uncommon on the whole? (Definitely related to #31 as well.)

[Chrysana]

A more rudimentary workaround would be to just detect if a file/folder already exists, yeah? Could just append a (1) or something to the end of the file/folder name.

Doesn't really "fix" the issue, but it would allow the program to at least download all of the files

[frozenpandaman]

Good idea @Chrysana, thanks. That workaround actually turned out to be a little more involved than I imagined, but I managed to implement pretty much that fix. I'm not sure if it's a final solution and if I should close the issue or not, but let me know what you think. At the least now you're able to actually download all those multiple chapters with the same number! (though they won't show up in the correct order in your file explorer or whatnot)

[doroshenko]

Unfortunately, the workaround doesn't work together with the option to archive chapters, as the folder with the downloaded images is deleted after archiving and the index is not appended to the next downloaded chapter.

[orbea]

@frozenpandaman Here is another example.

https://mangadex.org/title/e765a5c0-52a0-430c-81b7-15f69f1a1839/azumi-2