Quick update – some of the comics in my restored DB are now showing the same
issue.
It strikes me as similar to another issue that occurred last year – but I can’t
recall exactly what that was.
From: Guy Incognito
Sent: Thursday, 1 October 2020 9:19 AM
To: comixed-dev@xxxxxxxxxxxxx
Subject: [comixed-dev] Re: 0.7rc - library consolidation (again).
Appeared to be inconsistent.
I’ll need to try again and make notes. Likely won’t be able to try again for a
few days, as I’ll need to recover my DB and re-scrape a few comics.
On 1/10/2020, at 12:57 AM, Darryl L. Pierce <mcpierce@xxxxxxxxx> wrote:
Is it consistently the same source comics that result in this, or does
it move across comics?
On Wed, Sep 30, 2020 at 6:26 AM Guy Incognito
<dmarc-noreply@xxxxxxxxxxxxx> wrote:
The odd thing about them is that they’re only 0-byte once extracted by CX
for cover images. Trying to extract the cover via CMD line zip also fails.
Opening them via a zip gui works fine, as does opening the files via Cover.
Importing them into CX (either in a clean DB, or an existing one once the
relevant records were removed) works fine as well.
No other tasks were running – once I start a consolidation, I leave CX to do
it’s thing for a few hours or so.
As nobody else appears to have experienced this, I’m going to leave it for
now – I’ve managed to corrupt my DB somehow, so will be doing a restore from
a backup and then tidying things up again.
From: Darryl L. Pierce
Sent: Wednesday, 30 September 2020 3:01 AM
To: comixed-dev@xxxxxxxxxxxxx
Subject: [comixed-dev] Re: 0.7rc - library consolidation (again).
Are the files with the 0-byte images being created by CX as a part of
the library consolidation? And, are there any other tasks (import,
conversion) running when the consolidation starts? I've still got the
work to do to prevent imports, conversion and consolidations from
being enqueued together; i.e., if any task of one type are running
then block the others from being started. This can lead to some
non-deterministic behavior like you're seeing.
On Mon, Sep 28, 2020 at 8:39 PM Guy Incognito
<dmarc-noreply@xxxxxxxxxxxxx> wrote:
Not entirely sure what’s going on here, or how to investigate it.
Following a library consolidation (involving deletions and renaming), some
comics are being put into the base comics directory, and not in the
directory structure in the naming convention. Not many, only 11 out of
2.8k or so.
Most, but not all, of these comics no longer display a cover image. Note
that this is not the “cover not found” default image, but an incomplete
image pane. Looking at the image directory, the image files (named with
the last 8 characters of the page hash) have a file size of 0.
Attempting to export the images via CMD un-zip fails. Opening them via a
zip gui works fine. Cover (a windows comic reading app) opens the files
fine.
Attempting to re-import the comics into CX (both in a clean database and in
an existing one, after deleting the problem records) works as expected.
This is the second time this has occurred. The first time, I figured it
was some sort of file corruption during the backing up and moving of my
comics library.
The only way I’ve found to identify the problem comics is to extract all
the cover images (I have a SQL script that helps me pre-populate the cover
images), and then look for files with a size of 0, then work my way back to
find the file names so I can delete the records. Then run an import again.
Problem is then solved...until I run an consolidation again.
--
Darryl L. Pierce <mcpierce@xxxxxxxxx>
"Le centre du monde est partout." - Blaise Pascal
"Let's try and find some point of transcendence and leap together." -
Gord Downie
--
Darryl L. Pierce <mcpierce@xxxxxxxxx>
"Le centre du monde est partout." - Blaise Pascal
"Let's try and find some point of transcendence and leap together." -
Gord Downie
