Closed baconcow closed 1 year ago
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.
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.
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.
Can you share your full docker run command? And check errors inside the docker container logs.
Added the full Docker command that I used as well as an error screen when loading one of the books without a cover.
Can you try the following:
cover.jpg
and all image files stored with the audiobook.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
.
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.
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.
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.
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)?
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.
I am not familiar with Librivox. I embedded those custom covers with Mp3tag v3.1.8 (as with all of my covers).
I was just able to perform a full scan after doing the following:
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.
A few files needed their covers updated. I tried the following:
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.
Describe the issue
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
Audiobookshelf version
v2.2.11
How are you running audiobookshelf?
Docker