mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Bug]: The same file & folders are being recognized as missing then readded on scans as a new entry #1983
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#1983
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 @kanjieater on GitHub (May 12, 2024).
What happened?
The path is:
/audiobooks/アンドレイ・サプコフスキ, 川野 靖子, 天沼 春樹/ウィッチャー I エルフの血脈/ウィッチャー I エルフの血脈 [B0CXDWXBCW].m4bBoth entries are the exact same, and you can see I can use the browser find functionallity to find that the same path matches. It seems that because the author name that comes from metadata doesn't match the one I have persisted to disk.
ABS doesn't fetch the metadata or match the new book, and despite the files being the exact same it's not removed from the issues and combined into a single entry. I'm not sure why it's thinking the file changed in the first place though honestly.
What did you expect to happen?
Files and paths that haven't been changed should result in the same audiobook entry
Steps to reproduce the issue
Audiobookshelf version
v2.9.0
How are you running audiobookshelf?
Docker
What OS is your Audiobookshelf server hosted from?
Linux
If the issue is being seen in the UI, what browsers are you seeing the problem on?
Chrome
Logs
Additional Notes
I am using MusicBee to automatically organize the file structure by metadata. It may have done something automatically to the same folder - but the files and paths are the same, I would expect it to be treated as the same audiobook entry.
@nichwall commented on GitHub (May 12, 2024):
Are you running scans, either manual or periodic? Do you have the watcher enabled?
There are issues with non-ASCII characters that have popped up when doing the comparison for SQLite, so could be related to that. Is it all books or only certain books?
@kanjieater commented on GitHub (May 12, 2024):
Thanks for the reply.
It's 10%~ of my library 2000 book library.
I have hourly scans setup. Just confirmed I had the watcher set up as well. At first it did this to about 10 of them. Then i fixed those 10, rescanned and it showed 200~.
All of these should be utf-8 chars. Not latin or shift-jis.
@advplyr commented on GitHub (May 12, 2024):
Can you enable debug logs, run a full library scan, and share the scan log?
The provided log is filled with rate limit requests from matching authors and not related to a scan.
@advplyr commented on GitHub (May 12, 2024):
Also if you can share what file system you are using. Are you mapping a Windows drive? Is this a remote file system?
@kanjieater commented on GitHub (May 13, 2024):
I'll try to rerun and post soon. I'm using wsl2 with the docker compose setup. The drive is my windows drive accessed directly through /mnt/a/audiobooks
@kanjieater commented on GitHub (May 13, 2024):
I Set the server log level to debug and rescanned
@kanjieater commented on GitHub (May 13, 2024):
I did remove the issue books and have disabled musicbee from changing files automatically so nothing is broken. If you'd like I can reenable it to try to break something and reproduce.
@advplyr commented on GitHub (May 16, 2024):
I'm not sure. Is this resolved now on your end?
@oddstr13 commented on GitHub (Jul 11, 2024):
I am seeing this behavior after moving files around and re-scanning.
(1)
(2) moved to the following and then re-scanning
(3) after that, moving to the following and re-scanning;
This resulted in one entry for each book, in addition to a collective entry for all three books, stuck in state (2) – listed as an item with an issue due to missing files.
Deleting the bad entry from the database does not make it re-appear after a new scan.
Side-note; it would be nice to separate the delete from database and delete from filesystem into separate permissions, as I would prefer not having the delete from filesystem option available at all, and as such have disabled this permission on my main user account, meaning it took me a while longer figuring out how to clean up the ghost entry.