mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
Moving audio file to subdirectory marks original entry as "missing" #1830
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#1830
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 @rkennedy on GitHub (Mar 19, 2024).
Describe the issue
Suppose I have an audiobook file in my library's main directory, /audiobooks/Example.m4b. Then I later obtain the e-book edition of the same book, Example.epub. To associate them as the same book in ABS, they need to reside in a directory together, so I create a new directory, /audiobooks/Example, and I move Example.m4b and Example.epub into that new directory.
What I hoped would happen is that the ABS would show that the audiobook I had before now also has an e-book file. Instead, it shows that the audiobook file is missing, and it shows a new book entry consisting of both files.
The inode number of the .m4b file is the same. I was under the impression that ABS was supposed to recognize renamed or moved files when their inode numbers are the same, but that's not what I've observed in this case.
I run ABS with Podman, and I have a single library bind-mounted into the ABS container from a locally attached USB SSD. The inode number of the file in question is the same both inside and outside the container.
This is annoying because I need to redo any metadata updates and chapter markers that were previously done on the original book entry.
Steps to reproduce the issue
Audiobookshelf version
v2.8.1
How are you running audiobookshelf?
Docker
@mikiher commented on GitHub (Mar 21, 2024):
Yes, I'm able to reproduce this, thanks for reporting.
Moreover, if the file move above happens through the library watcher path, the old item is not even marked as missing, which is even worse.
I've been working on a related issue (#2686) in the same area of the code, so I'll try to tackle this one as well.
@mikiher commented on GitHub (Mar 21, 2024):
So, the story is like this:
When scanning a library, the code does try to identify modifed entries by ino.
The problem is that in this scenario is that the ino of the libraryItem and the newly scanned item are not the same. The old libraryItem's ino is the file (example.m4b) ino. but the ino coming from the scan is the new containing folder ino. Therefore, when trying to match the exisitng library item with one of the scanned items by ino, a match is not found.
This is a consequence of the fact that single files in the library's root folder are handled in a slightly different way than files contained in a subfolder.
BTW, the issue happens both ways - when you move file in the root folder to a subfolder, and also when you move a file from a subfolder to the root folder - for the same reason.
I'll have to make a chage that associates scanned items with the inos of both their containing folder and their individual files, and then the existing libraryItem can be match with a scanned item. After that I'll need to make sure the library item update works as expected.
Stay tuned...
@rkennedy commented on GitHub (Mar 21, 2024):
Wow, thanks for the prompt and thorough explanation! Sounds like you have a pretty good idea of how to fix it, too, which is always a good sign.
@advplyr commented on GitHub (Apr 22, 2024):
Fixed in v2.9.0
@Alarez777 commented on GitHub (May 5, 2024):
The problem persists in 2.9.0.
I had a folder of an author and inside I had folders with his audiobooks, when I wanted to create a series I created the folder and put 2 folders of audiobooks inside. When scanning I got 15 audiobooks as not found several of other authors.
@rkennedy commented on GitHub (May 5, 2024):
For what it's worth, the issue I observed and reported here is resolved. I created a new folder and moved an audio file from the top-level directory into the new folder, and ABS still listed a single book and was able to play the file from its new location.
Based on Mikiher's description above, it sounds like a library item's parent folder inode is relevant in identifying it, so moving a file from one folder to another could certainly interfere with that. Doesn't seem like intended behavior, though.