mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-03-02 22:46:55 -05:00
[Bug]: New Audiobook gets old Audiobooks Metadata #3206
Labels
No labels
authentication
awaiting release
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/audiobookshelf-advplyr#3206
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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 @Amsee-Daniel on GitHub (Jan 28, 2026).
What happened?
I have the following problem:
Every now and then, when I copy audiobooks to the file system monitored by Audiobookshelf, these new audiobooks randomly receive the metadata of existing audiobooks. Apparently, the existing audiobooks whose metadata is incorrectly used are then assigned new metadata, because the existing books still have the correct metadata they always had, but lose their numbering in a series. Very strange.
In any case, I then have to manually go into these new audiobooks with incorrect metadata and manually search for the correct metadata in the grabber based on the file name and assign it.
What did you expect to happen?
I Expect a new Book to get new Metadata and the old one to stay as it is
Steps to reproduce the issue
Audiobookshelf version
v2.32.1
How are you running audiobookshelf?
Docker
What OS is your Audiobookshelf server hosted from?
Other (list in "Additional Notes" box)
If the issue is being seen in the UI, what browsers are you seeing the problem on?
Firefox for Android
Logs
Additional Notes
I am Using Unraid to Host the Server and the monitored Network Share.
Audio-Log.json
@Vito0912 commented on GitHub (Jan 28, 2026):
Do you do that via the network share or directly on the NAS?
@Amsee-Daniel commented on GitHub (Jan 28, 2026):
Hay, I do that via a Network-Share. So, in the Windows File-Explorer. I am not using the Audiobookshelf Upload function (I tried that, but it will mess up my sorting system and just create a locked file).
Little Addendum: I activated the Metadata-File stored besides the Audiofile. So, even when a valid file is next to the Old Audiobook, it vanishes.
@Vito0912 commented on GitHub (Jan 28, 2026):
Just to rule out the most obvious. Can you please show the tree of a book where this is happening?
(with all files and folders to that)
@Amsee-Daniel commented on GitHub (Jan 28, 2026):
This is one of the Books, that this happened with.
In generell: My Books are sorted like this:
Horbucher(The Name of the Network-Share)/Genre/Author/Series/Episode/File.m4b
@Vito0912 commented on GitHub (Jan 28, 2026):
Assuming there is no single file in the "Die Hausboot-Detektive", then it should be fine. Then sadly the text I would have written before:
There has been an elevated rate of reports for this happening.
I personally, as a contributor (so not maintainer, so don't take my words for times), suspect that some update on any device messed up with inodes when copying via the Windows site on SMB shares (or whatever is used(. Personally I don't think this can be fixed easily, because ABS depends heavily on inodes. If the drive reports inodes that should not be reported, something like this would happen. (But it is also not 100% clear if it's because of this)
Please try the upload dialogue (although you said it will not work for you, but for others) or try uploading the files directly with FTP or similar and check if that also causes this. I don't say this is a fix, but personally I would not think that someone has an immediate solution for this, especially since this only really seems to happen for a few months now and is not reproducible on actual "server" builds most people run ABS on.
@Amsee-Daniel commented on GitHub (Jan 28, 2026):
Oh, I am Sorry. The Formater changed how my written Path looked. I fixed it. Would it be possible for you, to look at it again? Thank you. Otherwise... I think i need to live with it then.
Thank you for your Help :)
@Vito0912 commented on GitHub (Jan 28, 2026):
It still looks correct :);)
@Armelline commented on GitHub (Jan 31, 2026):
Could ABS not perform additional checks before blindly trusting inodes? If the path doesn't remotely match the metadata it's trying to apply the path to, that should surely raise red flags. I can reproduce the issue on my Mac, Windows and Linux. Maybe a "Trust inode or path" flag that the user can pick between? It makes managing my library a deeply, deeply frustrating experience. Especially since a 3 hour scan every time I add a book isn't really a viable option.
@Vito0912 commented on GitHub (Jan 31, 2026):
If you can explain how, I am sure a PR can be opened. Until recently, these things happened "rarely".
(macOS also added a lot of reports, but macOS is completely broken at other things too [like not exposing whole folders], so it might not even be inodes there)
I don't think any dev person has gotten this reproduced all the times.
There is also this PR https://github.com/advplyr/audiobookshelf/pull/4857, but imho this is not the proper solution that should fix this (but hopefully that gets merged soon, although I see some issues with that PR, function wise)
@Armelline commented on GitHub (Jan 31, 2026):
Here's some logs on the nightmare I'm currently experiencing. It's looking increasingly likely I'll just have to go back to Plex as I can't trust ABS even remotely. It all started when I tried to move one book from a series folder to a series/series folder and cascaded from there. This happens regularly. It's infuriating. I wish it would just look at paths. Why not use inotify/FSEvents/ReadDirectoryChangesW rather than inodes which are clearly incredibly unreliable?
Even just exposing the path for manual editing would be enough to make untangling the message much easier.
I was running on Linux due to reading reports of this issue on Mac but it kept happening to me there, so I moved it to my Windows machine to test and it happened there so I just put it on my Mac mini server where Plex etc. are running as if it's going to happen regardless of where I run it I might as well be running it on the computer that's going to be running 24/7 anyay.
The common thread for me is Docker. I blame Docker for not using consistent inodes.
logs.txt
@Armelline commented on GitHub (Jan 31, 2026):
Here's one example as it cascades on and on. It's more than just "the path is assigned to the wrong book" there's a whole conflating of two completely different books happening. (Path > More Info = screenshot.)
@computersaint commented on GitHub (Feb 19, 2026):
I'm having this issue on Unraid, almost every book I add is now being assigned the metadata of an existing book and does not show up on the new books section. I have to go and figure out where it is and match it with the correct metadata. It does not seem to affect the existing book and it's metadata. Does anyone have any update on this bug? It's making it really difficult to add books now. Any workaround or advice would be appreciated.