mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
Bug [Scanner]: New Covers Causes Duplicate Books #37
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#37
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 @Budlyte on GitHub (Oct 1, 2021).
I added covers to some books that were missing them and it created duplicate books.
@advplyr commented on GitHub (Oct 1, 2021):
Did you upload the covers or drag them into the folder?
Are you using
v1.3.1?@Budlyte commented on GitHub (Oct 1, 2021):
Yeah, v1.3.1
I saved them to the folders and the scanner re-ran. But, I just noticed, those aren't the covers I saved in there. The new files are square images. ??
@advplyr commented on GitHub (Oct 1, 2021):
The new version uses the cover embedded in the audio file if there is one.
If there is a cover already set it won't override it though and you should still see the covers listed under "local covers" in the edit covers page.
If you delete those duplicates and press scan again, does it create more duplicates?
@advplyr commented on GitHub (Oct 1, 2021):
Duplicate audiobooks must be an issue with the inode value again, which has me stumped.
If you open a terminal and run
stat "{audiobook folder name}"you can see the Inode value of the folder.Here is what it looks like on my machine:
@Budlyte commented on GitHub (Oct 1, 2021):
Oh, well that's a really good update. A library scan on startup might have prevented this.
Hmm, so when I did a full rescan it marked the old books that I had placed covers in as "missing".
But any new ones that scanned in from the audio file came in fine. See No.5 here. Number 2 threw an error too because I added a cover to its folder after posting the image above.
Stats on Reckoners
*** Whoa, that scan added so many covers!
@Budlyte commented on GitHub (Oct 1, 2021):
I was mistaken, several others created duplicates as well and invalidated the previous book.
What I can't tell is if everything that got invalidated was a book that had a cover file, or what the connection is. There are plenty that got their covers extracted though and are fine now.
Honestly, this might not be a real issue, it might just be growing pains as the system updates to a collection that exists (the cause). New users may never see this issue and deleting the invalidated books seems to have cleared up the symptom.
ugh, things are scanning slowly tonight. I had a drive throw a bad sector so it's going through an extended SMART test and the parity drive is running everything. Doing all this while that goes on is probably a bad idea. D:
@Budlyte commented on GitHub (Oct 1, 2021):
Ok, I found a way to reproduce what's happening to the inode value, using the "Save Metadata" button causes a duplicate book to show up.
Here's the before & after hitting the button.
@advplyr commented on GitHub (Oct 1, 2021):
I found why this is happening.
In Unraid the files may be split between two disks, which means the folder might exist multiple times.
For example I had that audiobook on 2 disks.
/mnt/disk2/media/Audiobooks/Adam Smith/The Wealth of Nations/and
/mnt/disk4/media/Audiobooks/Adam Smith/The Wealth of Nations/I moved all the audiobook files inside the one on disk4 into the one on disk2 and deleted the empty folder on disk4.
Running
stat "/mnt/user/media/Audiobooks/Adam Smith/The Wealth of Nations/"resulted in a different inode value.This makes sense actually, it is unfortunate since now I have to think of a new way to track folders, but at least the problem has been identified.
@advplyr commented on GitHub (Oct 2, 2021):
I implemented a solution for release v1.3.3
For posterity..
This issue will only occur on shared drives, where files might move between file systems. The following only applies to shared file systems (i.e. Unraid).
Background
Saving the inode value for the audiobook directory and files is necessary to handle renames, so a renamed folder/file can be matched with the existing audiobook. The inode value should not change on renames, it will only change when adding/removing files.
Solution
When scanning, first match audiobooks and files by their inode (catches renames), then fallback to using the filepath. When an audiobook directory gets scanned, all inode values will be updated.