[Bug]: problem to load cbr or cbz files

[Duke715]

Preflight Checklist

• I have searched the issue tracker for a bug report that matches the one I want to file, without success.

OpenComic Version

1.5.0

Operating System

windows 11

Installed via

.exe

Steps to reproduce

when you try to open big compressed files nothing happen..or it's too slow
for example 10 folders with 150 files each compressed .cbr or .cbz

Expected Behavior

i would like instant opening when i use big files

Actual Behavior

too slow or froze

Error message

No response

Additional Information

No response

Sample file

No response

[Duke715]

the old version 1.4.1 you gave me work much better

[ollm]

It may be due to the fact that the new version supports extracting multiple different files at the same time. This can increase speed in most cases, but it could slow things down on solid and slow hard drives.

Try this build, it has multi-threaded extraction disabled.

Build: https://mega.nz/file/DCREjKAS#JUQA9s6XIFVtgvQabSneLPuyNqFLA_ls9C3YdUsk5pQ

[Duke715]

Oh wow......it's much faster on that version......i can't find a way to close fast the program when i'm full screen.....good job and thank you for your help

[ollm]

I've made some changes to try to detect whether a hard drive is an HDD or an SSD, and to use multithreading or not depending on the case a4874a6.

I've done some extraction speed tests to see the difference, and here are the results:

Extraction Performance Test (32 files × 331 MB = 10.6 GB)
System: Linux Ubuntu 24.04

Drive Type	Multi-thread	Single-thread	Auto-detect
NVMe	14.2s	49.2s	14.7s
SSD	20.4s	51.1s	20.9s
HDD	145.1s	84.5s	82.0s

As you can see, using multithreading on an HDD is actually slower, since reading from multiple files at once slows down HDDs. The difference is probably even greater when the main hard drive (where extraction happens) is also an HDD, mine is an NVMe, so only the reading part was tested.

If you want to try it, I'll leave a build on the master branch.

Build: https://mega.nz/file/ePxhAALS#Xo3ofl-Kkty-snb8Y_oKNqYDJsnot_cct2OVDY1k72w

i can't find a way to close fast the program when i'm full screen

Currently, the only thing you can do is set a shortcut or tap zone to the gamepad menu and close OpenComic from there.

[Duke715]

i will try this new build....i have not "close opencomic"....what kind of menu is that?
Anyway with the single thread extraction build is super fast now...it's almost perfect ...there is another small bug
but it's irrevelant...Great comic reader, good job!!!!

[ollm]

This is a menu for use with a Gamepad/Controller, but you can set it as a shortcut for any key from the app settings and for any tap zone, for example you can have it appear when you press right click in the top center instead of the current context menu.

[fhadeboer]

I've made some changes to try to detect whether a hard drive is an HDD or an SSD, and to use multithreading or not depending on the case a4874a6.

I've done some extraction speed tests to see the difference, and here are the results:

Extraction Performance Test (32 files × 331 MB = 10.6 GB) System: Linux Ubuntu 24.04

Drive Type Multi-thread Single-thread Auto-detect
NVMe 14.2s 49.2s 14.7s
SSD 20.4s 51.1s 20.9s
HDD 145.1s  84.5s   82.0s 
As you can see, using multithreading on an HDD is actually slower, since reading from multiple files at once slows down HDDs. The difference is probably even greater when the main hard drive (where extraction happens) is also an HDD, mine is an NVMe, so only the reading part was tested.

If you want to try it, I'll leave a build on the master branch.

I was suffering from the same issue. 1.4 worked fine. 1.5 completely refused to open files. The master branch version solved the issue.
Just wanted to chime in that HDD vs SDD isn't the only issue. I have my files on a NAS which seems to have run into the same issue.

Yours,

[Duke715]

ohhh that's cool.....this version is 1.5.0?

[ollm]

I was suffering from the same issue. 1.4 worked fine. 1.5 completely refused to open files. The master branch version solved the issue.
Just wanted to chime in that HDD vs SDD isn't the only issue. I have my files on a NAS which seems to have run into the same issue.
Yours,
Originally posted by @fhadeboer

I've changed the default disk type fallback from SSD to HDD when detection fails a61dd0e, since this is likely the scenario with NAS connections. If this still doesn't resolve the issue with NAS setups, I'll consider adding an option in the settings to disable multi-threaded extraction.

Build: https://mega.nz/file/ffoQgJRb#pN4E6UUi8C1ZY9uDRjUCGGnWyaITz0xECVrUtFSh9rY

ohhh that's cool.....this version is 1.5.0?
Originally posted by @Duke715

This build is an interim version, between v1.5.0 and the upcoming v1.6.0.

[ollm]

Closing this, since the fix is now available in v1.6.0

If the problem persists, feel free to open a new issue or comment on this one.