search

binarynonsense / comic-book-reader

ACBR - A comic book reader and converter for CBZ, CBR, CB7, EPUB and PDF files (Windows & Linux)
BSD 2-Clause "Simplified" License
182 stars 8 forks source link

Unrecognized last pages in cbz file #172

Closed Vortm4x closed 1 month ago

Vortm4x commented 2 months ago

Reader doesn't recognize last pages for this file. For me it shows that there 100 pages, but the actual number is 186, the application skips last 86 pages
ACBR

image


CDisplayEx

image
binarynonsense commented 2 months ago

Are you using the Windows or Linux version? It's showing correctly for me on Linux... will try it on Windows later.

image

I had a similar problem once with one file, it was very strange because if I renamed the file, moved it to another folder or made a copy, those were working fine... could you try that and see what happens?

binarynonsense commented 2 months ago

Just tried it on Windows and can't reproduce it either with the latest version of ACBR, shows the correct number of pages (186), quite strange:

winscreen

Vortm4x commented 2 months ago

Are you using the Windows or Linux version? It's showing correctly for me on Linux... will try it on Windows later.

image

I had a similar problem once with one file, it was very strange because if I renamed the file, moved it to another folder or made a copy, those were working fine... could you try that and see what happens?

I used it on Win11, installed from SFX archive

binarynonsense commented 2 months ago

If you can, let me know what happens if you rename the file and open it or make a copy and open that copy (or even a copy of the file with the same name as the original)... As I mentioned, some time ago something similar happened to me with a particular file in one machine (in that case a Linux one) and only with that exact file in that exact folder with that exact name... really weird, and never managed to reproduce it either in my dev machine or find a logical reason (at first I thought it could be some strange issue related to the file path encoding, the image file names... but the fact that those tests worked meant that wasn't the case) so I ended up giving up on finding an explanation for that one back then as I never had anything like that happen again.

That's the closest bug/weirdness I've experienced similar to yours that comes to mind. Although without being able to reproduce it either I can't think of a way to figure it out right now, any clue (no matter how random it may seem) could be helpful.

You can also try launching ACBR in dev mode (with the command line option --dev) and see if the output shows any errors while using that file (that didn't help in my case, but who knows).

binarynonsense commented 2 months ago

I found the file that works incorrectly in one of my computers and I think renaming the file works but a copy with the same name doesn't (I was convinced it did back then), so it could still have something to do with file names, string lengths... in a particular combination, a bug related to that or other thing with the decompression library (7z)... I'm still a bit lost (wish I could replicate it on my dev PC, this one has no space left to install the tools I need) but the more clues I can gather the better the odds of figuring it out.

binarynonsense commented 2 months ago

A bit of good news: I didn't manage to reproduce your bug with your file, but I managed to reproduce the one I experienced some time ago (which seems very similar) in my dev machine with the file I had a problem with in the past.

These are my findings so far: it only happens if the path is exactly the same as I had in the other machine (folder and file name) and only happens when using 7z to read the file entries inside the zip (I used to use another library for zips but I changed it to 7z because the other one didn't support files bigger than 2GB, so I just reenabled it to do the tests and the problem isn't there). So it seems to related to a weird combination of having a particular file path (length/letters...???) and using this library that only happens in very rare/specific cases... but I'm not 100% sure yet, just my first impressions.

If I can't pinpoint another reason, one within my code, to cause the issue, the 7z binaries package from npm I use hasn't been updated in quite a while BUT I just saw that there's a recent pull request for an update, so if that gets approved some day I may try updating it to see if that fixes the problem. I could also add an option to ACBR to let users choose the decompression library to use when opening zips (the old one with the 2GB limitation or the 7z binaries with this rare to experience but annoying problem) in case I don't find a better solution.

binarynonsense commented 2 months ago

I found a way to fix the bug I could replicate (and probably yours then) using a different method from the library to list the files inside a zip. The one I was using let me also know if a password was needed but was more obscure/not so well documented and wasn't probably meant for what I was using it (although I still suspect it has a bug, because it works perfectly fine most of the time for listing the files), so changing to the more common one seemed to do the trick (and I think it's quicker). I had to figure out a different way to detect password protected files in some situations but everything appears to be working fine now.

I've just release a new version with these changes, 3.6.3, so let me know if you try it and also fixes your issue.

binarynonsense commented 1 month ago

It's been a week since I released the fix so, given the lack of feedback, I'm going to assume it works and close the issue. Let me know here either way if you have the chance but, hopefully, everything is ok now.

Vortm4x commented 1 month ago

Sorry for such a large delay Yes, that was the same bug and issue has been fixed in the new release

binarynonsense commented 1 month ago

Great, thanks for testing it and letting me know it works for you too.