mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Bug]: Book covers not working after restoring backup #2879
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#2879
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 @ratsputin on GitHub (Jul 10, 2025).
What happened?
After restoring a backup taken last weekend, all of my audiobook covers are showing as invalid in the library and items views. The oddball issue is that there are
cover.jpgfiles in the item directories, and if I go in to modify the cover, the contents of that file is shown as the book's cover (even though the library view shows invalid).What did you expect to happen?
Restoring the backup should have restored all of the covers and should have displayed correctly in the library view.
Steps to reproduce the issue
Audiobookshelf version
2.25.1
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 identified a specific item (
03a44dc1-75db-420a-8fa5-ce16203ed4f1) that was having an issue. The API call was:http://debian.dante.local:13378/audiobookshelf/api/items/03a44dc1-75db-420a-8fa5-ce16203ed4f1/cover?ts=1751748740193Initially, accessing this in my browser returned
Not Found.Checking for that ID, I found the following:
The JPEG file did correspond to the image shown when I tried to edit the cover; however, from the library view, the cover image was listed as invalid.
Shortly after trying this, it appears that AudioBookshelf downloaded a new cover image; however, the JPEG file in the items directory hasn't been replaced.
In short, the correct cover image is in the item directory and was restored from the backup; however, it isn't being used for the library view.
One additional troubleshooting step I used was to restore the cached covers directory manually from before the restore process blew them away. This did not address the issue.
@Vito0912 commented on GitHub (Jul 10, 2025):
Can you check two things:
For 2. if not try this and report back
@ratsputin commented on GitHub (Jul 10, 2025):
Still the same behavior. I've attached a screenshot that demonstrates the issue.
@nichwall commented on GitHub (Jul 10, 2025):
Can you clarify what invalid means? Like is the empty gray box or the Invalid Cover shown in https://github.com/advplyr/audiobookshelf/issues/4090 ?
Do you have "Store Cover with Item" enabled in the settings?
The cache should be cleared when restoring from backup, can you confirm whether those cached covers were not removed correctly or whether they were regenerated when trying to access the covers? You said you manually tried to restore the cache so not sure what that means.
@ratsputin commented on GitHub (Jul 10, 2025):
Here is a screenshot of the specific item I was talking about. The image shown in the background is the one that Audiobookshelf apparently automatically downloaded. It started being returned on that API call later after I got the Not Found.
This is what the home page looks like now (including this book and the book from the screenshot I posted a moment ago).
Regarding manually restoring the cache, I had a copy of the cache directory from before the restore (I saved it before doing the restore). Thinking that might resolve the issue, I restored all of those cache files that were deleted during the restore. That (obviously) didn't resolve the issue. Those files have since been deleted when I did the purge all.
@nichwall commented on GitHub (Jul 10, 2025):
Audiobookshelf only downloads cover images if you accept the Match, use Quick Match, or use the cover picker and select one of the images. Audiobookshelf does not automatically download any files or metadata from online providers, it is intentionally a manual action. Are you sure that image was not embedded in the audio file?
Can you find the file path of the square cover image that you say is the incorrect one?
Thanks for confirming. That is expected behavior, where they are removed during a backup restore and when you purge the cache.
@ratsputin commented on GitHub (Jul 10, 2025):
Apologies, that image could very well be in the file. It is an m4b file. I haven't worked with Audiobookshelf enough to know the ins and outs of its behavior.
@nichwall commented on GitHub (Jul 10, 2025):
No worries. The main question is where did that image come from to narrow down the issue (a different cover image stored somewhere, embedded in an audio file, etc).
Can you also share your server settings, and whether you have changed them at all? Specifically this part
@ratsputin commented on GitHub (Jul 10, 2025):
Thank you for your help!
@ratsputin commented on GitHub (Jul 10, 2025):
Oh, and I did play the m4b file back in VLC and it displayed that same cover so the picture definitely came from the file.
@ratsputin commented on GitHub (Jul 10, 2025):
Incidentally, as a side note, if I go to the authors page, it automatically populates their images and a bunch of new image files show up in
cache/images/. It's just not happening with the books.@ratsputin commented on GitHub (Jul 11, 2025):
I don't know if this is helpful or not, but I tried turning on "Ignore prefixes when sorting" and now about 2/3 of the books in my library have the proper cover image. I know that many of these images are not from the audiobook file, but rather from the cover image I set previously.
An understanding of where the image shown in the library comes from (presumably the cache) and how it gets updated (I'm assuming there's some logic that is supposed to be triggered when the cache is empty and that's what's failing) would be helpful.
Is there a higher level of debug or another set of logs I can look at? I would expect to see some sort of error message when there's an invalid image or the cache update fails but nothing is reflected in the logs.
@ratsputin commented on GitHub (Jul 11, 2025):
Okay, this is interesting. I started playing with this a bit more and cleared the cache again. Once the library images repopulated, I went and looked in the
metadata/cache/coversdirectory and there are only two files there. I manually updated a couple of covers and now see four files there.It appears that there must be some logic that causes cover images to either be pulled from the
metadata/cache/itemsdirectory or themetadata/cache/coversdirectory. I'm now starting to wonder if this is what's broken, as I frequently have an issue after a reboot where the volume where all of my audiobook data is not mounted when the container starts. I have to stop the container, mount the volume, then restart the container.Is it possible that the path for the cover image in the database is flagged as invalid if it tries to render the library and can't find the cover image at that time and it will never try to do it again?
@advplyr commented on GitHub (Jul 11, 2025):
When a cover image is requested:
/metadata/cache/covers)https://github.com/advplyr/audiobookshelf/blob/9c0c7b6b08ec68d9b80f2c8aec21f7052ea9433a/server/controllers/LibraryItemController.js#L373-L405
https://github.com/advplyr/audiobookshelf/blob/9c0c7b6b08ec68d9b80f2c8aec21f7052ea9433a/server/managers/CacheManager.js#L33-L59
@ratsputin commented on GitHub (Jul 11, 2025):
Well, with no explanation whatsoever, the issue has now resolved itself. I just randomly checked the covers and 99% of them had repopulated.
@nichwall commented on GitHub (Jul 11, 2025):
Glad you got it figured out, but that is weird.