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

Still having trouble post processing. #820

Closed
mccorkled opened this issue Jul 16, 2021 · 6 comments
Closed

Still having trouble post processing. #820

mccorkled opened this issue Jul 16, 2021 · 6 comments
Assignees
Labels
metadata quality issue Data out of our control is causing the issue

Comments

@mccorkled
Copy link

I am still having trouble with manual post processing a ton of comics. Mylar starts with looking for Daredevil every time, and then when it finishes it states that manual post processing was completed for two comics.

Version: v0.5.4 ( master)
Docker

carepackage.zip

@evilhero
Copy link
Collaborator

Your dates are all wrong for the files that you're trying to manually post-process.

In the logs you can see several lines that are like this:
[POST-PROCESSING][ISSUE-VERIFY] 1987-10-27 is before the issue year of 1988 that was discovered in the filename.

When you reference that issue on comicvine the store date is 1987-10-27, and the cover date is January 1988 - so why is it that your filenames have the date as 1988 when it was released 2+ months earlier ?

You need to clean up the dates on your files if you want them to be post-processed or found by Mylar - if I recall this was something you brought up a few times before in other issues, and I mentioned the same thing.

You're going to have to go thru the logs to see which ones it's failing on - and then fix the dates. Every single one of the ones it doesn't post-process is due to the date in your filename being the incorrect value. I know I also mentioned that I might possibly fix the adjustment, but I'm still not 100% sure going several months outside of the existing 2 month window is the best course of option.

@mccorkled
Copy link
Author

mccorkled commented Jul 18, 2021

When these were not post processing, I manually went through to check the dates and they are right. One example from my log..

[POST-PROCESSING][ISSUE-VERIFY] 1946-10-30 is before the issue year of 1947 that was discovered in the filename

When I go into that comic within Mylar, I can see that the date for issue 60 is 1947. My file name is Captain America Comics 60 (1947)

The next line in the log is...

[POST-PROCESSING][NON-MATCH: Captain America Comics-1628] Incorrect series - not populating..continuing post-processing

What would be the reason Mylar is looking under the wrong comic? There's only one "Captain America Comics" on my watch list.

@evilhero
Copy link
Collaborator

evilhero commented Jul 18, 2021

Those are the wrong dates. Mylar uses the store date over the cover date, unless there is no store date available. The date shown in mylar is the cover date, which I know confuses the issue more, but that's how it currently is. You can view the store date by going into the Manage tab / Manage Issues and locate the series in question by sorting the columns. You'll see that it displays both dates.

The 1946-10-30 is the store date, 1947 is the cover date. Your comics are all using the cover date which was normal for comics back then (ie. before the digital era), but the date in the filename is not when the comic was actually published / available.

@mccorkled
Copy link
Author

mccorkled commented Jul 18, 2021

Perhaps then it would be beneficial to show that date (or have the option to) when under the comic. I have been using the date that Mylar displays when I go into the comic's directory.

I have them mostly all sorted now. Thanks for the help on that. I am having trouble with one last book titled Scientific Progress Goes "Boink" #1 (1991) and I believe it is due to the "". Any suggestions?

@evilhero
Copy link
Collaborator

What is the filename for the "Boink" one ?

As far as pubdate aspect - unfortunately the entire comics industry uses the publication date with more regularity than the store date when talking about a specific issue. Mylar has to use the store date for verification / matching / etc due to how specific it is, and the fact that it's almost literally 2-3 months prior than the cover date. So when it does comparisons it uses the more accurate date if it's available. Perhaps in the future we'll try to allow for some customisation by the user as far as what is displayed.

Fun fact: the cover date was created by publishers for comic book shops / retailers - the cover date shown on the 'cover' of the comic tells retailers when they have to pull the unsold comics from the shelves and ship them back to the publisher in order to get reimbursed. There's really no other use for it other than the fact that it's literally on the front of the comic, but the actual store date is on average 2-3 months prior than the date listed on the cover (at least it used to be for the larger publishers)

@mccorkled
Copy link
Author

The filename is Scientific Progress Goes Boink since Windows does not allow certain characters.

evilhero added a commit that referenced this issue Aug 3, 2021
IMP: Add Advanced MetaTagging options in GUI
IMP: Added color legend to search results & weekly page
IMP: Break out the CBR TO CBZ ONLY option in the config under it's own section as Conversions
FIX: Wanted page checkbox via filter regarding storyarcs
FIX: Triple-click highlight directory location on series detail
FIX: 'part' in series title would get mistakingly detected as part of a volume/TPB during file checks
FIX: (#820) series with double quotation marks would fail to be matched against
FIX: Wanted page not displaying due to annuals being listed as individual watchlist items and within series via annual integration
FIX: Corrected some incorrect counts related to annuals during file rechecks
FIX: Fixed incorrect pathing to Archived issues
FIX: series.json creation would error when adding new series
FIX: CV API returns API date times as PST timezone (not TZ aware). Changed outlying call that dbUpdate uses to submit date-range queries based on PST time, and not UTC
FIX: Annuals in weekly pull not linking correctly to series if CV hadn't posted data yet but annual was linked
FIX: Post-processing check incorretly checking the pull year to not be the current year
FIX: Sabnzbd version check not returning valid value > 3.3.0
@barbequesauce barbequesauce added the metadata quality issue Data out of our control is causing the issue label Mar 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
metadata quality issue Data out of our control is causing the issue
Projects
None yet
Development

No branches or pull requests

3 participants