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]: Inconsistent folder watcher scanning & book duplicates [depends on library folders] #2466

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

Originally created by @SawkeeReemo on GitHub (Jan 6, 2025).

What happened?

I have two audiobook libraries [lib1 and lib2] for testing.
Both are set view the same book folder(s) but in a different manner:

lib1 folders:
audiobooks/username/media1
audiobooks/username/media2
audiobooks/username/media3

lib2 folder:
audiobooks/username/

Inside the media# folders is the file structure:
author/booketitle/files.ext

Both lib1 and lib2 have the watch folder setting turned on, but if I move an author folder from /media1 to /media2, for example, I get the following results:

lib1 = watch folder scan is triggered
lib2 = watch folder scan is NOT triggered

lib1 = the book(s) is added again to the library as a new entry, but the original entry is not marked as missing until I run a full manual library scan.
lib2 = have to run a manual library scan to catch changes, but properly links the original entry to the new file(s) location.

What did you expect to happen?

I expect a folder watcher scan to be triggered in both scenarios. And also expect current book entries to be properly relinked to the new file locations.

Steps to reproduce the issue

  1. All explained in the What Happened section above.

Audiobookshelf version

v2.17.7

How are you running audiobookshelf?

Docker

What OS is your Audiobookshelf server hosted from?

Linux

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

Chrome

Logs

No response

Additional Notes

No response

Originally created by @SawkeeReemo on GitHub (Jan 6, 2025). ### What happened? I have two audiobook libraries [**lib1** and **lib2**] for testing. Both are set view the same book folder(s) but in a different manner: **lib1** folders: `audiobooks/username/media1` `audiobooks/username/media2` `audiobooks/username/media3` **lib2** folder: `audiobooks/username/` Inside the media# folders is the file structure: `author/booketitle/files.ext` Both **lib1** and **lib2** have the `watch folder` setting turned on, but if I move an author folder from /media1 to /media2, for example, I get the following results: **lib1** = watch folder scan is triggered **lib2** = watch folder scan is NOT triggered **lib1** = the book(s) is added again to the library as a new entry, but the original entry is not marked as missing until I run a full manual library scan. **lib2** = have to run a manual library scan to catch changes, but properly links the original entry to the new file(s) location. ### What did you expect to happen? I expect a folder watcher scan to be triggered in both scenarios. And also expect current book entries to be properly relinked to the new file locations. ### Steps to reproduce the issue 1. All explained in the What Happened section above. ### Audiobookshelf version v2.17.7 ### How are you running audiobookshelf? Docker ### What OS is your Audiobookshelf server hosted from? Linux ### If the issue is being seen in the UI, what browsers are you seeing the problem on? Chrome ### Logs _No response_ ### Additional Notes _No response_
adam added the bug label 2026-04-25 00:07:25 +02:00
adam closed this issue 2026-04-25 00:07:25 +02:00
adam commented 2026-04-25 00:07:26 +02:00
Author
Owner
Copy Link
Copy Source

@SawkeeReemo commented on GitHub (Jan 6, 2025):

UPDATE: I decided to just go with the lib2 style (parent folder setup) and I removed lib1. ...and now for some reason the folder watcher scanner is being triggered.

@SawkeeReemo commented on GitHub (Jan 6, 2025): UPDATE: I decided to just go with the **lib2** style (parent folder setup) and I removed **lib1**. ...and now for some reason the folder watcher scanner is being triggered.
adam commented 2026-04-25 00:07:26 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Jan 6, 2025):

I'm not sure I understand the issue. The lib2 folder structure in your example that would have multiple nested media1, media2, folders wouldn't be a valid folder structure. If that was scanned in the media1 would come in as the author name.

Abs isn't set up to support pointing multiple libraries to the same media with the watcher enabled. When the watcher gets triggered for a file path that file path is "locked" so that multiple scans of the same directory doesn't happen.

If there is a bug here can you give reproducible steps in enough detail so that I can test it?

@advplyr commented on GitHub (Jan 6, 2025): I'm not sure I understand the issue. The `lib2` folder structure in your example that would have multiple nested `media1`, `media2`, folders wouldn't be a valid folder structure. If that was scanned in the `media1` would come in as the author name. Abs isn't set up to support pointing multiple libraries to the same media with the watcher enabled. When the watcher gets triggered for a file path that file path is "locked" so that multiple scans of the same directory doesn't happen. If there is a bug here can you give reproducible steps in enough detail so that I can test it?
adam commented 2026-04-25 00:07:26 +02:00
Author
Owner
Copy Link
Copy Source

@SawkeeReemo commented on GitHub (Jan 13, 2025):

I'm not sure I understand the issue. The lib2 folder structure in your example that would have multiple nested media1, media2, folders wouldn't be a valid folder structure. If that was scanned in the media1 would come in as the author name.

Abs isn't set up to support pointing multiple libraries to the same media with the watcher enabled. When the watcher gets triggered for a file path that file path is "locked" so that multiple scans of the same directory doesn't happen.

If there is a bug here can you give reproducible steps in enough detail so that I can test it?

Sorry for the delay, I wanted to test a few things, and free time has been thin. I think the issue comes down to what you mentioned above, that having two libraries pointing to the same group of files prevents folder watcher from working properly. I had it set up that way just for testing, but as soon as I removed lib1 from my example above, folder watcher started working and has worked properly ever since.

So we should close this, but maybe add something to the wiki about this so people don’t run into this problem? A possible scenario being that maybe people want to curate different libraries for different users where they overlap media. In this context, they should be using collections and not libraries, for example. (If that makes sense… I can’t seem to “get my words out” today.

@SawkeeReemo commented on GitHub (Jan 13, 2025): > I'm not sure I understand the issue. The `lib2` folder structure in your example that would have multiple nested `media1`, `media2`, folders wouldn't be a valid folder structure. If that was scanned in the `media1` would come in as the author name. > > Abs isn't set up to support pointing multiple libraries to the same media with the watcher enabled. When the watcher gets triggered for a file path that file path is "locked" so that multiple scans of the same directory doesn't happen. > > If there is a bug here can you give reproducible steps in enough detail so that I can test it? Sorry for the delay, I wanted to test a few things, and free time has been thin. I think the issue comes down to what you mentioned above, that having two libraries pointing to the same group of files prevents folder watcher from working properly. I had it set up that way just for testing, but as soon as I removed lib1 from my example above, folder watcher started working and has worked properly ever since. So we should close this, but maybe add something to the wiki about this so people don’t run into this problem? A possible scenario being that maybe people want to curate different libraries for different users where they overlap media. In this context, they should be using collections and not libraries, for example. (If that makes sense… I can’t seem to “get my words out” today.
adam commented 2026-04-25 00:07:26 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Jan 13, 2025):

Yeah we'll add a warning for it, ideally in the UI. It has been set up like this for a few years and this hasn't come up before your post then a few days later it came up again https://github.com/advplyr/audiobookshelf/issues/3826
We'll use that issue as the one for adding a warning

@advplyr commented on GitHub (Jan 13, 2025): Yeah we'll add a warning for it, ideally in the UI. It has been set up like this for a few years and this hasn't come up before your post then a few days later it came up again https://github.com/advplyr/audiobookshelf/issues/3826 We'll use that issue as the one for adding a warning
adam commented 2026-04-25 00:07:26 +02:00
Author
Owner
Copy Link
Copy Source

@SawkeeReemo commented on GitHub (Jan 17, 2025):

Sounds good. Thanks for all the great work on this!

@SawkeeReemo commented on GitHub (Jan 17, 2025): Sounds good. Thanks for all the great work on this!
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#2466
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?