UUID filenames instead of comic titles

[HeartofSteel]

Hello,

I'm having an issue backing up any comics from comixology. I backed up dozens last year, but ever since the new update, I haven't been able to backup any properly. Instead of saving in the usual cbz format, they save as file codes titled "a51ee388-7632-4d3b-8384-b7d653d3aec4" and other names like that one.

At first, I assumed it was the comic length, but even normal comics that 23-27 pages produce the same results. I have the most updated version of both Chrome and Comixology Backup. I'm using Windows 10. Saving in CBZ format. Jpg page format. Minimum page swap interval is 600 ms. Page skip delay is 1200 ms.

Please help. I have no idea what could be causing this.

Thank you!

[Cortys]

Hi! Sorry for the late response.

Could you try reinstalling the extension and make sure you are not using incognito mode for backups?

If that does not help please send me a screenshot of the extension options page.

[Cortys]

Closing due to inactivity.

[sgbeal]

FWIW, i've been seeing this "wrong naming" behaviour for at least 18 months. i always pull the latest version from github and never use Incognito mode to do backups. The backup has not, in a very long time, named my CBZs "properly" - they're just some sort of hash or UUID (like the OP says). They're not broken, per se - i simply have to rename them manually.

Edit: i've seen this happen as recently as a week ago.

[Cortys]

I see. For some reason I'm not able to reproduce this. Could you maybe test this in combination with the download directory feature @ReAnzu implemented (finally merged it...)?

Are comics downloaded to ~/Downloads/[UUID].cbz or to ~/Downloads/[download dir]/[UUID].cbz or something else?

[sgbeal]

i will try it out in just a few moments. Before that update, the files are named simply named ~/Downloads/UUID (with no extension). Current platform: Linux Mint 19 using Chrome (Version 67.0.3396.99 (Official Build) (64-bit)). i'll report back soon.

[sgbeal]

i just re-scanned a book using the current (after you merged #71). To confirm that i have the latest version (the version number still says 2.4.0, which i think it said before i updated), i configured a backup directory name. It scanned book but it did not create the newly-defined backup directory, placing the scanned book directly in the Downloads folder. The scanned file is named 6306272d-ff47-4ad9-b458-226ce50b18f1 and is a valid CBZ file.

i'm happy to provide you with more info about what it's doing if you can tell me how to do so.

[sgbeal]

PS: this happens 100% of the time since at least 18 months. It's not limited to a specific length of book - most of mine are 30 pages or less, but it also happens with books having 120+ pages. It's not a huge problem, just slightly annoying.

[Cortys]

I think we have to figure out which component of your setup is causing this. OS, Browser, Extensions, Hardware (CPU arch, maybe memory).

In #68 the issue was caused by an extension. I'm assuming that's not it this time. Can you reproduce the issue on Windows and/or Mac OS?

[sgbeal]

i don't have a commercial OS to try it on, but i just tried several things out and have some new info;

(EDITS: slight corrections/clarifications)

i use the Chrono download manager. If i disable that extension then this problem goes away but two new problems arise:

1) after scanning is complete, Chromium prompts (via a file dialog) for where to download the scanned file to. This makes it impossible to queue up downloads and continue working on something else because when i'm typing (e.g. in this input field) and the file dialog pops up, it steals focus and overwrites the suggested filename name. The suggested filename IS correct except for...

2) If the download directory is NOT set then the recommended filename is prefixed with "undefined" (presumably from the unspecified download directory field). So the book ABC.cbz gets the suggested name undefinedABC.cbz. If the download directory is set, that directory gets created if needed (as expected). However, when the file dialog pops up and suggests a name, it's likely that the name gets destroyed because i'm typing in another app when the file dialog steals focus and my typing overwrites the suggested name.

So the main problem here is the use of a download manager. If the download manager is enabled, downloads are automatically saved, without prompting via a file dialog, but they are mis-named. If the download manager is disabled, the names are correct but every scan prompts for where to save the file. If i have to choose between those two behaviours, i'll choose the one which doesn't prompt me with a file dialog.

i tried this in both Chrome and Chromium, with the same results. Except that...

While typing this in, i let it run again (in Chrome, with the DL manager disabled) and this time it saved the file automatically with the correct name, but prefixed the name with "undefined" (the download directory). After setting a download dir and trying it again, it did exactly what was expected: it automatically downloaded the book, with the correct name, to the newly-defined download directory.

i just repeated that last test again in Chrome and Chromium, with a download directory defined, and: in Chrome it downloads silently (as expected) but in Chromium it prompts me with a file dialog (but i was typing in this github field when the dialog stole focus, so the suggested book name was immediately overwritten by what i was trying to type in this field).

Weird.

A final test: if i manually set the download dir, then manually unset it, the "undefined" prefix problem goes away - presumably because it gets set to an empty string when it is manually cleared. Chromium still prompts me with a file dialog and Chrome does not.

Chrome: Version 68.0.3440.75 (Official Build) (64-bit) Chromium: Version 68.0.3440.106 (Official Build) Built on Ubuntu , running on LinuxMint 19 (64-bit)

TL;DR: this whole problem seems to be a misinteraction with a download manager. Chromium prompting with a file dialog for where to save every book is a separate problem.

[Cortys]

Thanks! The "undefined" bug slipped through and is fixed now.

I just tried Chromium (same build) but could not reproduce the file dialog. Could you check whether you have the "Ask where to save each file before downloading" option enabled?

Regarding the download manager, I'll have a look at it. Maybe there's a simple fix that'll let both extensions work together nicely.

[sgbeal]

Doh, facepalm :/. Sure enough, that setting was on for that one installation of Chromium. (It was a fresh install with no customized options beyond the extensions.)

So, problem solved:

1) Disable download manager extensions while using this extension.

2) Disable the "Ask where to save each file before downloading" option.

:)

[Cortys]

I think I found a simple solution for the Chrono Download Manager problem. The filename is now included in the anchor of all downloaded comic blobs. This makes it possible to write a rule in Chrono, to properly name downloads.

This can be tested (using the latest master version) by adding a rule like this:

The only downside to this solution is, that all comics will be placed into a folder named "comic-backup". This means that the download directory setting will be relative to ~/Downloads/comic-backup/ instead of ~/Downloads/.

[sgbeal]

:-D. Trying it out now...

Chrono: Display name = Comics Internal name = r_comic Condition = *anchor*.beginWith("comic-backup") Naming mask = *anchor*

comic-backup: Download directory = comic-backup/

...

Nope - they're all downloading as ~/Downloads/UUID. i tried with a blank download dir as well, but the same behaviour.

No big deal - i can remember to disable Chrono when needed. i normally only buy comics in batches 3 or 4 times a year, so i don't need to do this that often.

Tested only on Chrome, not Chromium.

[Cortys]

It should be beginwith all lowercase.

[sgbeal]

Aha! (and i thought it should probably be beginsWith(), with an "s"!). Here we go:

Condition = anchor.beginwith("comic-backup") Download directory = blank ...

OMG, it works :). i dislike the idea of you having to hard-code the dir name "comic-backup" in there, but having the directory automatically named the same as the app's git repo also seems reasonable to me. It also makes the new download dir kind of obsolete, since there will never(?) be a need for multiple levels of download dir.

[Cortys]

The only reason for the hardcoded "comic-backup" is to make it possible to detect downloads coming from this extension. I have not yet found another way to make identification possible. If you find one, the prefix can of course be removed.

You are right about the download dir option being useless in this case. But since the "comic-backup" dir is only used when Chrono is active, it does not affect all users. Also other download managers might allow smarter naming rules than Chrono and make it possible to use something like substring to cut away the prefix. I don't know if there is such a download manager, but in that case there would be no discernible difference between Download Manager vs no Download Manager.

[Cortys]

2.4.0 is now finally released. It includes a fix for this issue.