starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Enhancement] Cover image downsizing when adding a new book #118

New Issue
Closed
opened 2026-04-24 22:58:55 +02:00 by adam · 5 comments
adam commented 2026-04-24 22:58:55 +02:00
Owner
Copy Link
Copy Source

Originally created by @scorpio862 on GitHub (Dec 7, 2021).

At the moment, Audiobookshelf is using the covers in original size. This could potentially slow down the page load times as some of the covers can be in high resolution.

There needs to be a process which will downsize the cover.jpeg files in metadata folder to 208x332px (or whatever is the highest image size used by audiobookshelf). There is no need (at least at the moment) to have the covers in high resolution.

I noticed that some of my covers in the medatadata folder are more than 2MB. I have 425 audiobooks and all the covers in total have around 19MB and this is a lot of loading.

Originally created by @scorpio862 on GitHub (Dec 7, 2021). At the moment, Audiobookshelf is using the covers in original size. This could potentially slow down the page load times as some of the covers can be in high resolution. There needs to be a process which will downsize the cover.jpeg files in metadata folder to 208x332px (or whatever is the highest image size used by audiobookshelf). There is no need (at least at the moment) to have the covers in high resolution. I noticed that some of my covers in the medatadata folder are more than 2MB. I have 425 audiobooks and all the covers in total have around 19MB and this is a lot of loading.
adam added the enhancement label 2026-04-24 22:58:55 +02:00
adam closed this issue 2026-04-24 22:58:55 +02:00
adam commented 2026-04-24 22:58:56 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Dec 7, 2021):

Yeah this is a big one for performance. When I was working on the lazy bookshelf I also noticed that the cover image load times could be improved.
There will be some logic to change when it comes to saving cover image paths. All cover paths will point to the metadata directory, instead of the audiobook directory if you have that server setting enabled.

I am also a fan of low quality image placeholders. This would mean potentially generating 2 images per cover. One of them being very small like 25px width that is used until the other image loads. Might not be necessary in this case, but if you have used Google photos they do this and have one of the best user experiences in that regard.

@advplyr commented on GitHub (Dec 7, 2021): Yeah this is a big one for performance. When I was working on the lazy bookshelf I also noticed that the cover image load times could be improved. There will be some logic to change when it comes to saving cover image paths. All cover paths will point to the metadata directory, instead of the audiobook directory if you have that server setting enabled. I am also a fan of [low quality image placeholders](https://www.guypo.com/introducing-lqip-low-quality-image-placeholders). This would mean potentially generating 2 images per cover. One of them being very small like 25px width that is used until the other image loads. Might not be necessary in this case, but if you have used Google photos they do this and have one of the best user experiences in that regard.
adam commented 2026-04-24 22:58:57 +02:00
Author
Owner
Copy Link
Copy Source

@Jdiesel87 commented on GitHub (Dec 8, 2021):

Agreed it is amazing how small of a file size you can get away with when the image is in the proper format, using the right compression and scaled correctly for the viewing screen.

Do the clients store cached images locally at the moment?

@Jdiesel87 commented on GitHub (Dec 8, 2021): Agreed it is amazing how small of a file size you can get away with when the image is in the proper format, using the right compression and scaled correctly for the viewing screen. Do the clients store cached images locally at the moment?
adam commented 2026-04-24 22:58:57 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Dec 13, 2021):

v1.6.40 was just pushed that downsizes covers and uses webp if accepted. Covers are cached on the server in /metadata/cache/covers. Cache can be purged with a button on the config page.

@advplyr commented on GitHub (Dec 13, 2021): `v1.6.40` was just pushed that downsizes covers and uses webp if accepted. Covers are cached on the server in `/metadata/cache/covers`. Cache can be purged with a button on the config page.
adam commented 2026-04-24 22:58:57 +02:00
Author
Owner
Copy Link
Copy Source

@scorpio862 commented on GitHub (Dec 13, 2021):

This is grat. The page loads much faster. The total size of cover images was cut by half. Some cover are showing now as "Invalid Covers" for some reason but it is not a huge problem. I just had to find new images on google.

Is is possible to get the android app to store the covers localy on the phone?

@scorpio862 commented on GitHub (Dec 13, 2021): This is grat. The page loads much faster. The total size of cover images was cut by half. Some cover are showing now as "Invalid Covers" for some reason but it is not a huge problem. I just had to find new images on google. Is is possible to get the android app to store the covers localy on the phone?
adam commented 2026-04-24 22:58:57 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Dec 17, 2021):

There were some issues with the covers that were resolved in the last update.
Yes, I think the mobile app will eventually cache cover images but not a priority atm.

@advplyr commented on GitHub (Dec 17, 2021): There were some issues with the covers that were resolved in the last update. Yes, I think the mobile app will eventually cache cover images but not a priority atm.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#118
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?