[Bug]: Local covers are not being used.

[baconcow]

Describe the issue

• Covers which are embedded within the m4b file, or located within the local folder and named as cover.* were not being used.
• Covers that are added from URLs, manually uploaded, or found from the built-in search option work okay.
• I noticed that some of my embedded covers were not being updated during scans (standard or forced).
• I removed the cached covers (\metadata\cache\covers) and performed a scan, then forced re-scan, then rebuilt the image and container.
• Following the user contributed procedure for Windows, the default setting for Docker: "I:\Audiobooks\Audiobookshelf\audiobooks:/audiobooks -v".
• The covers can be seen in the "Files"/"Library Files".
• There is no issue with playback of the files, just the covers (and series generation, which may be a separate issue).
• Attached images showing "Library" and "General" settings.
• Log shows the following errors: "Failed to load resource: the server responded with a status of 500 (Internal Server Error)".

Docker command used:

docker run -d -e AUDIOBOOKSHELF_UID=99 -e AUDIOBOOKSHELF_GID=100 -p 13378:80 -v I:/Audiobooks/Audiobookshelf/config:/config -v I:/Audiobooks/Audiobookshelf/metadata:/metadata -v I:/Audiobooks/Audiobookshelf/audiobooks:/audiobooks -v I:/Audiobooks/Audiobookshelf/podcasts:/podcasts --name audiobookshelf --rm ghcr.io/advplyr/audiobookshelf

The link referenced by the error with the cover: http://192.168.2.24:13378/api/items/li_e5nd7pf2soeefkuivs/cover?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiJyb290IiwidXNlcm5hbWUiOiJyb290IiwiaWF0IjoxNjcxODY3NTI2fQ.CFkzVBtJX51zLV_j7DC7g98vZviD4ShzH4I-Q69KQ3c&ts=1672504336636

Steps to reproduce the issue

1. Set-up Audiobookshelf (ABS) with Docker on Windows 10.
2. Standard scan books. Result: ABS was not using the embedded cover art or local files.
3. Remove the files from the "covers" cache folder.
4. Standard scan books. Result: No book covers showing up.
5. Force re-scan books. Result: No book covers showing up.
6. Delete and re-install ABS with Docker.
7. Force re-scan book. Result: No book covers showing up.

Audiobookshelf version

v2.2.11

How are you running audiobookshelf?

Docker

[advplyr]

I'm not able to reproduce this. My first guess is that it is a permissions issue.

Check the logs coming from the docker container. In the browser open up the console CTRL+SHIFT+J and look for the error that is coming from one of the images.

[advplyr]

Also, since you have enabled the setting "Store covers with item" the docker container must have write access to your library folders. For the media you have with embedded covers you should see the extracted cover stored as cover.jpg inside your item folder.

[baconcow]

I updated the post with an error I see for all the files from the log ("Failed to load resource: the server responded with a status of 500 (Internal Server Error)") and an image showing the cover file from ABS.

[advplyr]

Can you share your full docker run command? And check errors inside the docker container logs.

[baconcow]

Added the full Docker command that I used as well as an error screen when loading one of the books without a cover.

[advplyr]

Can you try the following:

1. Disable the server setting "Store covers with item"
2. On one of the items where the cover is embedded in the audio file (and broken) press edit then remove the cover like this:
3. On your file system delete the cover.jpg and all image files stored with the audiobook.
4. Purge cache
5. Run a "Force Re-Scan" on that library

The force re-scan will see that the item does not have a cover saved and extract the image from the audio file. Now that you have disabled the server setting "Store covers with item" the extracted cover is going to be saved to /metadata/items/{item ID}/cover.jpg.

[baconcow]

I attempted this process on one series of books and another standalone book.

Edit: Upon scanning all of my books, it looks like most of them pulled the embedded covers. Going through them, now. It appears that while many series and books have used the correct covers, many still did not. One series to note is the Red Rising series, which did not load covers during a the previous purge and re-scan and is now using covers from the search (some which have a different language), not the ones that are embedded.

• The books in the series (Red Rising) did not get any image, despite having on embedded.
• The standalone book (The Divine Comedy) had the same image that was embedded and that shows up in the built-in search engine (I am not sure which is the source).

Side Note: After purging the cache and re-scanning, I did not see any issue with Dante's book being put into its own series, which is the other issue I posted. I will look into this further, with more books, for the other issue.

[advplyr]

The series issue that you had is explained by you moving the books around in the folders when you had the server running.

Once you setup a library and add a folder to the library the server is going to listen for changes to your folder structure. If you originally had the audiobooks in a different folder structure then changed it it is not going to delete the metadata it pulled before. If you don't want the server to listen for changes to your folder structure use the "Disable Watcher" server setting.

For the Red Rising embedded cover that was not used you should do a re-scan of that library item and watch the logs. There is a known bug with cover art extraction for Librivox audiobooks (see #1063).

You will have to check the logs to see what error is being thrown when attempting to extract the covers from your audio files.

[baconcow]

I definitely made changes to some of the structure and I had never purged things before. I guess that fixes my series issue, which is great. Is there something specific that I should be looking for in the logs (I am not familiar with them)?

[advplyr]

Watch the docker logs for errors. You can lookup how to watch docker logs for a container since it depends on how you are running docker.

I'm fairly certain you are having the same cover issue as #1063. It has to do with the way cover images are embedded that isn't yet detectable by ffprobe that we are using to scan audio files.

[baconcow]

I am not familiar with Librivox. I embedded those custom covers with Mp3tag v3.1.8 (as with all of my covers).

[baconcow]

I was just able to perform a full scan after doing the following:

• Purge All Cache
• Remove All Library Files
• Manually delete all of the contents of "\metadata\items"
• Manually remove all cover image files from the audiobook folders.
• Force re-scan (no books were in the library prior to this)
• With the following settings:

Out of the 511 books, 28 did not get a cover. I went through them with Mp3tag and it appears these are books that have covers in the .webp format, which I assume is not yet supported. The remaining books were all able to pull the correct embedded cover from their respective .m4b file.

[baconcow]

A few files needed their covers updated. I tried the following:

• Replacing their covers and scanning/re-scanning the books. The embedded cover would not be selected.
• I tried deleting the book's covers and scanning/re-scanning the books. The embedded cover would not be selected.
• I then removed the books from ABS and scanned/re-scanned the books. The books just showed up without their embedded covers.

It should be possible to update a book to a new embedded cover without having to purge all of the metadata and deleting the items cache to fix them. I wanted to delete the item metadata cache for the updated books, but I was unsure how to locate it given their random-looking folder names.

Since the embedded cover can be found by the application, without having to delete a ton of files, I would still consider this a bug or a update that should be added.