mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Bug]: Author images not showing on 2.30.00 #3033
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#3033
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 @wylie102 on GitHub (Oct 9, 2025).
What happened?
After updating to 2.30.00 if I go to the Authors tab I cannot see any images. I instead get the question mark/image unable to load icon (see images below). I have tried this in safari, Vivaldi, and in an iOS app with the same results.
Refreshing, or restarting the server/container did not solve the issue.
What did you expect to happen?
I expected to be able to see/load the authors images.
Steps to reproduce the issue
Audiobookshelf version
2.30.00
How are you running audiobookshelf?
Docker
What OS is your Audiobookshelf server hosted from?
Other (list in "Additional Notes" box)
If the issue is being seen in the UI, what browsers are you seeing the problem on?
None
Logs
Additional Notes
I have tried different browsers and an iOS app. I have tried re-matching all authors but the images seem to be there they just won't preview.
Audiobookshelf is running on Home Assistant (HAOS which is linux based) as an add on, basically in docker. The add on is here and is basicallt just a wrapper around the docker compose.
@Vito0912 commented on GitHub (Oct 9, 2025):
Did you try clearing the cache?
@wylie102 commented on GitHub (Oct 9, 2025):
I've just done that now and no improvement
@Vito0912 commented on GitHub (Oct 9, 2025):
After clearing the cache it sometimes takes a minute until it gets shown again.
If there is no improvement please send a log from the client side and check with which error code the request fails
@wylie102 commented on GitHub (Oct 9, 2025):
How do I get the client side logs or see the error code? I opened the log in the settings in audiobookshelf but it has the same data as the log that I see from Audiobookshelf server.
I set it to debug.
Here are some logs from going to the home page
and then to the authors page
then clicking on an author
Then if I right click on the image and try to open it in a new tab, the new tab simply says "not found" and there are no further log entries for that action.
@Vito0912 commented on GitHub (Oct 9, 2025):
These are server side logs. Important are the client logs.
Where to get this depends on your used browser. You need to navigate to the console to see the logs of the client and you need to navigate to some kind of network tab to view the requests and response codes.
@wylie102 commented on GitHub (Oct 9, 2025):
Got it (I think), this is just one of them. I couldn't see an efficient way to get them all. But they're all error 404 not found and then just different hashes for the different images/author ids I think.
Summary
URL: http://192.168.4.164:13379/audiobookshelf/api/authors/35724905-8a75-4f56-b34e-a9cf0cf5520a/image?ts=1759831806333
Status: 404 Not Found
Source: Network
Address: 192.168.4.164:13379
Initiator:
bde4e3a.js:2619
Request
GET /audiobookshelf/api/authors/35724905-8a75-4f56-b34e-a9cf0cf5520a/image HTTP/1.1
Accept: image/webp,image/avif,image/jxl,image/heic,image/heic-sequence,video/;q=0.8,image/png,image/svg+xml,image/;q=0.8,/;q=0.5
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en;q=0.9
Connection: keep-alive
Cookie: connect.sid=xxxx; refresh_token=xxxx
If-None-Match: W/"9-0gXL1ngzMqISxa6S1zx3F4wtLyg"
Priority: u=5, i
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0.1 Safari/605.1.15
Response
HTTP/1.1 404 Not Found
Connection: keep-alive
Content-Length: 9
Content-Type: text/plain; charset=utf-8
Date: Thu, 09 Oct 2025 10:30:44 GMT
ETag: W/"9-0gXL1ngzMqISxa6S1zx3F4wtLyg"
Keep-Alive: timeout=5
Referrer-Policy: no-referrer
Query String Parameters
ts: 1759831806333
Is this helpful?
@wylie102 commented on GitHub (Oct 9, 2025):
Just to update you, I added a book by a new author and after quick matching then the image for them does display. Also, if I delete the image for an author and then quick match them the image also displays.
So I guess maybe after the update perhaps either the location of the previous author images got scrambled or that destination is somehow inaccessible to the server? Have you managed to recreate the issue? I'd be interested to know whether this is just related to me or to the home assistant add-on.
(Unfortunately there doesn't seem to be a way to batch-delete all the author images like you can using quick match, or to select multiple like you can with the audiobooks. So the current solution involves deleting all the images manually and then quick matching again.)
@Vito0912 commented on GitHub (Oct 9, 2025):
Did you update once before this happened (so is this your first update)?
@Vito0912 commented on GitHub (Oct 9, 2025):
Btw. you should never share your tokens (aboves request), even if it's just a local server
@wylie102 commented on GitHub (Oct 9, 2025):
Yes I think this is the first update as the previous one 2.29 was in August and I wasn't using Audiobookshelf then.
Thanks, I didn't spot them in there. I've redacted them now.
@Vito0912 commented on GitHub (Oct 9, 2025):
Can you please share your docker compose file (or the HA equivalent). This could be a faulty metadata mount then
@wylie102 commented on GitHub (Oct 9, 2025):
Sure, the files are in the repo I shared in the initial comment it's this repo. There are two add-ons in there, this is the audiobookshelf one, and this appears to have been the latest commit changing from 2.29 to 2.30.
I created an issue with them as well, I referenced this issue in it so there's a cross-link in the thread above, but it's here if you spot anything incorrect and want to give them some guidence on how to fix it or avoid it happening on future updates.
@advplyr commented on GitHub (Oct 9, 2025):
Author images are stored in
/metadata/authorsand the cached image is stored in/metadata/cache/images. Make sure you can access these directories outside of the docker container.@Vito0912 commented on GitHub (Oct 9, 2025):
As the ha repo is newer than any update of ABS it's somewhat likely that the ha repo has some misconfiguration. Especially since there are no other reports
I sadly do not understand that syntax 100%. But as advplyr stated as long as the files in there are untouched everything should work.
If you can validate that they are still in there, then it's an issue with ABS, otherwise it's an issue with the ha repo.
@wylie102 commented on GitHub (Oct 9, 2025):
This is where we have a bit of an issue, It's not possible to access any of the containers file systems from outside the container in HAOS, it's designed that way and the maintainers won't change it as it will likely cause more issues (for them) than it helps solve. Add-ons are designed to be run as standalone containers with setting exposed by a configuration page.
I can access them using portiainer, and can confirm that those folders are present and they contain jpgs
But I don't think this counts as accessing from outside the container.
The file system not being exposed doesn't seem to have prevented the metadata or author information from being accessed previously, I suspect it's possible that it got wiped during the upgrade as I think most add-on files are by default unless they are in a shared folder like the ABS sqlite file is. So that is a fault of the add-on config. The main ABS issue is that although the files are deleted, the reference to them remains and is passed on to the client for retrieval without checking the file still exists first.
If that happened would you get these 404 errors? As in, once the image is downloaded and it's location recorded in the DB, are there any checks to verify that the files are still present before attempting to display them in the client? Or is the logic that if there is a reference then go directly to providing the location to display it?
For example, if an author picture has been retrieved and I were to manually delete it using the file browser not ABS (or it was deleted/corrupted due to an error), would the ABS UI recognise that and display this?
Or would it try to display the image and therefore get a 404?
Yes I think the maintainer needs to make sure that the metadata folders persist after upgrade, I think by default all files that aren't shared are deleted, the database is shared/visible in the add-on config folder so it persists but the metadata ones don't.
Real ABS bug (I think, based on limited knowledge)
I guess the main bug on your end is that if the author image files are deleted, the reference (presubmably in the DB) remains and the existance of the file isn't checked before passing the location to the client for retrieval, so you get the 404 errors when trying to view them. Plus then the user manually has to delete each "photo" to fix it, but they're actually deleting the reference.
The expected function would be that if the files are deleted/missing in the file system then this is detected on an if-exists check prior to allowing the client to attempt to retrieve it. If it doesn't exist the DB reference is removed and the image returns to the default and the user can simply quick match without deleting first? Does that make sense? I guess it's up to you guys whether you consider that a bug or how you would prioritise it.
But yes the main cause is in the add-on configuration I think. I'm happy for the issue to be closed from the point of view of the ABS update not causing it, but I'll leave you guys to decide whether to just close it or to assign a bug around the referencing of deleted files/images.
@nichwall commented on GitHub (Oct 9, 2025):
How are the audio file mounts (to persist outside of the container) set up? This would be the same issue where media uploaded through the ABS interface would be lost on upgrades if they aren't persisting the data outside of the container.
By design, anything stored inside of a container is deleted when it is upgraded/replaced, so files need to be persisted outside of the container, typically using a volume mount or bind mount.
@wylie102 commented on GitHub (Oct 9, 2025):
I don't know how they are set up. @bigred10151990 is the maintainer for the repo.
All I can tell you is that the only issue I had was with the authors. All the media worked fine, although I don't upload it through the ABS interface, I just put it in the watched folder under an author/book folder. I don't know whether it had to re-read/download all the metadata in the background after the upgrade, I have it set up to store the cover images with the media so perhaps that helped.
From what I know HAOS simply runs the docker compose file, but there is a page on how to set them up as "add-ons" here. I haven't really looked into how this side of it works as I've always managed to find an add-on already made by someone, it might make more sense to you.
The map section seems to be the relevant one.
But like I said, I'd be coming to this cold (I don't know what the terms volume mount or bind mount mean in this context) so it would take me a while to start to understand it properly.
Edit: for reference my audiobook files are stored in media. For me this happens to be on the same hard drive, but within that folder are also any NAS/external volumes that the user has integrated with home assistant. So within media I have Audiobooks - same hard drive, and video - on my NAS.
Addon_config is where there is an Audiobookshelf folder that contains the sqlite file, that persists between builds. The addons folder itself always appears empty, whether accessed through SMB or through terminal within HAOS. I assume it's where the container files are stored but they are just not accessible to users.
@Vito0912 commented on GitHub (Oct 9, 2025):
I wouldn't count this at a bug at all. This is a directory a user never should touch, thus it's auto-generated.
If you delete random files from your operating system that you are not supposed to touch it won't work too. There could be better error handling, yes, but this is an configuration error then, which is the real error here.
Although from your image above the .jpg seem to be correct. Are these the one you added after the upgrade?
@bigred10151990 commented on GitHub (Oct 9, 2025):
I will need to look into this for you. I have all of my mappings on a network folder myself. I'm not sure why the metadata folder would have been wiped on an update like that off hand. this is my first addon so I don't have a ton of experience. I may look at moving the default mounts to Media instead of Addon_Config as that should persist. Sorry that you ran into this issue and thank you for tagging me.
@advplyr commented on GitHub (Oct 9, 2025):
In some cases the user has changed their mount path when running the docker container without realizing it and if we removed all the references to the files on startup it would be irreversible without restoring a backup. I think returning 404s is correct in this case.
@wylie102 commented on GitHub (Oct 9, 2025):
Yes I had already gone through and manually "deleted" all of the author photos in the ABS interface and then clicked on match all authors again, it was the only way that I could find to fix the issue. I had done this before I remembered that there was a portainer add on that could be used to view the file system within the containers themselves.
So I don't actually know that the original .jpg files were deleted, it's just my best guess. It's possible there was another cause.
I could try manually deleting a couple of jpg files again to see if that reproduces the problem? But I guess we still wouldn't know whether originally the folder was emptied, or whether there is a random misnamed authors dir full or .jpg files somewhere on my system.
Good point, I was just highlighting what I thought was actually triggering the 404 error. I already said the root cause was the config error. I wasn't trying to push anything on you, whcih was why I finished by saying it was up to you guys whether you thought the 404 part was actually an issue at all.
Thanks for your help today @Vito0912 and @advplyr and @nichwall, it's nice to see such responsive and dedicated maintainers.
@wylie102 commented on GitHub (Oct 9, 2025):
Makes sense, I think outside of a config error the folder being deleted is probably pretty rare and at least this way there is some visual feedback that something is wrong.
@bigred10151990 commented on GitHub (Oct 9, 2025):
I have run a few testes on my end. The metadata folder was cleared when the addon was updated. this would have caused anyone using the default mapping for metadata and backups to get cleared when updating. I'll be releasing an update to add access to the backup folder and updating the default config to move the metadata folder to /config/metadata and the backup folder to /backup/audiobookshelfserver.
Very sorry about this @wylie102. let me know if you run into any issues going forward and I will get them fixed for you as fast as I can. I'll have the update out later today.
@advplyr Sorry this ended up in your issues list.
@wylie102 commented on GitHub (Oct 9, 2025):
@bigred10151990 No problem, it wasn't a big deal. And I learned a bit about it all while working out what the issue was.
Thanks for the help everyone. I'll close the issue now.