Closed Panaphobe closed 4 years ago
Tried using dezoomify-rs and it works fine using that. So it's probably not any sort of rate-limiting, and it's something unique to the web tool.
Hello, I just tried this URL, and it works fine for me. I'm going to close this issue, but you can still comment below, and if you find a way to consistently reproduce the issue, I'll reopen it.
Tried using the version at https://ophir.alwaysdata.net/dezoomify/dezoomify.html, the current Chrome extension (0.4.3), and the current version on Github (54073d9, updated Oct 5 2020).
Seems to have the same problem on all deepzoom images hosted on portafontium.eu
A representative example of a collection with many deepzooms that all have the same problem is located at http://www.portafontium.eu/census/soap-kt/1880/klatovy-prazske-predmesti-klatovy A direct link to a particular deepzoom that fails in this way is http://www.portafontium.eu/fcgi-bin/iipsrv.fcgi?DeepZoom=census/soap-kt/census-1880-okres-klatovy/klatovy-prazske-predmesti/cp001/soap-kt_01159_census-1880-klatovy-prazske-predmesti-cp001_0010.jp2.dzi
The dezoomifier will successfully identify the correct type of deepzoom and launches, but the progress bar will be stuck at "Preparing tiles load... (0%)".
Viewing the dezooming attempt in progress through Chrome dev tools' Network tab shows the various images being requested in rapid succession, and sit (pending) for some time before each eventually times out.
My only guess as the the cause is it's possible that the server won't respond to too many requests from the same source in such rapid succession - is it possible to space out the image requests?