[bromix]

Hi,

today I noticed that my SoundCloud addon wasn't showing any thumbnails and I was investigating. First I thought I use a false url for the thumb, but all URLs work in the browser. For example this one:
https://i1.sndcdn.com/artworks-000071683...00x300.jpg

After debug-logging I found this:

Code:

18:30:01 T:2344   DEBUG: CTextureCacheJob::GetImageHash - unable to stat url https://i1.sndcdn.com/artworks-000071683213-nayj6f-t300x300.jpg

I changed the thumbnails to a fix random image on the net and it worked. So it hasn't to do with the addon or the url.

It seems that the routine behind this has trouble with Chunked Transfer from a server...because images with closed-transfer work.
https://github.com/xbmc/xbmc/blob/Helix/...b.cpp#L198

Result from the server for the image.

Code:

HTTP/1.1 200 OK
Content-Type: image/jpeg
Transfer-Encoding: chunked
Connection: close
Access-Control-Allow-Headers: Accept, Accept-Encoding, Authorization, Content-Type, Origin
Access-Control-Allow-Methods: GET
Access-Control-Allow-Origin: *
Cache-Control: public,max-age=31536000
Date: Wed, 25 Feb 2015 18:20:02 GMT
Age: 170308
X-Cache: Hit from cloudfront
Via: 1.1 9b873c22fb06a32f8142a90b7071aba9.cloudfront.net (CloudFront)
X-Amz-Cf-Id: H2wjZxp0HQODq1zWxwWfHwDzr9hJVNe6lO-xKyWggrTNl4xrZojMlw==

Can somebody confirm this? For now all thumbnails are missing in this addon. Chunked-Transfer is a common use to speed up data transfer (especially binary) so the caller hasn't to wait for calculated length from the server. Maybe there is a way to overcome this in some way? Can I do something on my side?

[Montellese]

The problem is that Kodi sends a HTTP HEAD request but and the server answers with a HTTP response without body (which is to be expected) but the response doesn't contain neither the "Content-Length" nor the "Last-Modified" header. The call to CFile::Stat() (which actually calls CCurlFile::Stat()) actually works but then the logic tries to retrieve either the creation/last modified time or the size. Therefore the check at https://github.com/xbmc/xbmc/blob/Helix/...b.cpp#L203 fails and it falls through to the error.

I'm not sure why the hash relies on the content-length and/or last modified time but I'm guessing it's a good indicator for whether a resource has changed i.e. if either of these two properties change, the generated hash will change and therefore the image needs to be re-fetched because it has changed. I guess we could add a fallback in case the CFile::Stat() call worked but neither of the two mentioned properties is set. For these images we won't be able to detect that they have changed but at least we can cache and display them.

I'll consult RFC2616 about whether a chunked transfer should return either of the two properties because then it would actually be an issue of the server (but I'm assuming they aren't mandatory).

[bromix]

The problem is that Kodi sends a HTTP HEAD request but and the server answers with a HTTP response without body (which is to be expected) but the response doesn't contain neither the "Content-Length" nor the "Last-Modified" header. The call to CFile::Stat() (which actually calls CCurlFile::Stat()) actually works but then the logic tries to retrieve either the creation/last modified time or the size. Therefore the check at https://github.com/xbmc/xbmc/blob/Helix/...b.cpp#L203 fails and it falls through to the error.

I'm not sure why the hash relies on the content-length and/or last modified time but I'm guessing it's a good indicator for whether a resource has changed i.e. if either of these two properties change, the generated hash will change and therefore the image needs to be re-fetched because it has changed. I guess we could add a fallback in case the CFile::Stat() call worked but neither of the two mentioned properties is set. For these images we won't be able to detect that they have changed but at least we can cache and display them.

I'll consult RFC2616 about whether a chunked transfer should return either of the two properties because then it would actually be an issue of the server (but I'm assuming they aren't mandatory).

A fallback would be awesome. The other solution would be to download each thumb (via the addon)...but this will slow things down. Is there anything I can do...or least an issue via GitHub I can follow? Because user will ask why the thumbs are missing and it would be nice if I could direct them.

[Montellese]

See PR6562. Maybe it can also be backported to Helix.

[bromix]

Thanks man backport to Helix would be nice

[pancheto]

this same error has recently started to happen with filmaffinity addon (metadata.filmaffinity.com). is there anything we can do from the scraper side, or is this a problem with Kodi handling incorrect/invalid/incomplete image information? if so, how could we suggest an alternative such as the fallback mentioned above?

here is an example that isn't being displayed in Kodi:

Code:

23:06:11.702 T:7996   ERROR: CCurlFile::Stat - Failed: HTTP response code said error(22) for https://pics.filmaffinity.com/unknown-930984351-large.jpg
23:06:11.702 T:7996   DEBUG: CTextureCacheJob::GetImageHash - unable to stat url https://pics.filmaffinity.com/unknown-930984351-large.jpg

#s3gt_translate_tooltip_mini { display: none !important; }

[andy-g]

I'm getting the same issue, for my RedbullTv addon:

Code:


08:40:53.763 T:123145376391168   DEBUG: GetImageHash - unable to stat url https://resources.redbull.tv/AP-1TPK2VN3...w_300,q_70
08:40:55.721 T:123145374781440   DEBUG: Thread JobWorker start, auto delete: true
08:40:55.722 T:123145374781440    INFO: easy_aquire - Created session to https://resources.redbull.tv
08:40:55.776 T:123145375854592   DEBUG: GetImageHash - unable to stat url https://resources.redbull.tv/AP-1QG7A6VK...w_300,q_70
08:40:56.204 T:140737159402432   DEBUG: ------ Window Deinit (Pointer.xml) ------
08:40:56.448 T:123145376391168   DEBUG: GetImageHash - unable to stat url https://resources.redbull.tv/AP-1TMJM1N2...w_300,q_70
08:40:56.457 T:123145374781440   DEBUG: GetImageHash - unable to stat url https://resources.redbull.tv/AP-1QVQ86MX...w_300,q_70


Is there anyway to bypass the check, or just check for a cached copy against the url?

[glennguy]

Having the same problem here too. HEAD returns 404, whereas GET returns 200. Would be great to be able to signal Kodi to go straight for a GET.

[-Dis]

Sorry for bumping old thread but I just found out this same problem when trying to get artwork quality limit working in discovery+ add-on. Currently only solution I found was to make proxy for images but I don't like that.

Code:


2022-02-16 19:20:14.372 T:162842   DEBUG <general>: Curl:ebug - TEXT: The requested URL returned error: 404 
2022-02-16 19:20:14.372 T:162842   DEBUG <general>: Curl:ebug - TEXT: stopped the pause stream!
2022-02-16 19:20:14.372 T:162842   DEBUG <general>: Curl:ebug - TEXT: Connection #0 to host eu1-prod-images.disco-api.com left intact
2022-02-16 19:20:14.372 T:162842   DEBUG <general>: GetImageHash - unable to stat url https://eu1-prod-images.disco-api.com/20...=true&q=80