Max2Play Home › Forums › Max2Play on Raspberry PI › Jivelite doesn't display cover-art served by m.media-amazon.com
- This topic has 9 replies, 2 voices, and was last updated 4 years, 5 months ago by MarioM Moderator.
-
Posted in: Max2Play on Raspberry PI
-
18. April 2020 at 11:37 #48546
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?
21. April 2020 at 16:52 #48575Hi StigN,
Are the cover arts displayed in the Squeezebox server web interface? If so, the problem may be with Jivelite. We were able to successfully test the download of a jpg from Amazon to the Pi on site. Please test a simple wget on an image from your Pi. Your device may have been blocked due to too much access. Nevertheless, some pictures seem to have been retrieved successfully.
21. April 2020 at 20:00 #48579Hi Mario
Thanks for the response.
The device being blocked by Amazon sounded like a plausible theory, unfortunately/luckily that doesn’t seem to be the issue. I can download from the RPi3 using wget it seems:pi@m2p-livingroom:~ $ wget https://m.media-amazon.com/images/I/414x7CvevDL.jpg --2020-04-21 19:40:07-- https://m.media-amazon.com/images/I/414x7CvevDL.jpg Resolving m.media-amazon.com (m.media-amazon.com)... 151.101.129.16, 151.101.193.16, 151.101.65.16, ... Connecting to m.media-amazon.com (m.media-amazon.com)|151.101.129.16|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 22700 (22K) [image/jpeg] Saving to: ‘414x7CvevDL.jpg’ 414x7CvevDL.jpg 100%[=====================================================================>] 22.17K --.-KB/s in 0.008s 2020-04-21 19:40:07 (2.58 MB/s) - ‘414x7CvevDL.jpg’ saved [22700/22700]
Yes album-art is visible on the Squeezebox server web interface – or LMS web-ui as I call it (Logitech Media Server). It is also visible on my original SB-Touch and on Orange Squeeze Android app.
I updated Max2Play to latest 2.52 yesterday, including another Jivelite update it looked like. But no, still no cover-art from m.media-amazon.com. Weird…
If anyone feel like trying the KCRW plugin for LMS, install as described at
https://forums.slimdevices.com/showthread.php?112001&p=971466&viewfull=1#post971466
and play the stream:
http://media.kcrw.com/pls/kcrwmusic.pls/Stig
26. April 2020 at 20:24 #48622While 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 fastly
C:\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,VE1
I’m not an expert in those headers. But I don’t think there’s anything very suspicious here?
I’m so lost…
28. April 2020 at 15:36 #48643Hi StigN,
In order to solve your problem, we have to recreate the setup and debug. This may take some time due to the current situation. It may be that Jivelite has problems with SSL, as it may use an older version or an older HTTP standard to retrieve the images. Although the pictures should actually run on the Squeezebox server and should be cached there. In this case, wget cannot really show this and if the server is running on another device, you would have to do the wget from there. However, your specified link to the picture does not work for us at all.
28. April 2020 at 18:24 #48649Hi MarioM
I’m very grateful if you take the time to recreate my setup to help. Even if it takes some time.
I see my discogs image link doesn’t work. It is also a very long and complex address, maybe the forum software f*cked it up. I try again:But doesn’t the other links I have posted works for you? They work for me in this forum too:
https://m.media-amazon.com/images/I/414x7CvevDL.jpg (Works everywhere for me except RPi3)
https://m.media-amazon.com/images/I/414x7CvevDL._SL300_.jpg (Works everywhere for me except RPi3)
https://is2-ssl.mzstatic.com/image/thumb/Music123/v4/2f/f6/39/2ff63936-6cd0-01b1-efb1-06a5ed671cab/source/200x200bb.jpg (Works everywhere INCLUDING on RPi3)The following one also works for me, including on the RPi3. For some reason LMS in this case decided to cache it via it’s own proxy. I don’t know when that happens and when it doesn’t? But when it is shown like that in LMS webinterface, it also shown on the RPi3. But Of course this link doesn’t work for you, because it points to my local „intranet“ LMS:
http://192.168.1.151:9002/imageproxy/https%3A%2F%2Fimages-na.ssl-images-amazon.com%2Fimages%2FI%2F61woa6C3PCL._SL300_.jpg/image.jpgAll the image URLs I have posted is taken from LMS web-interface ( = Squeezebox Server web-interface) by right clicking the shown artwork. Of course I don’t know if is the exact same URLs which are sent to the various devices. If it makes a difference, please also notice that I’m running LMS on a Synology NAS, not on the RPi3. The RPi3 is a player only. I will try to find out to do a wget on the Synology too…
/Stig
28. April 2020 at 18:33 #48650Of course it is also a problem that I updated several things at once. Including LMS792 to LMS800 (I’m using Pinkdot’s LMS distribution: https://forums.slimdevices.com/showthread.php?111876 ).
It is easiest to suspect Jivelite, but I guess it would have been much better if I had taken my updates steps by step and verified everything a couple of days between steps :-/ …PS. Discogs-image link in previous comment works for me now here in this forum.
28. April 2020 at 19:06 #48652Just managed to check:
All images can also be downloaded from my LMS-hosting Synology NAS using wget.
I had to put quotes around the complex discogs-url, but yes it also worked.5. Juni 2020 at 9:36 #48946Could it be related to version of IO::Socket::SSL ?
Just yesterday, a Max2play 2.52 (Mar 2020) system based on Jessie with IO::Socket::SSL: 2.002 (released in 2014 ! ) failed to access some https metadata connections. The same system had OpenSSL of 1.0lts.
9. Juni 2020 at 14:48 #48967Hi StigN,
That could actually be the reason. We no longer actively support our old Jessie image. Because of this, some services under Jessie may no longer work properly today. Therefore please consider switching to our stretch or buster images. However, we recently had problems with an expired root certificate, which affected older versions of OpenSSL. We are currently working on finding solutions for this.
-
You must be logged in to reply to this topic.