Bug: Scanner Adds Duplicates of First Track to Track List

[advplyr]

Bug: Scanner Adds Duplicates of First Track to Track List

[Budlyte]

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]

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]

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]

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]

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]

I could definitely see issues if your files are soft links. Thanks for looking into it.

[Budlyte]

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]

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]

Oh neat! Here it is.

https://drive.google.com/file/d/1rMtAvFOHVtVkubed5Cp0Xl5ArGJWiv5z/view?usp=sharing

[advplyr]

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]

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