mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Bug]: New Audiobook gets old Audiobooks Metadata #3206
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#3206
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 @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 20, 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.
@NeoEvaX commented on GitHub (Feb 25, 2026):
This is also happening to me. I am using unraid as well.
It used to happen very occasionally, but this morning I had multiple new uploaded books take over existing other books. The original book files are located in the folder correctly still, but are ignored completely. It really makes it difficult to manage these books.
I uploaded a book A, it "took over" an older book B. I updated it to be correct A. I then had no book B anymore. But the file is still in the folder. So I delete the file from the folder and upload it again. This time the upload took over book C. So now Book C is "orphaned" on the folder share.
All of these are random books from random authors. There is no overlap in naming or author names.
@matthewkei commented on GitHub (Mar 3, 2026):
I am also affected by this issue. Seems to have really increased in frequency. I see the issue when adding books to library through web interface upload or adding directly to file structure. It's frequent enough that I have altogether quit adding books to my library.
Running abs v2.23.1 (can confirm bug also present in v2.23.0) in docker on Ubuntu.
Anyone finding a workaround? Also- I suspect this was happening before I realized it and I probably have books in my library that don't show up due to this issue. Anyone know how to identify if books are mixed up like this?
@Jimmni commented on GitHub (Mar 4, 2026):
The only workaround I've found is this: Disable folder monitoring, enable metadata by the files (which I was loathe to do), and only scan files manually. I had to do both the first two, neither one worked on their own but they did together. It's a pita as it takes several hours to do a scan on my library. I do find that if I scan, add books, then scan again the second scan is much quicker.
I fixed my library using a script that pulled the name, author and file path of every book from the library using the API and plonked them in a CSV file. I don't think I have it anymore but a LLM can easily create such a script. I then fed that CSV into an LLM and asked it to identify all instances where the author+title did not match what would be expected for the file path. It pumped out a big long list of clearly mismatching. If you library isn't too large you can probably just look over the list manually and skip feeding it to an LLM.
I then took that list and painstakingly fixed each one by moving the files out of the library, running a scan. Every book that was "hijacked" by a new file overwriting its file path then gets marked as Missing in the UI. I removed all "missing file" book listings. Rescanned. The books that were overwritten were then added back again, with their correct paths. I then had to re-add the books that had done the overwriting and been "lost" and did another scan, picking them up. It was, in my case, over a thousand books.
It was not a positive introduction to Audiobookshelf.
@Jimmni commented on GitHub (Mar 14, 2026):
I ended up making my own forked image that strips out the inode matches overriding path matches in folder watching, relying only on paths instead. What is happening, in my case at least, is Audiobookshelf sometimes uses inode matches to decide that a newly added book is really an older, existing book that had just been moved, and then replaces the old book’s stored location with the new one instead of adding the new book as a new entry.
So far so good, no lost file as yet. The only tradeoff I've found is that it can no longer watch for renames - they get treated as a missing + new item. Small price to pay for reliable scanning and books no longer being lost. And even this price could be avoided with a little more effort in the scanning code. I just wanted to confirm the problem and a temporary fix.
If it stays solid for longer-term testing, ultimately it would probably be best to just add extra protections so inodes can't hijack paths incorrectly, maybe via asking for manual review or via extra checks like matching parent folder. Or perhaps a toggle to turn the use of inodes off on systems where they can't be relied on.
This is a very fixable problem. Hopefully the devs look into it!