Jivelite doesn't display cover-art served by m.media-amazon.com

Max2Play Home 2016 (en) Forums Max2Play on Raspberry PI Jivelite doesn't display cover-art served by m.media-amazon.com

This topic contains 9 replies, has 2 voices, and was last updated by  MarioM Moderator 3 months, 1 week ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • 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.jpg

    The 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.png

    I 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?

    • This topic was modified 5 months ago by  StigN.
    • This topic was modified 5 months ago by  StigN.
    21. April 2020 at 16:52 #48575

    Hi 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 #48579

    Hi 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:

    [email protected]:~ $ 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 #48622

    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 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…

    • This reply was modified 4 months, 3 weeks ago by  StigN.
    • This reply was modified 4 months, 3 weeks ago by  StigN.
    28. April 2020 at 15:36 #48643

    Hi 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 #48649

    Hi 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:

    Link to discogs image which was shown on LMS web-interface, on SBTouch and on OrangeSqueeze android app – but not on my RPi3

    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.jpg

    All 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 #48650

    Of 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 #48652

    Just 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 #48946

    Could it be related to version of IO::Socket::SSL ?

    https://forums.slimdevices.com/showthread.php?99537-Announce-Music-amp-Artist-Information-plugin&p=977476&viewfull=1#post977476

    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 #48967

    Hi 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.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.

Register here