-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MS 0073 gives errors #922
Comments
ah, yeah that's an IA issue- they're super slow. You can refresh and sometimes get some images in, otherwise it just keeps processing ad infinitem; check in in ~an hour and it might move. I went down a rabbit hole on this, and it's semi-related to 1) IA's image servers and 2) who they use, namely Cantaloupe, which results in odd loading behaviors (particularly for some bizarre tile behavior). If you need ms73 images for casual persual/consultation, I have all them in a drive file. They're going to be up on e2e-omr-resources as well (~next Wednesday). |
I have them too! (or at least, I have all the ones I need right now immediately available, and the others...somewhere.) |
I just went and looked at some of my talks with some of the folks at IA and on the cantaloupe page; IA finished its IIIF switch to v3 and changed all of their URLs. They have a service to point to the new ones, but that might be slowing things down- we currently have the old URL (iiif.archivelab.org) when their new base domain is EDIT: I do also agree about looking into us hosting, or at least having some kind of backup- as the recent cyberattacks on IA have shown it might be helpful to have something to kick in if IA times out or is unresponsive... |
I just changed the iiif link for MS 0073 to this: https://iiif.archive.org/iiif/McGillLibrary-rbsc_ms-medieval-073-18802/manifest.json but I'm still getting the gateway timeout. I can't even seem to access individual images from the manifest :( |
So, it looks like they're out of memory: |
Since these are McGill images, could we not work with the library to serve them from somewhere more...consistent? CU already has a built in IIIF server. |
that's certainly a possibility. would this be like Salzinnes before we had the Alamire's/IDEM pictures? |
On a different server I think, because iirc the old Salzinnes images are hosted on the Liber server (come to think of it, it might behoove us to move those images to a more up to date server too). But yes, with essentially the same effect. @fujinaga Would this be ok? |
On the other hand, does the McGill library not have a procedure? Or is IA their go to? |
@dchiller IA is their go to; they also have images up on Hathitrust, which is a useful secondary link but afaik not IIIF. Based on my conversations about putting the fragments on Fragmentarium, the library seems happy to have other copies hosted elsewhere and does not seem to have strong feelings about a specific procedure for this (or else I've been talking to the wrong people.) |
Yes, it's fine as a temporary (next 5 years) solution. |
We could host them on the DIAMM IIIF server too. We have a dedicated domain (iiif.diamm.net) that is just a IIIF manifest and image server. I would just need a manifest and the pre-processed files. |
@ahankinson What image server does the DIAMM one use? I'm agnostic as to where we serve these. DDMAL is already serving images used by Cantus Ultimus, so it would be easy enough to add MS 0073. It does seem, though, like a good opportunity to centralize where we are hosting DDMAL-hosted images (old Salzinnes images, MS 073, Gottschalk images) wherever we decide to put them. |
DIAMM uses IIP, if that's what you meant? The images will have to be preprocessed (pyramid tiff or tiled JPEG2k) and the manifest already made. |
Yes! Thanks. |
This might really be an Internet Archive problem, but I tend to get an error when looking at MS 0073 on Cantus Ultimus:
This is where the image links from CantusDB go, so I encounter it pretty often...
The text was updated successfully, but these errors were encountered: