You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since I've been attempting to import the DC Master Reading order list into Komga recently, I wanted to discuss some of the problems I've come across and brainstorm ways to fix them.
The master lists are quite large, and Komga does not match as well as it could using all the data in the list and my files. For instance, importing DC part 2 (779 books), I had to manually fix the match on at least half of them because it would match to the wrong volume. This is more of a Komga issue that could be solved by making its matching more robust, but the size of the lists may be problematic. The master lists are already broken into multiple fairly arbitrary parts, so why don't we break it up more...
The second problem, is the events... They are not incorporated into the master lists in any way, and you have to consult an outside source (website) in order to know when to read them. This seems like a huge problem if the goal is a reading list. So the easiest way to fix this would be breaking up the master list and adding a naming convention prefix to the lists, something like [DC01-00], [DC01-01], [DC01-02],... [DC03-21]... etc. While this solves one problem, I think it creates another in that now the event lists can not be separated from the master list folder without duplicating them and renaming them just for naming purposes. So while this may be the most feasible solution, it is not my ideal solution. I suppose since it could be solved with scripting to just combine lists, we could just create multiple versions so that there's the master list and event list separate, and then an Ultimate list that combines both into one.
I think the most future functional solution would be to create nested reading lists. With this solution, then the reading lists could be broken up as much as needed and you gain additional organizational abilities. Could keep the reading list view as a group of folders, or when they're imported they simply expand to show all as a single list. However, this would require a change in any programs that import cbl lists. I'm not aware if that's something within our power to change, but I'd be most interested in this change. Then the question would be do you create XML that points to other reading lists that the user has to probably manually point to, or do you create XML 'folders' that still list every issue inside the sub-reading list so that it's its own stand-alone entity?
Any thoughts? Atm, I kind of just want Komga to match better because if I have to manually fix half of the entries each time I'm not going to want to reimport the entire master lists multiple times and correct every time.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Since I've been attempting to import the DC Master Reading order list into Komga recently, I wanted to discuss some of the problems I've come across and brainstorm ways to fix them.
The master lists are quite large, and Komga does not match as well as it could using all the data in the list and my files. For instance, importing DC part 2 (779 books), I had to manually fix the match on at least half of them because it would match to the wrong volume. This is more of a Komga issue that could be solved by making its matching more robust, but the size of the lists may be problematic. The master lists are already broken into multiple fairly arbitrary parts, so why don't we break it up more...
The second problem, is the events... They are not incorporated into the master lists in any way, and you have to consult an outside source (website) in order to know when to read them. This seems like a huge problem if the goal is a reading list. So the easiest way to fix this would be breaking up the master list and adding a naming convention prefix to the lists, something like [DC01-00], [DC01-01], [DC01-02],... [DC03-21]... etc. While this solves one problem, I think it creates another in that now the event lists can not be separated from the master list folder without duplicating them and renaming them just for naming purposes. So while this may be the most feasible solution, it is not my ideal solution. I suppose since it could be solved with scripting to just combine lists, we could just create multiple versions so that there's the master list and event list separate, and then an Ultimate list that combines both into one.
I think the most future functional solution would be to create nested reading lists. With this solution, then the reading lists could be broken up as much as needed and you gain additional organizational abilities. Could keep the reading list view as a group of folders, or when they're imported they simply expand to show all as a single list. However, this would require a change in any programs that import cbl lists. I'm not aware if that's something within our power to change, but I'd be most interested in this change. Then the question would be do you create XML that points to other reading lists that the user has to probably manually point to, or do you create XML 'folders' that still list every issue inside the sub-reading list so that it's its own stand-alone entity?
Any thoughts? Atm, I kind of just want Komga to match better because if I have to manually fix half of the entries each time I'm not going to want to reimport the entire master lists multiple times and correct every time.
Beta Was this translation helpful? Give feedback.
All reactions