- This topic has 9 replies, 2 voices, and was last updated 3 years, 10 months ago by
.
-
Hi!
I have noticed that my RPi3/Max2Play based „Squeezebox“ doesn’t show album-art when it is embedded from https://m.media-amazon.com/ , like f.ex:
https://m.media-amazon.com/images/I/414x7CvevDL.jpg or
https://m.media-amazon.com/images/I/414x7CvevDL._SL300_.jpg
But it shows fine on the RPi3 when f.ex. hosted on is2-ssl.mzstatic.com:
https://is2-ssl.mzstatic.com/image/thumb/Music123/v4/2f/f6/39/2ff63936-6cd0-01b1-efb1-06a5ed671cab/source/200x200bb.jpgThe m.media-amazon.com hosted cover-arts shows fine in LMS web-UI (this is where I find the image URLs), on my original Squeezebox Touch and on Orange Squeeze Android app. But not on my RPi3/Max2Play based player.
The problems started (or was discovered?) when testing a new LMS plugin for KCRW radio. In the beginning it was actually working fine for me, but then I did a couple of software updates including LMS792->LMS800 (Running on a NAS, not the RPi3) and latest available plugin-versions found from Max2Play’s built-in update-feature (including a Jivelite update). And after that I lost most cover-art from the KCRW station.
Currently most cover-art used by KCRW seems to be hosted on m.media-amazon.com. Most other sources seems to work, including the mentioned is2-ssl.mzstatic.com, but a station-art PNG hosted on kcrw.com ain’t shown either. I don’t if that is because Max2Play/Jivelite doesn’t support PNGs, or if it is same problem as with the m.media-amazon.com hosted cover-arts?:
https://www.kcrw.com/++theme++kcrw.theme/images/song-covers/default.pngI have also noticed cover-art sometimes are „cached“ via a proxy on my LMS installation, like http://192.168.1.151:9002/imageproxy/https%3A%2F%2Fimages-na.ssl-images-amazon.com%2Fimages%2FI%2F61woa6C3PCL._SL300_.jpg/image.jpg . When that happens, cover-art is shown fine on the RPi3 even if it originally came from an amazon domain. I don’t know when this caching happens though (and I have also noticed origin is actually another amazon domain. Coincidence?).
Why do I have this problem, and why didn’t I see it before doing software updates? I see several possibilities:
1) The updated version of Jivelite cannot show images embedded from m.media-amazon.com ?
2) Jivelite has never been able to show images embedded from m.media-amazon.com. The LMS-update cleared some proxy-cache it found most cover-arts in before I did the updates ?
3) KCRW by coincidence changed the primary source of their cover-arts at the same time as I did the software updates ?
4) ??Should I report this problem here, or is there a better place? I believe Max2Play is using their own version of Jivelite, but it could of course easily be a general problem for all (recent?) versions of Jivelite?
While playing Dandelion radio from the http://www.dandelionradio.com/DandelionRadio.pls stream, I noticed my RPi3 wont show the cover-art embedded from Discogs either. F.ex: this one ain’t shown:
https://img.discogs.com/wBpvmHQHXOvMUbKE-IdWamolUf0=/150×150/smart/filters:strip_icc():format(jpeg):mode_rgb():quality(40)/discogs-images/A-1741195-1427667902-1010.jpeg.jpg
Dandelion is new station for me, but I’m pretty sure it had cover-arts the first time I listened to it.
So I tried looking at headers when using curl (on my PC) to fetch some cover-art my RPi3 will show and some it wont show:
My RPi3 WORKS with images from is4-ssl.mzstatic.com, like:
C:\Users\Stig>curl --head https://is4-ssl.mzstatic.com/image/thumb/Music/v4/7f/a6/96/7fa696d6-c736-d7ef-67d5-fc6d9d432461/source/200x200bb.jpg HTTP/1.1 200 OK Server: ATS/8.0.7 Content-Type: image/jpeg Content-Length: 25986 X-Apple-Jingle-Correlation-Key: LZ5BTQSMCYRU6OV3N37EUG37NM X-Apple-Request-UUID: 5e7a19c2-4c16-234f-3abb-6efe4a1b7f6b apple-seq: 0.0 apple-tk: false Apple-Originating-System: UnknownOriginatingSystem Last-Modified: Sat, 25 Apr 2020 04:51:50 GMT ETag: "FDdRKLBuVYxmcanAoUBerA==" Access-Control-Allow-Origin: * Access-Control-Expose-Headers: Content-Length,Content-Type,ETag,Cache-Control,Expires,Last-Modified Strict-Transport-Security: max-age=31536000; includeSubDomains x-daiquiri-instance: daiquiri:13624002:mr85p00it-hyhk03094901:7987:20E24 CDNUUID: d510cb70-168a-477f-9ae0-dc1a618cd34a-967962253 Cache-Control: no-transform, max-age=14464339 Date: Sun, 26 Apr 2020 18:01:39 GMT X-Cache: TCP_MISS from a95-100-154-37.deploy.akamaitechnologies.com (AkamaiGHost/10.0.0.1-29304580) (-) Connection: keep-alive X-Cache-Remote: TCP_MISS from a2-16-128-197.deploy.akamaitechnologies.com (AkamaiGHost/9.9.4.2-29290934) (-)But it DOESN’T WORK with images from m.media-amazon.com or img.discogs.com, like:
C:\Users\Stig>curl --head https://m.media-amazon.com/images/I/51MO0of2EiL.jpg HTTP/1.1 200 OK Connection: keep-alive Content-Length: 63037 Content-Type: image/jpeg Expires: Fri, 09 Mar 2040 09:25:04 GMT Cache-Control: max-age=630720000,public X-Amz-IR-Id: c808de4f-73d1-4a64-ae7c-141a9a7be577 Timing-Allow-Origin: https://www.amazon.in, https://www.amazon.com Access-Control-Allow-Origin: * Last-Modified: Thu, 03 Nov 2016 22:53:15 GMT Accept-Ranges: bytes Date: Sun, 26 Apr 2020 18:21:10 GMT Age: 297202 X-Served-By: cache-dca17751-DCA, cache-cph20639-CPH X-Cache: HIT from fastly, HIT from fastlyC:\Users\Stig>curl --head https://img.discogs.com/wBpvmHQHXOvMUbKE-IdWamolUf0=/150x150/smart/filters:strip_icc():format(jpeg):mode_rgb():quality(40)/discogs-images/A-1741195-1427667902-1010.jpeg.jpg HTTP/1.1 200 OK Connection: keep-alive Content-Length: 3880 Cache-Control: max-age=315360000,public Content-Type: image/jpeg Etag: "007a18b23a1116239cb7f3d4cd758985e771dbce" Expires: Sat, 06 Apr 2030 08:34:42 GMT Server: nginx/1.16.1 Via: 1.1 varnish Accept-Ranges: bytes Date: Sun, 26 Apr 2020 18:22:21 GMT Via: 1.1 varnish Age: 1590458 X-Served-By: cache-sea4460-SEA, cache-cph20631-CPH X-Cache: HIT, HIT X-Cache-Hits: 1, 1 X-Timer: S1587925341.165648,VS0,VE1I’m not an expert in those headers. But I don’t think there’s anything very suspicious here?
I’m so lost…
:format(jpeg):mode_rgb():quality(40)/discogs-images/A-5825775-1563198450-4446.jpeg.jpg){kind=link}
You must be logged in to reply to this topic.