search

jesus2099 / konami-command

power‐ups for various web sites
121 stars 25 forks source link

Mutualise CAA image loadings #519

Open jesus2099 opened 4 years ago

jesus2099 commented 4 years ago

Now, the big pics are loading each one in Image objects, then, the small pics are loaded each one in other Image objects. But both big pics and small pics are actually loading the same /front-250 images for the same releases.

So I should make an image loader function that, once loaded, affect the image to big and small pics at the same time.

jesus2099 commented 4 years ago

I should see if that fixes @kellnerd issue too.

jesus2099 commented 3 years ago

The issue that this ticket would fix, occurs on artist pages, not inside release group pages. It appears that all big pictures are loaded first, then only then, all small pictures are displayed (reloaded?).

kellnerd commented 3 years ago

Unfortunately this does not fix my issue, the userscript still fails to load lots (ca. 40%) of the images for my example series (and other large series). And strangely there are still a few images that are only shown as either big pictures or small inline pictures, although this happens for less RGs than before (only about 3 cases instead of ca. 20(?) as before).

In the browser console I can see CORS errors for some requests to the index.json files (always the same RGs after a reload(?)) and 503 errors for index.json files and front-250 files for the missing images (random RGs after each reload). I guess there are just too many requests within a short time, sometimes even the Wikipedia extract fails to load.

jesus2099 commented 3 years ago

It's strange indeed.

In fact I did my fix and testing on my Raspberry Pi 3B running on Raspberry Pi OS / Raspbian 10 (32 bits). Neither Firefox 78.6.1esr (32 bits) nor Chromium 86.0.4240.197 (32 bits) suffer any issues, ever.

But now that you still report issues, I did test your collection on my old PC running on Debian 10 (64 bits). I only have Firefox 78.6.1esr (64 bits), here.

On this PC, somehow slower than RPi3B (but never crashing on big work), I apparently face similar issue as you!

But it's big pics and small pics for the same release group that fail at the same time. And for each pair, I get one CORS error message about "Same Origin" policy missing "Access-Control-Allow-Origin" prevents loading of them https://coverartarchive.org/release-group/<mbid>. But those CORS messages are red herring because it works on other RG and even on these RG, it depends on each request. Red herring: like on https://tickets.metabrainz.org/browse/CAA-122 where it was the 404 error page that missed CORS, here it's maybe a 503 error page or something like that, that misses CORS.

Is it because this PC is slower? Is it because CAA cannot handle 100 simultaneous calls for cover? If I would put some delay between each cover, it could take quite a while. :thinking: But maybe I will try that.

kellnerd commented 3 years ago

Well, the problem seems to have disappeared. During the last months I had the feeling that less and less images failed to load and now all 100 images are finally being loaded as big pictures and small inline pictures again 🎉

Since you have not changed the script since, I guess there must have been some improvements on the side of the CAA. Feel free to close this issue again 😃

jesus2099 commented 2 years ago

Nowadays, @kellnerd, don't you have many images not loaded, again?

jesus2099 commented 2 years ago

I understand why my last change, while I was hoping it would load same image for big pic and small pic, but it actually didn't. They do load balancing, so even if I want to load twice the same https://coverartarchive.org/release-group/a5e6e6cc-ebf4-39d2-8460-95736355f5ef/front-250 but then one of them was redirected (307 Temporary Redirect) to https://ia600904.us.archive.org/4/items/mbid-d69025d1-4f83-337a-8032-9c7e72e7cdf7/mbid-d69025d1-4f83-337a-8032-9c7e72e7cdf7-5420274836_thumb250.jpg and the other (307 Temporary Redirect) to different sub-domain/server https://ia800904.us.archive.org/4/items/mbid-d69025d1-4f83-337a-8032-9c7e72e7cdf7/mbid-d69025d1-4f83-337a-8032-9c7e72e7cdf7-5420274836_thumb250.jpg

jesus2099 commented 2 years ago

The new CORS I see are like last time, it's because the error pages (404, 429, etc.) are not in their CORS setup.

kellnerd commented 2 years ago

Yes, currently it's as bad as it had never been before. Out of 100 images only about 10 to 20 of them are loading for me (on average) 😢 I guess the biggest part of this problem can only be fixed on the CAA's side, but their bad performance might give you a better chance to test what's still sub-optimal on your script's side at least 😏

jesus2099 commented 2 years ago

I can see the final URL with this.responseURL but cannot do anything about the 307, 429, etc. Even in readystatechange I don't see redirects 307 and fails 429.

jesus2099 commented 7 months ago

I have tested carefully with throttling as slow 3G and no cache. I saw that, despite the redirects (307), each images was loaded only once for both small and big pics.

Sorry I forgot, or never asked in this ticket, @kellnerd, what is your browser and OS? Do you still experience this bug?

kellnerd commented 7 months ago

I think I haven't had these issues in a while, currently all covers are loading for me 🤷