Yes I know but due to bugs with reverse proxies (You returned the IP of the host not the proper public one, maybe it was fixed) I rewrite the urls and so can also pass any headers or parameters they added to protect the server.
This was fixed, now the user can configure the public URL if ND cannot figure it out automatically.
Ah, I see. Yeah, that makes sense, but if the URL is public, seems that it is a misconfiguration of the proxy, as it should allow access without any authentication
This is after checking an artist that has an artist.jpg in the artist folder, not even an external request. One thing to note, my server doesn’t support http, only https, because my isp blocks port 80 and only allows 443, so maybe that has something to do with it?
logs.txt.json (79.9 KB)
Here are the full navidrome logs, with debug log level and I did a sync in symfonium. I added .json to the filename so I could upload it
Yeah, my bad. I’m used to Subsonic image endpoints that returns a XML response on errors, with status 200!
@ULJgN Unfortunately the logs do not contain any useful info. Is your server publicly available? If so, can you please send me the URL for the image, so I can see the message?
Here’s something interesting: one artist that I manually added an image for was always using a square image, and it loads in symfonium. The artist I’ve been using as an example (which I manually added an image for) was a rectangular image, but I thought maybe that interfered with symfonium loading it so I changed it to a square one, but when I loaded the image on the web interface just now and opened it in a new tab to get the url, it was still the rectangular one. Maybe it’s still cached, and symfonium doesn’t like rectangular images?
That doesn’t account for external integration images not loading in symfonium though
Symfonium use the result from getArtistInfo2 when users enable the option to fetch additional metadata.
This was necessary to force servers to do the external source thumbnail fetching and return the possible external images.
When you reworked that endpoint to always return urls then Symfonium had no way to know there’s urls even if there’s nothing on the other side, and so will always use that url as it’s sent by the server so supposed to be valid and better than the coverArt.
How it’s handled on Navidrome side to properly decide what to return on those urls is fully internal to Navidrome.
I’m not saying Symfonium is doing anything wrong, just stating that the two endpoints have this difference: one is public (no need to authenticate) and the other is private. Internally the art resolution is the same.
The only reason the public URL (from getArtistInfo) would return a 400 is if the JWT param is invalid. This could happen because:
It was encoded with a different JWT token secret (it changed in 0.54.x)
It does not contain an ID or the ID is invalid.
Now thinking more about this, maybe the URL was cached from a previous version of Navidrome, and after the upgrade it is now invalid?
That’s why I’m trying to see the message returned by the 400 error