starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Bug]: Big comics are basically unusable at the moment #2307

New Issue
Open
opened 2026-04-25 00:05:55 +02:00 by adam · 13 comments
adam commented 2026-04-25 00:05:55 +02:00
Owner
Copy Link
Copy Source

Originally created by @kuldan5853 on GitHub (Oct 12, 2024).

What happened?

Since the server was fixed to be better at importing cbr/cbz comic books (no crashes anymore, thanks!), I have been trying to implement a comic library.

The built-in reader works okay for smaller books (20, 30mb filesize), but as soon as files get over in the multiple hundred MB range, they either load infinitely (never opening), or if they open (I tested this on a 200mb file), it can take up to 30-60 seconds for a single page turn, while the whole system basically becomes unresponsive.

This makes using the comic book feature basically unusable at the moment.

This was the same across the App and the Web client, so I assume it is a backend issue.

What did you expect to happen?

Smoother performance / working at all also for larger cb files

Steps to reproduce the issue

  1. Add a big comic book (300+ mb) to your library and try to open it.

When it (eventually) opens, try to scroll through more than a few pages.

Audiobookshelf version

v2.14.0

How are you running audiobookshelf?

Windows Tray App

What OS is your Audiobookshelf server hosted from?

Windows

If the issue is being seen in the UI, what browsers are you seeing the problem on?

None

Logs

No response

Additional Notes

No response

Originally created by @kuldan5853 on GitHub (Oct 12, 2024). ### What happened? Since the server was fixed to be better at importing cbr/cbz comic books (no crashes anymore, thanks!), I have been trying to implement a comic library. The built-in reader works okay for smaller books (20, 30mb filesize), but as soon as files get over in the multiple hundred MB range, they either load infinitely (never opening), or if they open (I tested this on a 200mb file), it can take up to 30-60 seconds for a single page turn, while the whole system basically becomes unresponsive. This makes using the comic book feature basically unusable at the moment. This was the same across the App and the Web client, so I assume it is a backend issue. ### What did you expect to happen? Smoother performance / working at all also for larger cb files ### Steps to reproduce the issue 1. Add a big comic book (300+ mb) to your library and try to open it. When it (eventually) opens, try to scroll through more than a few pages. ### Audiobookshelf version v2.14.0 ### How are you running audiobookshelf? Windows Tray App ### What OS is your Audiobookshelf server hosted from? Windows ### If the issue is being seen in the UI, what browsers are you seeing the problem on? None ### Logs _No response_ ### Additional Notes _No response_
adam added the bug label 2026-04-25 00:05:55 +02:00
adam commented 2026-04-25 00:05:55 +02:00
Author
Owner
Copy Link
Copy Source

@mikiher commented on GitHub (Oct 13, 2024):

Up until now we had issues with scanning some of these files, and now that they mostly got fixed on the server, we're starting to see some client issues (the client and the server used to use similar buggy versions of un-archiving libraries, now the server is fixed, but the client might still have issue).

We're aware of (at least some of) those issues, and we'll try to focus on solving them soon.

@mikiher commented on GitHub (Oct 13, 2024): Up until now we had issues with scanning some of these files, and now that they mostly got fixed on the server, we're starting to see some client issues (the client and the server used to use similar buggy versions of un-archiving libraries, now the server is fixed, but the client might still have issue). We're aware of (at least some of) those issues, and we'll try to focus on solving them soon.
adam commented 2026-04-25 00:05:55 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Oct 13, 2024):

I think that performance issues are bound to occur on larger comics since we are extracting the cbr/cbz on the client side. Comic images tend to be a large file size.
The reason it is useful to extract client side is we can make the comic reading available offline easier on mobile. The downside is this.

@advplyr commented on GitHub (Oct 13, 2024): I think that performance issues are bound to occur on larger comics since we are extracting the cbr/cbz on the client side. Comic images tend to be a large file size. The reason it is useful to extract client side is we can make the comic reading available offline easier on mobile. The downside is this.
adam commented 2026-04-25 00:05:56 +02:00
Author
Owner
Copy Link
Copy Source

@kuldan5853 commented on GitHub (Oct 13, 2024):

Thanks guys - I think as comic files can approach 500mb or more, this can become an issue - at least on the browser I can pretty easily put the server into an endless "please wait..." while simply flipping through pages..

Would it be possible to maybe make this a toggleable option to have server side rendering vs. client side rendering?

I assume some people would be happy with the tradeoff to invest cache ram / storage space on the server side if it means that the server only has to serve out single jpgs one at a time for performance reasons?

At any rate, comics are a side note to the whole server, so I can totally understand if it's not a priority.
When the import issues got fixed I just got a bit too excited ;)

@kuldan5853 commented on GitHub (Oct 13, 2024): Thanks guys - I think as comic files can approach 500mb or more, this can become an issue - at least on the browser I can pretty easily put the server into an endless "please wait..." while simply flipping through pages.. Would it be possible to maybe make this a toggleable option to have server side rendering vs. client side rendering? I assume some people would be happy with the tradeoff to invest cache ram / storage space on the server side if it means that the server only has to serve out single jpgs one at a time for performance reasons? At any rate, comics are a side note to the whole server, so I can totally understand if it's not a priority. When the import issues got fixed I just got a bit too excited ;)
adam commented 2026-04-25 00:05:56 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Oct 13, 2024):

I built that comic reader without looking into other projects that have a comic reader. I would be curious to know if other comic readers extract the images server side and reduce the file size.

I don't have any test comics that big so I haven't experienced the issue but can see how it would be slow. If it is getting stuck completely maybe you are coming across a bug and not just a performance issue.

@advplyr commented on GitHub (Oct 13, 2024): I built that comic reader without looking into other projects that have a comic reader. I would be curious to know if other comic readers extract the images server side and reduce the file size. I don't have any test comics that big so I haven't experienced the issue but can see how it would be slow. If it is getting stuck completely maybe you are coming across a bug and not just a performance issue.
adam commented 2026-04-25 00:05:56 +02:00
Author
Owner
Copy Link
Copy Source

@mikiher commented on GitHub (Oct 13, 2024):

@advplyr we know for a fact that libarchive (which still runs on the client) has some issues with some cbr files, just like it had when scanning those on he server, before we replaced it. Those files would seem to be stuck forever while opening on the client (I saw this when testing with some of these files).

The first order of things is to replace libarchive on the client as well, and at least some of the issues will go away.

In terms of performance, my gut feeling says is that we should be able to deal with large files like these. After all, we are dealing with gygabyte-sized audio files, aren't we? Perhaps we're doing something very inefficient with libarchive (we know we were loading the files fully into memory, before we switched to the new un-archivers that use streaming - perhaps this is what's also causing performance issues on the client).

@mikiher commented on GitHub (Oct 13, 2024): @advplyr we know for a fact that libarchive (which still runs on the client) has some issues with some cbr files, just like it had when scanning those on he server, before we replaced it. Those files would seem to be stuck forever while opening on the client (I saw this when testing with some of these files). The first order of things is to replace libarchive on the client as well, and at least some of the issues will go away. In terms of performance, my gut feeling says is that we should be able to deal with large files like these. After all, we are dealing with gygabyte-sized audio files, aren't we? Perhaps we're doing something very inefficient with libarchive (we know we were loading the files fully into memory, before we switched to the new un-archivers that use streaming - perhaps this is what's also causing performance issues on the client).
adam commented 2026-04-25 00:05:56 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Oct 13, 2024):

Ah yeah I forgot that libarchive is loading the full archive into memory and not streaming. Replacing that would be the first step before looking at serving the images server side.

Looking at node-unrar-js it doesn't look like that library is able to stream either. Archiver library for CBZ files would be able to stream but I'm not sure if that is supported for the browser.

@advplyr commented on GitHub (Oct 13, 2024): Ah yeah I forgot that libarchive is loading the full archive into memory and not streaming. Replacing that would be the first step before looking at serving the images server side. Looking at node-unrar-js it doesn't look like that library is able to stream either. Archiver library for CBZ files would be able to stream but I'm not sure if that is supported for the browser.
adam commented 2026-04-25 00:05:56 +02:00
Author
Owner
Copy Link
Copy Source

@mikiher commented on GitHub (Oct 13, 2024):

node-unrar-js does use streaming (it has two modes), and we use the streaming mode.

The only peculiarity of node-unrar-js, is that when you use the streaming mode, it can only write the unzipped output to file, and then you have to read it back to memory if you need it. I don't think that this is a limitation of the underlying unrar logic, only of the API. perhaps when I have time, I will add unzipToBuffer functionality, but that's not a high priority.

@mikiher commented on GitHub (Oct 13, 2024): node-unrar-js does use streaming (it has two modes), and we use the streaming mode. The only peculiarity of node-unrar-js, is that when you use the streaming mode, it can only write the unzipped output to file, and then you have to read it back to memory if you need it. I don't think that this is a limitation of the underlying unrar logic, only of the API. perhaps when I have time, I will add unzipToBuffer functionality, but that's not a high priority.
adam commented 2026-04-25 00:05:57 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Oct 13, 2024):

I was going off of the issue opened here https://github.com/YuJianrong/node-unrar.js/issues/164

@advplyr commented on GitHub (Oct 13, 2024): I was going off of the issue opened here https://github.com/YuJianrong/node-unrar.js/issues/164
adam commented 2026-04-25 00:05:57 +02:00
Author
Owner
Copy Link
Copy Source

@kuldan5853 commented on GitHub (Oct 13, 2024):

If I can help with anything (e.g. sharing some of the big comics I used to produce the issue) I can gladly share them.

@kuldan5853 commented on GitHub (Oct 13, 2024): If I can help with anything (e.g. sharing some of the big comics I used to produce the issue) I can gladly share them.
adam commented 2026-04-25 00:05:57 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Oct 13, 2024):

Thanks. It's always helpful to have more data to test with if you want to send me an email or a discord DM.

@advplyr commented on GitHub (Oct 13, 2024): Thanks. It's always helpful to have more data to test with if you want to send me an email or a discord DM.
adam commented 2026-04-25 00:05:57 +02:00
Author
Owner
Copy Link
Copy Source

@mikiher commented on GitHub (Oct 13, 2024):

I was going off of the issue opened here YuJianrong/node-unrar.js#164

I think the author was trying to explain that the unrar wasm is not ammenable to accept a standard Javascript ReadStream. However, the unrar does accept an Extractor abstract class that defines abstract read(), seek() and tell() methods. the Extractor class has two implementations, ExtractorData (which implements those methods using a memory buffer), and ExtractorFile (which implements the methods using actual file operations).

When I say it supports streaming, what I actually mean that when it uses ExtractorFile, (I think) it does not read the whole thing into memory at once, but rather uses the read(size) and seek() methods to read what it needs directly from the input file, without needing to read all of it into memory. Or in other words, it is using random access into files (in the case of ExtractorFile) as it needs.

I haven't read the code too carefully, but I think this is how it works.

@mikiher commented on GitHub (Oct 13, 2024): > I was going off of the issue opened here [YuJianrong/node-unrar.js#164](https://github.com/YuJianrong/node-unrar.js/issues/164) I think the author was trying to explain that the unrar wasm is not ammenable to accept a standard Javascript `ReadStream`. However, the unrar does accept an `Extractor` abstract class that defines abstract `read()`, `seek()` and `tell()` methods. the `Extractor` class has two implementations, `ExtractorData` (which implements those methods using a memory buffer), and `ExtractorFile` (which implements the methods using actual file operations). When I say it supports streaming, what I actually mean that when it uses `ExtractorFile`, (I think) it does not read the whole thing into memory at once, but rather uses the `read(size)` and `seek()` methods to read what it needs directly from the input file, without needing to read all of it into memory. Or in other words, it is using random access into files (in the case of ExtractorFile) as it needs. I haven't read the code too carefully, but I think this is how it works.
adam commented 2026-04-25 00:05:58 +02:00
Author
Owner
Copy Link
Copy Source

@mikiher commented on GitHub (Oct 13, 2024):

If I can help with anything (e.g. sharing some of the big comics I used to produce the issue) I can gladly share them.

Please share with me as well.

@mikiher commented on GitHub (Oct 13, 2024): > If I can help with anything (e.g. sharing some of the big comics I used to produce the issue) I can gladly share them. Please share with me as well.
adam commented 2026-04-25 00:05:58 +02:00
Author
Owner
Copy Link
Copy Source

@KapUttyy commented on GitHub (Aug 2, 2025):

Hey there! Is and work on this progressing? I am currently thinking of managing my comics with ABS, but with the files > 200 MB, I am not able to open them neither with Brave or Safari on MacOS, nor with the ABS App on iOS or Brave on Windows. It is in Please Wait state forever.

@KapUttyy commented on GitHub (Aug 2, 2025): Hey there! Is and work on this progressing? I am currently thinking of managing my comics with ABS, but with the files > 200 MB, I am not able to open them neither with Brave or Safari on MacOS, nor with the ABS App on iOS or Brave on Windows. It is in Please Wait state forever.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#2307
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?