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

[PR #3422] [MERGED] Catch file extraction errors in parseComicMetadata #3969

New Issue
Closed
opened 2026-04-25 00:17:46 +02:00 by adam · 0 comments
adam commented 2026-04-25 00:17:46 +02:00
Owner
Copy Link
Copy Source

📋 Pull Request Information

Original PR: https://github.com/advplyr/audiobookshelf/pull/3422
Author: @mikiher
Created: 9/15/2024
Status: ✅ Merged
Merged: 9/15/2024
Merged by: @advplyr

Base: master ← Head: parse-comic-metadata-try-catch

📝 Commits (1)

  • 0b31792 catch file extraction errors in parseComicMetadata

📊 Changes

1 file changed (+51 additions, -43 deletions)

View changed files

📝 server/utils/parsers/parseComicMetadata.js (+51 -43)

📄 Description

This partially fixes #3406, fixes #3399, fixes #2526 by catching file-extraction related exceptions in parseComicMetadata functions and preventing scan failure.

This is just adding straightforward try-catch block around the code.

However, there's the more general question of libarchive. It seems we have multiple reports of it throwing exceptions while trying to extract files from cbr/cbz files. Some observations:

  • It looks like it is only used for comic file extraction on the server.
  • While libarchive throws exceptions on some cbr files, it looks like 7zip has no issues reading and extracting those files.
  • Another potential issue is that we need to read the whole archive file into memory and pass it to libarchive. This is not how modern archivers should work, and can potentially get us into memory issues.

On the client, I'm even more confused regarding what's happening with libarchive - we have some mix of an installed libarchive npm package (v1.3.0), and some libarchive code in client/static, both of which (!) seem to be used in ComicReader.vue.

Also after fixing the server failures, the offending CBR book is successfully added to library, but then crashes with the same libarchive error on the client when trying to read the book.

Any insights or suggestions on how to proceed?

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/advplyr/audiobookshelf/pull/3422 **Author:** [@mikiher](https://github.com/mikiher) **Created:** 9/15/2024 **Status:** ✅ Merged **Merged:** 9/15/2024 **Merged by:** [@advplyr](https://github.com/advplyr) **Base:** `master` ← **Head:** `parse-comic-metadata-try-catch` --- ### 📝 Commits (1) - [`0b31792`](https://github.com/advplyr/audiobookshelf/commit/0b31792660590c063e41f3c0222912c9440a36e8) catch file extraction errors in parseComicMetadata ### 📊 Changes **1 file changed** (+51 additions, -43 deletions) <details> <summary>View changed files</summary> 📝 `server/utils/parsers/parseComicMetadata.js` (+51 -43) </details> ### 📄 Description This partially fixes #3406, fixes #3399, fixes #2526 by catching file-extraction related exceptions in parseComicMetadata functions and preventing scan failure. This is just adding straightforward try-catch block around the code. However, there's the more general question of `libarchive`. It seems we have multiple reports of it throwing exceptions while trying to extract files from cbr/cbz files. Some observations: - It looks like it is only used for comic file extraction on the server. - While libarchive throws exceptions on some cbr files, it looks like 7zip has no issues reading and extracting those files. - Another potential issue is that we need to read the whole archive file into memory and pass it to libarchive. This is not how modern archivers should work, and can potentially get us into memory issues. On the client, I'm even more confused regarding what's happening with libarchive - we have some mix of an installed libarchive npm package (v1.3.0), and some libarchive code in client/static, both of which (!) seem to be used in ComicReader.vue. Also after fixing the server failures, the offending CBR book is successfully added to library, but then crashes with the same libarchive error on the client when trying to read the book. Any insights or suggestions on how to proceed? --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
adam added the pull-request label 2026-04-25 00:17:46 +02:00
adam closed this issue 2026-04-25 00:17:46 +02:00
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 pull-request
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#3969
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?