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]: Download cover art from servers which don't provide a content-type header #3078

New Issue
Open
opened 2026-04-25 00:13:32 +02:00 by adam · 0 comments
adam commented 2026-04-25 00:13:32 +02:00
Owner
Copy Link
Copy Source

Originally created by @jasonlearst on GitHub (Nov 6, 2025).

Type of Enhancement

Server Backend

Describe the Feature/Enhancement

When fetching cover art for podcasts use the URLs file extension to infer the image type received by the server if the server does not provide a content-type header in it's response.

Why would this be helpful?

When adding some podcasts to ABS they have the default cover image in my library. Checking the server logs I found:

[2025-11-06 02:11:43.764] ERROR: [CoverManager] Download image file failed for
"https://twit.cachefly.net/coverart/sn/sn2048clubtwitaudio.jpg?021325" Error: Invalid content type ""
    at /workspaces/audiobookshelf/server/utils/fileUtils.js:315:25
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {stack: 'Error: Invalid content type ""
    at /worksp…ions (node:internal/process/task_queues:95:5)', message: 'Invalid content type ""'}

Logger.js:114
[2025-11-06 02:11:43.765] ERROR: [PodcastManager] Download cover error from "https://twit.cachefly.net/coverart/sn/sn2048clubtwitaudio.jpg?021325":
 Failed to download image from url

Checking with cURL I received the following response:

> curl -I "https://twit.cachefly.net/coverart/sn/sn2048clubtwitaudio.jpg?021325"
HTTP/2 200
date: Thu, 06 Nov 2025 03:47:36 GMT
content-length: 279841
access-control-allow-origin: *
x-cfhash: "0aafae7b16ef8f426ebd892219899d9d"
x-cff: B
last-modified: Wed, 02 Oct 2024 21:59:51 GMT
x-cf3: H
cf4age: 0
x-cf-tsc: 1762395104
cf4ttl: 31536000.000
x-cf2: H
server: CFS 0215
x-cf1: 11796:fT.ord1:cf:nom:cacheN.ord1-01:P

Future Implementation (Screenshot)

Maybe the future implementation could infer the content type from the URL?

Audiobookshelf Server Version

v2.30.0

Current Implementation (Screenshot)

No response

Originally created by @jasonlearst on GitHub (Nov 6, 2025). ### Type of Enhancement Server Backend ### Describe the Feature/Enhancement When fetching cover art for podcasts use the URLs file extension to infer the image type received by the server if the server does not provide a `content-type` header in it's response. ### Why would this be helpful? When adding some podcasts to ABS they have the default cover image in my library. Checking the server logs I found: ```bash [2025-11-06 02:11:43.764] ERROR: [CoverManager] Download image file failed for "https://twit.cachefly.net/coverart/sn/sn2048clubtwitaudio.jpg?021325" Error: Invalid content type "" at /workspaces/audiobookshelf/server/utils/fileUtils.js:315:25 at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {stack: 'Error: Invalid content type "" at /worksp…ions (node:internal/process/task_queues:95:5)', message: 'Invalid content type ""'} Logger.js:114 [2025-11-06 02:11:43.765] ERROR: [PodcastManager] Download cover error from "https://twit.cachefly.net/coverart/sn/sn2048clubtwitaudio.jpg?021325": Failed to download image from url ``` Checking with cURL I received the following response: ```bash > curl -I "https://twit.cachefly.net/coverart/sn/sn2048clubtwitaudio.jpg?021325" HTTP/2 200 date: Thu, 06 Nov 2025 03:47:36 GMT content-length: 279841 access-control-allow-origin: * x-cfhash: "0aafae7b16ef8f426ebd892219899d9d" x-cff: B last-modified: Wed, 02 Oct 2024 21:59:51 GMT x-cf3: H cf4age: 0 x-cf-tsc: 1762395104 cf4ttl: 31536000.000 x-cf2: H server: CFS 0215 x-cf1: 11796:fT.ord1:cf:nom:cacheN.ord1-01:P ``` ### Future Implementation (Screenshot) Maybe the future implementation could infer the content type from the URL? ### Audiobookshelf Server Version v2.30.0 ### Current Implementation (Screenshot) _No response_
adam added the enhancement label 2026-04-25 00:13:32 +02:00
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#3078
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?