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

[QUESTION] Renaming Files #19

Open
CubeComming opened this issue Nov 7, 2021 · 11 comments
Open

[QUESTION] Renaming Files #19

CubeComming opened this issue Nov 7, 2021 · 11 comments
Labels
bug Something isn't working

Comments

@CubeComming
Copy link

OS: What operating system are you running Manga Tagger on?

  • linux

Manga Tagger Version: What version of Manga Tagger are you running?

  • latest

Description of the issue: Give a a clear and concise description of what the issue is.
I don’t quit understand the environmental options. If I turn MANGA_TAGGER_RENAME_FILE to false, I would assume he only scraps the info’s for the series and doesn’t change its English name to its original....
But it does, so am I mistaken?
Is it possible to make him do that?

Manga Series: What manga series (singular or plural) were being tagged when the issue was encountered?

  • all
@CubeComming CubeComming added the bug Something isn't working label Nov 7, 2021
@Banh-Canh
Copy link
Member

This one is part of the dry run option. If you enable the dry run mode you can disable or enable each of the following three options to bypass the dry run mode:

  - MANGA_TAGGER_DB_INSERT=false # if true, allow metadata insertion in db
  - MANGA_TAGGER_RENAME_FILE=false # if true, allow MT to rename the file ( from MANGA -.- CHAPTER.cbz to MANGA CHAPTER.cbz)
  - MANGA_TAGGER_WRITE_COMICINFO=false # if true allow, MT to write the comicinfo.xml into the cbz archive.

Each of theses 3 options are enabled by default unless you use dry run mode. So if you disabled dry run mode you shouldn't have to worry about theses options. You can ignore them.
Else you can try to enable dry run and disable or enable them.

As to why the output file isn't named in english, it's not possible yet. MT take the romaji name that it gets when it asks Anilist for metadata.

@CubeComming
Copy link
Author

CubeComming commented Nov 9, 2021

Okay, Thank you.
Sadly it doesn't work using the dry mode.
Is there no way to implement a variable which will en-/disable the rename funktion?

@GlassedSilver
Copy link

I'm super fine with Romaji, in fact I prefer it. What I don't like about this forced rename is that I lose the scanlation group tag in the square brackets.

I have FMD2 generate cbz's with these settings:

Screenshot 2022-04-04 225552

Which generates a file like this:

Himouto! Umaru-chan -.- Vol. 02 Ch. 031.5 - Umaru and Hood [Norway Scan, Dragon and Griffin].cbz

In my humble opinion that's the best filename this could possibly have. I see the Romaji name, the volume (if applicable/available), chapter - in this order it even sorts perfectly! Then comes the chapter title and the scanlation group.

Mind you this is just an example name. With Mangadex this naming works flawlessly so far.

Romaji name + chapter as a mere number without even the Ch. part and all the rest is quite a bit too little in my liking.

I'd appreciate having the no-rename option available at all times A LOT.

Please reconsider! Otherwise, so far from my testing this is an excellent app and together with your dockerized FMD2 variant I feel like I can finally call my manga software stack nearing a well-rounded state! <3

@GlassedSilver
Copy link

Another case where this would be VERY crucial to have is for fan colorations or "lewd edits" that uncensor some scenes.

Upon inspecting the code I noticed you would append a suffix to make sure that we don't overwrite the old file, which is good, but then it's hard to tell from that suffix which is which. Usually the source filename is pretty self-explanatory and parsing it and automating detection of coloration or uncensors might be very difficult to reliably pull off when that original filename already is very clear. IMHO FMD2's naming is pretty solid (so far).

@GlassedSilver
Copy link

The problem with DRY_RUN set to true and controlling the three other options manually is that when processing the CBZ, the manga name gets parsed correctly, but chapter recognition seems to be dependent on the rename having taken place?

Because without it I get this error:

2022-04-10 11:26:23,813 | Thread-1 22476255337272 | MangaTaggerLib.task_queue.SeriesHandler | INFO - Creation event for "/downloads/Himouto! Umaru-chan/Himouto! Umaru-chan -.- Vol. 01 Ch. 001 - Umaru and Onii-chan [Dragon and Griffin].cbz" will be added to the queue
2022-04-10 11:26:24,638 | MTT-3 22476263361336 | MangaTaggerLib.task_queue.QueueWorker | INFO - Pulling "file created" event from the queue for "/downloads/Himouto! Umaru-chan/Himouto! Umaru-chan -.- Vol. 01 Ch. 001 - Umaru and Onii-chan [Dragon and Griffin].cbz"
2022-04-10 11:26:25,640 | MTT-3 22476263361336 | MangaTaggerLib.MangaTaggerLib | INFO - Now processing "/downloads/Himouto! Umaru-chan/Himouto! Umaru-chan -.- Vol. 01 Ch. 001 - Umaru and Onii-chan [Dragon and Griffin].cbz"...
2022-04-10 11:26:25,641 | MTT-3 22476263361336 | MangaTaggerLib.MangaTaggerLib | INFO - Attempting to rename "Himouto! Umaru-chan -.- Vol. 01 Ch. 001 - Umaru and Onii-chan [Dragon and Griffin].cbz"...
2022-04-10 11:26:25,642 | MTT-3 22476263361336 | MangaTaggerLib.MangaTaggerLib | INFO - Filename was successfully parsed as ['Himouto! Umaru-chan', 'Vol. 01 Ch. 001 - Umaru and Onii-chan [Dragon and Griffin].cbz'].
2022-04-10 11:26:25,644 | MTT-3 22476263361336 | MangaTaggerLib.task_queue.QueueWorker | ERROR - Expecting value: line 1 column 1 (char 0)
Traceback (most recent call last):
File "/app/Manga-Tagger/MangaTaggerLib/task_queue.py", line 188, in process
MangaTaggerLib.process_manga_chapter(path, uuid.uuid1())
File "/app/Manga-Tagger/MangaTaggerLib/MangaTaggerLib.py", line 68, in process_manga_chapter
metadata_tagger(file_path, manga_details[0], manga_details[1], manga_details[2], logging_info)
File "/app/Manga-Tagger/MangaTaggerLib/MangaTaggerLib.py", line 270, in metadata_tagger
exceptions = json.load(exceptions_json)
File "/usr/lib/python3.8/json/__init__.py", line 293, in load
return loads(fp.read(),
File "/usr/lib/python3.8/json/__init__.py", line 357, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3.8/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python3.8/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
2022-04-10 11:26:25,645 | MTT-3 22476263361336 | MangaTaggerLib.task_queue.QueueWorker | WARNING - Manga Tagger is unfamiliar with this error. Please log an issue for investigation.

@GlassedSilver
Copy link

Okay I wiped my config folder and the db, that seemed to help I think? at least the file got parsed, but a) the source cbz didn't get moved and b) the target filename still is the same name as before.

Apparently this renaming toggle doesn't affect the resulting cbz? It's still %MANGA% %CHAPTERNUMBER(without volume or Ch. or anything)%.cbz

Bit of a letdown... would it have affected the jpgs inside the cbz? No point having a toggle for that if you ask me.

This is all very confusing if you ask me...

@Banh-Canh
Copy link
Member

Hello, I'll try to take the time to get around those issues. Just to be clear, among thoses issues you also want an option so MT doesn't rename file anymore, am I understanding it correctly ?

@GlassedSilver
Copy link

GlassedSilver commented Apr 10, 2022

Well, in my limited testing so far I'm narrowing down my solutions of applications to use to begin with that look most promising. I stumbled upon your Manga-Tagger because of two reasons:

a) manga tagging is a field left widely open to solutions to begin with sadly. There's metadata scraping solutions for many things, but manga are almost a forgotten area. So finding A solution was already pain enough. When I heard that Manga-Tagger (the OG you forked this from) is fully of dependencies I tried it out and lo and behold... I couldn't even get it to run.

b) You provide a containerized solution for FMD2, which I swear by. It's a wonderful program, very set-and-forget... You're doing everyone a major service here, let me tell you that. (also hats of to dynamically loading the latest release! Good foresight, because keeping up with releases manually is hopefully mostly unnecessary.) There's only few things I don't particularly like about FMD2. (mostly that if a manga has one chapter done by multiple groups it will download them all.)

So... My problems in my stack so far are:

The filename FMD2 outputs, at least with what I tested it with so far, is pretty much perfect. The chapter on Mangadex includes Volume, Chapter and the Chapter title as well as the scanlation group. (at least by what I checked so far, but I think that's how it's universally done since the Mangadex relaunch)

Kavita is my manga media manager and web UI. I use the Tachiyomi extension with it, because Tachiyomi is by far the best Android reader with active support and integrates into all sorts of things like sources, self-hosted media managers like Kavita, Komga, etc... and also it can scrobble your reads to AniList, MAL, Kitsu and your media manager like Komga and such. I think Kavita is supported as well. Didn't check on that one yet.

So so far the filename of FMD2 is pretty amazing, because it includes additional helpful info that otherwise is lost, so yeah an option to keep the filename and only move the file to the library location from the watch folder would be ideal. If you could set up the subfolders for the target as well, that'd be really awesome. E.g.:

/manga/%MANGA%/%VOLUME%/original-filename.cbz

Another thing I noticed is that pulling of art is a bit of a hot topic. The general manga art often is for a specific volume or before there are tankobon it's a promotional graphic. However, whilst Kavita supports volumes, if you supply the cover art for the entire series per chapter cbz then all your chapter previews end up being the cover art. It would be cool if the cover art could be loaded specific to the volume and put into the %CHAPTER% directory.

As I pointed out before the best source for HQ volume cover art seems to be Mangadex.

I know that's quite a lot of backstory and context and wishes, but if you don't mind I could tell you more one to one in a Discord call, because getting that sweet sweet perfect Manga software stack seems ever so close.

PS: I also noticed that writing the release date into the ComicInfo has a bit of a catch. If it's the original first release date, then it should only be written into the first chapter's info, because succeeding chapters almost never release on the same day. But I'm not 100% on whether the source you pull from has the release date of the first volume as in tankobon, so it might apply to more than one chapter that way. (doubt it though and it'd still be just the first chapter to really have the earliest possible release date if released in some weekly magazine.)

Sorry for the wall of text. D:

@GlassedSilver
Copy link

Any update on this per chance? :)

@ThePromidius
Copy link
Member

Any update on this per chance? :)

I have this planned

@GlassedSilver
Copy link

Oh, I have to add that I mistyped, obviously the volume cover art should be in the volume subfolder, not in the chapter, repeated (which is a cbz anyhow and not a folder, so maybe you got my drift anyhow)

Hope that clears up any possible confusion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: No status
Development

No branches or pull requests

4 participants