mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Enhancement]: Removing a book from the filesystem doesn't remove it from audiobookshelf #2447
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/audiobookshelf#2447
Reference in New Issue
Block a user
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?
Originally created by @dessalines on GitHub (Dec 31, 2024).
What happened?
I removed a book from my filesystem, but for some reason it's still showing up as missing on audiobookshelf.
What's worse is that there's no way to remove it now, either from within the android app, or the web interface. Really it should be auto-removed on rescans.
What did you expect to happen?
A rescan should remove books that are missing.
Steps to reproduce the issue
Audiobookshelf version
v2.7.16
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
@nichwall commented on GitHub (Dec 31, 2024):
ABS does not delete books if they are removed from the file system and are marked as missing so you are aware that ABS thinks files are missing. Can you explain what you mean by "no way to delete it"?
You can edit the book and press the "delete" button, or go to the Issues tab in the navigation bar in the web client and delete missing books. This tab may not show up in a mobile browser depending on the screen dimensions.
@dessalines commented on GitHub (Dec 31, 2024):
I can't see the issue tabs on either android, or the web app.
Also why is it showing missing books? I don't know of any other media server that does that behavior. Not jellyfin, navidrome, or any other app. If you remove the file, it may keep the metadata stored, but it doesn't display missing items in the user interface.
I hit this because I sometimes download a few different versions of audiobooks to see which one is the best quality, and then remove the ones that don't. I did this, and now it shows versions of books I deleted on my main page.
@nichwall commented on GitHub (Dec 31, 2024):
Can you share a screenshot of the issues tab not showing up?
The metadata is no longer tracked when it is deleted from ABS, so it shows up to let the user know that there is metadata without a corresponding file. This metadata is not deleted in case the file being inaccessible is temporary (drive was not mounted correctly, file permissions changed, etc)
@dessalines commented on GitHub (Dec 31, 2024):
Android app: no issues tab, incorrectly shows the books I deleted.
Web app: No issues tab, shows missing metadata on the front page for books I deleted.
This is incorrectly assuming that missing files are bugs, and not that the user intentionally deleted them.
A better solution would be to do what all the other media servers do: not display items that are missing on your front page, and add a setting (default false maybe) that allows rescans to clear metadata for missing files. If you want to display errors for missing files, then it'd be better to do that on a different page.
@nichwall commented on GitHub (Dec 31, 2024):
Try using the web client in a computer, change your phone to landscape mode, or change the mobile browser to Desktop view.
@nichwall commented on GitHub (Dec 31, 2024):
The issues tab is visible here when not using the mobile view.
@dessalines commented on GitHub (Jan 1, 2025):
That should probably be a different bug report, that items are missing in mobile view, not following responsive design.
@2fst4u commented on GitHub (Jan 8, 2025):
I would personally prefer a trash handling setting which enables removal of items when their underlying files are deleted. I've also found this frustrating at times.
@ZLoth commented on GitHub (Jan 9, 2025):
I consider this a feature, not a bug. While I am able to directly access my audiobooks from my TrueNAS server to my Docker instance, some installs may be on a separate system and access the audiobook files on another system. That book may temporarily be inaccessable.
I also had a temporary "missing" occur when I found out a individual book was part of a series, and I moved it to the appropriate subdirectory.
@2fst4u commented on GitHub (Jan 9, 2025):
So let it be a setting.
@dessalines commented on GitHub (Jan 9, 2025):
There is no other media server software that does this.
If you delete a song from navidrome, or movie from jellyfin, it may keep the metadata, but it definitely removes it from your visible library. Keeping (or rather displaying) intentionally deleted media is a bug, not a feature.
@nichwall commented on GitHub (Jan 9, 2025):
I would still consider this a feature request rather than a bug. Just because other software does it a different way doesn't make it a bug. It would be a bug if ABS was designed to hide things, but it is designed to still show the media if it is missing so you are aware of it.
ABS is not designed as a server for frequently removing media. If you are frequently removing media from the server, I would recommend using a separate staging area to determine what file to keep before adding it to ABS.
@2fst4u commented on GitHub (Jan 9, 2025):
Removing a file once every now and then doesn't mean it's frequent. It's perfectly reasonable to want to remove a file from the filesystem and have that represented in your library.
@advplyr commented on GitHub (Jan 9, 2025):
The reason that Abs marks an item as missing rather than delete it from the library is to prevent accidental data loss.
One case where this can happen is in file systems that aren't using inode values because then we don't have a way to detect if a folder gets renamed. If an item folder is renamed the path is no longer reachable and appears missing. If Abs were to delete that item the user would lose any metadata they set for it as well as any user progress.
Another case that we see often is users changing their volume paths in docker by mistake without realizing. At that point they see a bunch of missing items and revert to the correct path without losing their data.
Navidrome is not really comparable. There is no additional metadata stored, it is all from the audio files. There is no progress.
I'm not confident on Jellyfin but I believe you do lose your data if you rename things so that is one way to do it.
This seems like a situation where there is no one size fits all solution but let me know what you think
@2fst4u commented on GitHub (Jan 9, 2025):
There's no reason that removing an item from the library should also remove progress data. It can still be held while still hiding it from the library if the item is re-added at some point in future.
@advplyr commented on GitHub (Jan 9, 2025):
How would you know it is the same item when it gets re-added in the future?
@2fst4u commented on GitHub (Jan 9, 2025):
The same way ADB matches items to upstream metadata (Goodreads or whatever it is), each item is matched to unique books, readding items should match to that same book regardless of which underlying file it is.
Store progress data against the upstream database item ID, not the file.
The same way the other media players mentioned do it.
@advplyr commented on GitHub (Jan 9, 2025):
For music, tv shows and music sure. Do you know of a provider we can use for books?
@2fst4u commented on GitHub (Jan 9, 2025):
Goodreads? Doesn't ADB already use them? Where does the metadata all come from?
@advplyr commented on GitHub (Jan 9, 2025):
I'm not sure what ADB is but Goodreads API is closed.
Abs supports fetching metadata from several providers but none of them are entirely reliable which is why Abs doesn't automatically pull metadata. That is a manual process.
Keep in mind that me and many others have been working on this project and discussing these exact topics for a few years now. When you say "there is no reason" why something isn't the way you think it should be there probably is.
@2fst4u commented on GitHub (Jan 9, 2025):
Sorry autocorrect started getting me, I mean abs. ADB is android debug bridge.
What do you mean it's a manual process? When a book is added that metadata shows without intervention right?
@dessalines commented on GitHub (Jan 10, 2025):
Hash the file or folder when scanning it, and store the hash. MD5 or sha1 should be fine.
@averageyogi commented on GitHub (Jan 13, 2025):
Metadata embedded in/with the audio file(s) will be loaded if it exists, but the book won't be matched with an online provider and no additional metadata will be pulled automatically.
@LiamWilkinson commented on GitHub (Oct 12, 2025):
For a long time I thought there was a bug or missing functionality in the issues tab where I could not delete an audio book that I had removed from the file system. I intended to look at implementing this feature and pulled down the repository to start working on it. When I looked at the code I saw that one of the computed fields is
userCanDelete.Seeing this code I switched to the root user and found the delete button to work perfectly fine, I just didn't know I didn't have the permissions required to delete. I suggest that this should be clarified with a UX improvement where the button is disabled and hovering over the button explains that the user doesn't have permissions to delete.
I would be happy to submit a PR implementing this change if people are interested.