[Bug]: Recurring crash #1780

@sveinbjornpalsson commented on GitHub (Feb 28, 2024):

I've set log level to debug. First thing I did was to run docker-compose, but I don't think it upgraded, I think it was already on latest release (2.8.0)
I just opened the ios client, it seemed to work, it's still up.

@sveinbjornpalsson commented on GitHub (Feb 28, 2024): I've set log level to debug. First thing I did was to run docker-compose, but I *don't think* it upgraded, I *think* it was already on latest release (2.8.0) I just opened the ios client, it seemed to work, it's still up.

adam commented

@nichwall commented on GitHub (Feb 28, 2024):

So there used to be a file at that location, but then you moved it and now it's crashing the server?

@nichwall commented on GitHub (Feb 28, 2024): So there used to be a file at that location, but then you moved it and now it's crashing the server?

adam commented

@sveinbjornpalsson commented on GitHub (Feb 28, 2024):

So there used to be a file at that location, but then you moved it and now it's crashing the server?

Funny thing is, this crash is recent, but those changes were made quite a while ago.

@sveinbjornpalsson commented on GitHub (Feb 28, 2024): > So there used to be a file at that location, but then you moved it and now it's crashing the server? Funny thing is, this crash is recent, but those changes were made quite a while ago.

adam commented

@nichwall commented on GitHub (Feb 28, 2024):

Does the book exist in your ABS library (shows up without scanning)? If so, does it show up as missing or let you interact with it?

@nichwall commented on GitHub (Feb 28, 2024): Does the book exist in your ABS library (shows up without scanning)? If so, does it show up as missing or let you interact with it?

adam commented

@sveinbjornpalsson commented on GitHub (Mar 1, 2024):

No. I searched for it when I saw the error. No registration of it. Which is
also strange, I haven’t deleted anything. Or I don’t think I have?

On Wed, 28 Feb 2024 at 13:55, Nicholas W @.***> wrote:

Does the book exist in your ABS library (shows up without scanning)? If
so, does it show up as missing or let you interact with it?

—
Reply to this email directly, view it on GitHub
https://github.com/advplyr/audiobookshelf/issues/2686#issuecomment-1969037473,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABY7EL3W5YXPWQZRNRIBTY3YV4ZOJAVCNFSM6AAAAABD6ARPHKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRZGAZTONBXGM
.
You are receiving this because you authored the thread.Message ID:
@.***>

@sveinbjornpalsson commented on GitHub (Mar 1, 2024): No. I searched for it when I saw the error. No registration of it. Which is also strange, I haven’t deleted anything. Or I don’t think I have? On Wed, 28 Feb 2024 at 13:55, Nicholas W ***@***.***> wrote: > Does the book exist in your ABS library (shows up without scanning)? If > so, does it show up as missing or let you interact with it? > > — > Reply to this email directly, view it on GitHub > <https://github.com/advplyr/audiobookshelf/issues/2686#issuecomment-1969037473>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABY7EL3W5YXPWQZRNRIBTY3YV4ZOJAVCNFSM6AAAAABD6ARPHKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRZGAZTONBXGM> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

adam commented

@mikiher commented on GitHub (Mar 2, 2024):

There's another thing I don't understand about the logs above

[LibraryScanner] Starting (forced) library scan 05246d51-dacf-4a88-aafd-9b90c897b4de for Fiction

Who initiated the forced library scan? As far as I understand, the force-rescan option doesn't even exist anymore on the client in recent versions, it's only available through the API. The round hour (13:00:00) on the log entry maybe suggests that the scan was started by the CronManager (although AFAIK the CronManager does not start a forced scan either).

Have you set up an automated scanning schedule on the 'Fiction' library? This is a possible reason why these crashes might happen even while you're not directly interacting with the server.
Can you attach the crash_logs.txt file (it's under <your_metdata_dir>/logs)? I want to see the stack trace of the crash/es.

@mikiher commented on GitHub (Mar 2, 2024): There's another thing I don't understand about the logs above `[LibraryScanner] Starting (forced) library scan 05246d51-dacf-4a88-aafd-9b90c897b4de for Fiction` Who initiated the forced library scan? As far as I understand, the force-rescan option doesn't even exist anymore on the client in recent versions, it's only available through the API. The round hour (13:00:00) on the log entry maybe suggests that the scan was started by the CronManager (although AFAIK the CronManager does not start a forced scan either). - Have you set up an automated scanning schedule on the 'Fiction' library? This is a possible reason why these crashes might happen even while you're not directly interacting with the server. - Can you attach the crash_logs.txt file (it's under <your_metdata_dir>/logs)? I want to see the stack trace of the crash/es.

adam commented

@sveinbjornpalsson commented on GitHub (Mar 2, 2024):

It scans every hour according to settings. I can't remember if I pressed the scan button in Settings > Libraries. Here's the log, hope hit helps?
It's been stable since I started this thread.

crash_logs.txt

@sveinbjornpalsson commented on GitHub (Mar 2, 2024): It scans every hour according to settings. I can't remember if I pressed the scan button in Settings > Libraries. Here's the log, hope hit helps? It's been stable since I started this thread. [crash_logs.txt](https://github.com/advplyr/audiobookshelf/files/14468923/crash_logs.txt)

adam commented

2026-04-24 23:58:08 +02:00

@mikiher commented on GitHub (Mar 9, 2024):

Sorry for nagging again, but the unfortunately crash the logs didn't provide me with much additional info.

Can you please also attach the crashed library scan log?
It should be at <your_metadata_dir>/logs/scans/2024-02-28_05246d51-dacf-4a88-aafd-9b90c897b4de.txt

Hopefully it will provide me with some more info regarding what happened right before the crash.

Also, since the crash most probably happens during an automated scan, then as a workaround until we figure the root cause, you can disable the automatic scans for that library. This will most likely stop the recurring crashes.

Also, if the folders for this library are local (i.e. not network mounted), then the watcher is capable of detecting new additions to the library, and there's no need for an automated scan at all. However if the library folders are remote, you indeed need the scan, since watchers will likely not detect changes.

@mikiher commented on GitHub (Mar 9, 2024): Sorry for nagging again, but the unfortunately crash the logs didn't provide me with much additional info. Can you please also attach the crashed library scan log? It should be at <your_metadata_dir>/logs/scans/2024-02-28_05246d51-dacf-4a88-aafd-9b90c897b4de.txt Hopefully it will provide me with some more info regarding what happened right before the crash. Also, since the crash most probably happens during an automated scan, then as a workaround until we figure the root cause, you can disable the automatic scans for that library. This will most likely stop the recurring crashes. Also, if the folders for this library are local (i.e. not network mounted), then the watcher is capable of detecting new additions to the library, and there's no need for an automated scan at all. However if the library folders are remote, you indeed need the scan, since watchers will likely not detect changes.

adam commented

@geminica commented on GitHub (Mar 10, 2024):

I have a similar issue. I moved some epubs to a different directory and now scan crashes. The logs/scan file doesn't show the errors; similar to the OP I get the logged error about failure to extract with "no such file or directory" and then it becomes FATAL immediately after. I haven't finished setting up a dev environment but suspect that on this line, the containerJson can be null and would need to be containerJson? in order to avoid failure?

https://github.com/advplyr/audiobookshelf/blob/0d9d2fa4be9b642f0948e52ddff71ff370fd524d/server/utils/parsers/parseEpubMetadata.js#L73

@geminica commented on GitHub (Mar 10, 2024): I have a similar issue. I moved some epubs to a different directory and now scan crashes. The logs/scan file doesn't show the errors; similar to the OP I get the logged error about failure to extract with "no such file or directory" and then it becomes FATAL immediately after. I haven't finished setting up a dev environment but suspect that on this line, the `containerJson` can be null and would need to be `containerJson?` in order to avoid failure? https://github.com/advplyr/audiobookshelf/blob/0d9d2fa4be9b642f0948e52ddff71ff370fd524d/server/utils/parsers/parseEpubMetadata.js#L73

adam commented

2026-04-24 23:58:08 +02:00

@mikiher commented on GitHub (Mar 10, 2024):

Thanks for the info.

I will try to reproduce the way you described.

Regarding containerJson - you're right that it needs to be checked before accessing it, but accessing a null reference doesn't produce an exception like the one we see. However, this means that the code hasn't even reached that point, which means the fatal failure is happening somewhere right before that, but after the ERROR. That narrows it down quite a bit.

@mikiher commented on GitHub (Mar 10, 2024): Thanks for the info. I will try to reproduce the way you described. Regarding `containerJson` - you're right that it needs to be checked before accessing it, but accessing a null reference doesn't produce an exception like the one we see. However, this means that the code hasn't even reached that point, which means the fatal failure is happening somewhere right before that, but after the ERROR. That narrows it down quite a bit.

adam commented

2026-04-24 23:58:08 +02:00

@mikiher commented on GitHub (Mar 10, 2024):

Ah, great, I was able to reproduce this.

The crash happens during a library scan when all the follwoing conditions are met:

An epub is moved from one folder to another within the same library
force_rescan is true (which, after reading the code more carefully, can happen, but only after the metadata precedence of a library was changed, as can be seen in the original crash log).

Due to a bug somewhere, although the book path changes, the code tries to open it in its original location, which likely causes the crash (I haven't identified exactly where the crash happens, but at least I understand the root of the problem).

I will work on a fix.

@mikiher commented on GitHub (Mar 10, 2024): Ah, great, I was able to reproduce this. The crash happens during a library scan when all the follwoing conditions are met: 1. An epub is moved from one folder to another *within the same library* 2. force_rescan is true (which, after reading the code more carefully, _can_ happen, but only after the metadata precedence of a library was changed, as can be seen in the original crash log). Due to a bug somewhere, although the book path changes, the code tries to open it in its original location, which likely causes the crash (I haven't identified exactly where the crash happens, but at least I understand the root of the problem). I will work on a fix.

adam commented

@sveinbjornpalsson commented on GitHub (Mar 11, 2024):

Ah, great, I was able to reproduce this.

So you don't need the log? I have found it but I'd be happy to skip it :)

@sveinbjornpalsson commented on GitHub (Mar 11, 2024): > Ah, great, I was able to reproduce this. So you don't need the log? I have found it but I'd be happy to skip it :)

adam commented

@mikiher commented on GitHub (Mar 11, 2024):

So you don't need the log? I have found it but I'd be happy to skip it :)

No, thank you, I don't need the log anymore

@mikiher commented on GitHub (Mar 11, 2024): > So you don't need the log? I have found it but I'd be happy to skip it :) No, thank you, I don't need the log anymore

adam commented

@mikiher commented on GitHub (Mar 11, 2024):

@advplyr, I dug into what happens when you move library files into a different folder in the same library.

It looks like the code that handles these kind of changes seems quite buggy at this point, so I'd like to understand better the considerations behind the organization of the data in LibraryItem records and their associated media (Book/Podcast/PodcastEpisode) records, before I implement a fix.

A LibraryItem record has libraryFiles column
In the media records:
- A Book record has ebookFile, audioFiles, and coverPath
- A Podcast record has coverPath
- A PodcatEpisode record has audioFile

The paths in libraryFiles need to be in sync with the paths in the various media records, otherwise bad things happen.

In this case, inside LibraryScanner.scanLibrary, when a book directory is moved from one folder to another, the scanner cleverly matches the existingLibraryItem with its new location, and then calls checkLibraryItemData, which updates existingLibraryItem and saves it in the database too. However, the associated media records are not updated, which corrupts the databsae and causes subsequent crashes.

So, my questions, before trying to fix:

Why are path duplicates kept in the database? This complicates the logic and causes issues like this one.
Should I just fix this issue by updating the media records, or should we try to change the schema to remove the duplication?

@mikiher commented on GitHub (Mar 11, 2024): @advplyr, I dug into what happens when you move library files into a different folder in the same library. It looks like the code that handles these kind of changes seems quite buggy at this point, so I'd like to understand better the considerations behind the organization of the data in LibraryItem records and their associated media (Book/Podcast/PodcastEpisode) records, before I implement a fix. - A `LibraryItem` record has `libraryFiles` column - In the media records: - A `Book` record has `ebookFile`, `audioFiles`, and `coverPath` - A `Podcast` record has `coverPath` - A `PodcatEpisode` record has `audioFile` The paths in `libraryFiles` need to be in sync with the paths in the various media records, otherwise bad things happen. In this case, inside [`LibraryScanner.scanLibrary`](https://github.com/advplyr/audiobookshelf/blob/9e44fe5524dc5611b93a0c07e375c204e8cf2960/server/scanner/LibraryScanner.js#L124), when a book directory is moved from one folder to another, the scanner cleverly matches the `existingLibraryItem` with its new location, and then calls [`checkLibraryItemData`](https://github.com/advplyr/audiobookshelf/blob/9e44fe5524dc5611b93a0c07e375c204e8cf2960/server/scanner/LibraryItemScanData.js#L146), which updates `existingLibraryItem` and saves it in the database too. _However_, the associated media records _are not_ updated, which corrupts the databsae and causes subsequent crashes. So, my questions, before trying to fix: - Why are path duplicates kept in the database? This complicates the logic and causes issues like this one. - Should I just fix this issue by updating the media records, or should we try to change the schema to remove the duplication?

adam commented