mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
App Crash and Covers invalid #128
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#128
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 @MidnightSnowleopard on GitHub (Dec 13, 2021).
After updating from 1.6.38 to 1.6.40 I removed all libraries and configuration entirely after having some issues with it suddenly not displaying covers correctly. A fresh install with new data rescanned the library I had previously and is still coming up with issues regarding covers.
Initial scan of new library finishes but upon loading the main library page the application crashes with the following:
Reloading it seems to work and it continues on but continued issues.
Loading the main library page starts immediately showing issue as instead of images a number of covers simply don't load at all. Checking browser console shows 404 errors for what I assume to be all failed to load covers. Clicking onto one of the blank covers load the book information but the image cover displays the "Invalid Cover" image from audiobookshelf. Not all covers are affected by this issue.
Logs during a rescan include a large number of messages like this:
Force rescanning the library seems to clear up the blank covers and they instead show the default blank cover image. I think there's something going wrong with the embedded image extraction. The ones that seem to having issues all seem to be ones that have embedded covers. Rescanning one of them that had an issue shows this sort of message in the logs:
@keaganhilliard commented on GitHub (Dec 13, 2021):
This happens in my library when the book in question doesn't have a
coverFullPathattribute. So it seems like that attribute isn't set when the cover image is extracted from the audiobook. As for the unsupported format error, do you have local cover files?@MidnightSnowleopard commented on GitHub (Dec 13, 2021):
For some of them, yes there is external local cover files. I don't think there are many of this type though and certainly not nearly anywhere near the number having issues. I also checked some of them stating that the cover had been removed but it hadn't. It was/is still accessible in the metadata folder in question.
@advplyr commented on GitHub (Dec 14, 2021):
This should hopefully 🤞 be fixed now in
v1.6.41@MidnightSnowleopard commented on GitHub (Dec 14, 2021):
Upgraded to v1.6.41 and purged cache and performed force rescan of the library with no change. Completed delete all metadata and configuration and rescanned. New scan looks much better with significantly better with far more showing up. There are still a handful of of covers that are left spinning for an extended period upon initial load before transitioning to a 404 error in library view and invalid cover on individual book view.
Logs from the container suggest some back end errors:
and
@advplyr commented on GitHub (Dec 14, 2021):
Ffmpeg is having trouble with some image embedded in your audio files. Did you embed those images yourself?
If you look in the folder of that audiobook, is it creating an image file? Maybe it is failing part-way through extracting the cover image, so the image is invalid.
@advplyr commented on GitHub (Dec 15, 2021):
I just pushed a patch, same version number, that added additional error logs.
@MidnightSnowleopard commented on GitHub (Dec 16, 2021):
So that seems to have clarified some with some of the files it's indexing being legitmately corrupted entirely. There is also some that are just failing to convert. This is one of the messages of that type:
There is also an issue with embedded when doing a library force refresh. When this new version came out I updated to it and activated a normal library rescan. This did not change anything so I initiated cache purged and then a force rescan. The messages from the library include many like these ones:
These are all embedded ones and are removed. Watching the library live as the rescan happens shows covers continually being removed from those items that have embedded covers. The actual cover listed in the metadata path however is never deleted. Seems like somehow it thinks it needs to remove the cover which is tries to do but fails or has a race condition on for the forced rescan but then when it comes back around to extract the embedded cover it bails due to the presence of a cover existing in the metadata folder path for the book. The only way to have extracted covers again on those items is to delete them from library and scan again to re-import them.
@advplyr commented on GitHub (Dec 16, 2021):
Thanks for all that info and logs, I found the issue with the covers getting removed. I pushed an update
v1.6.42There will still be the issue with the Ffmpeg command failing, but the error didn't show anything useful to go off of. Did you check that cover image in the file system to make sure you could open it and it wasn't corrupt?
@MidnightSnowleopard commented on GitHub (Dec 16, 2021):
The fix for the covers being removed on force re-scan is now fixed. Had to remove and re-add everything again but it now appears stable.
Unsure what the ffmpeg issue is. The files do show correct icons in explorer and checking the metadata given in the UI shows that there is a cover successfully extracted by Audiobookshelf itself. They are perfectly accessible and renderable outside of the program. Still investigating but all the ones that are having issues have the cover stored as a video track in PNG format. Possible that somehow that's tripping up the ffmpeg that is being used.
@advplyr commented on GitHub (Dec 19, 2021):
Embedded images in audio files should always show as a video track.
It might be specific to the webp encoding.
@MidnightSnowleopard commented on GitHub (Dec 26, 2021):
Agreed, something with some of the covers doesn't convert well. Oddly though after doing another force re-scan to update my library for other reasons it has again started exhibiting the behavior of losing covers on ones it previously had.
Further force re-scans continue to display the message of
The cover still exists on the filesystem under the metadata for the book. All of them affected seem to be explicitly embedded covers. There's considerably less of them affected by whatever is causing this as compared to before but it does still happen.
@advplyr commented on GitHub (Dec 26, 2021):
Do you have the server setting enabled to auto search and use covers?
If you have debug logs enabled, I'm wondering if you see this log
[Audiobook] "${this.title}" Check scan book cover removed.Debug logs can be toggled on in the config -> logs page.
That log you showed will only print if the audiobook has embedded cover art, a cover image already in your filesystem, and the audiobook has an empty cover field. This means at some point the cover field on that audiobook is getting reset.
@MidnightSnowleopard commented on GitHub (Dec 27, 2021):
Another two rebuilds and several force re-scans later and it has decided to have no further problems. I can't reproduce so I'd say this is solved entirely.
Thanks for all the awesome work.