mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
Bug: Scanner Adds Duplicates of First Track to Track List #32
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#32
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 (Sep 22, 2021).
Some of the books are saying "Duplicate Track" but it turns out to be the first track was added multiple times to the track list.
When I tested fixing this one by removing the year and rescanning, another one popped up with the issue. Removing the year didn't fix it.
@Budlyte commented on GitHub (Sep 22, 2021):
Looking at more of them, it appears to be adding that first track a number of times equal to the total number of tracks.
@advplyr commented on GitHub (Sep 22, 2021):
The scanner uses the OS internal id for files and folders so if they are renamed it doesn't lose track.
Are you running the docker image on Unraid?
Is this happening to any other audiobooks?
@Budlyte commented on GitHub (Sep 22, 2021):
Yes, on Unraid.
It happened to about 10. Rescanning this time didn't add any more, so maybe that one that added before had just been lying in wait.
@advplyr commented on GitHub (Sep 22, 2021):
I'm still not clear on what is happening.
If you delete the audiobook from Audiobookshelf and re-scan, is it adding the correct tracks?
When you rename a file in the audiobook folder it is duplicating the tracks?
@Budlyte commented on GitHub (Sep 22, 2021):
I haven't tried deleting & re-adding, I'll give that a go this evening.
I did rename the problem files & rescanned, and the problem came back with those same files.
Your comment about the system using the OS's file IDs and the problem repeatedly being with the files sounds like the issue may be in my OS. Though I have seen weird folders popping up in my library recently, possibly these are softlinks or something getting brought in?
I'll test more tonight.
@advplyr commented on GitHub (Sep 22, 2021):
I could definitely see issues if your files are soft links. Thanks for looking into it.
@Budlyte commented on GitHub (Sep 22, 2021):
I started up another container, audiobookshelf_test, to test it out. I was able to reproduce it with a couple and then of course when I went to get screenshots to help document it, I'm no longer able to reproduce it....
So when I was able to reproduce it, I noticed it is happening with books that are missing tracks. It happened after I went through Manage tracks and updated the track order, basically to ignore that track 1 is missing, and rescanned. Then sometimes that book now has track 2 duplicated in its list as many times as their are tracks.
I thought maybe it was softlinks because of the way the buttons are acting to uncheck tracks, but I cannot find anywhere in the entire library where duplicate tracks exist.
Here's what the buttons do on those duplicate tracks when it happens though. Click a red one makes others change state.
And now my test library actually has fewer errors in it than the original... LOL I guess I'm swapping the container names and path mappings!
@advplyr commented on GitHub (Sep 22, 2021):
When toggling a track to not include it should move to the top of the list. Even if they all have the same track number, it should still move to the top of the list, so that is strange.
Can you look in the developer console for errors? Ctrl+shift+i
@Budlyte commented on GitHub (Sep 22, 2021):
Oh neat! Here it is.
https://drive.google.com/file/d/1rMtAvFOHVtVkubed5Cp0Xl5ArGJWiv5z/view?usp=sharing
@advplyr commented on GitHub (Sep 24, 2021):
I'm still lost on this one.
It seems like your files are being issued a new inode value, which is causing the scanner to think it is a new file.
I added an extra check in the scanner to help see what is happening.
If an audio file has the same path as the audio file being scanned, but a different inode value, then it will show this warning:
Logger.warn("[Scanner] Audio file with path already exists with different inode, New: "${file.filename}" (${file.ino}) | Existing: ${audioFileWithMatchingPath.filename} (${audioFileWithMatchingPath.ino})")If you see this happen again on a scan, let me know if you see that warning in your log.
@advplyr commented on GitHub (Sep 27, 2021):
I came across an issue with the scanner not setting the inode for some files. This may have been the problem you had, but either way I added an extra step check in the scanner that should hopefully catch and resolve the issues you are having.
This is v1.2.5