My files did not show up on the PURL as expected

After finishing accessioning, you may find that an object isn't being displayed the way you expected. This page lists some common issues, with possible ways to resolve them.

A purl was created, but it does not show the embed viewer to display the content

A purl with no content could mean one of two things:

1. The object was accessioned without any files
2. The object was accessioned with files but no files were "published" and "shelved"

You can tell if an object was accessioned without files by looking at the object in Argo. If the Contents section is empty, the object has no files. If there are files listed in the Contents but the listing only shows the word "preserve" next to the files, then the files were not published or shelved.

For situation #1 (no files in the object):

• Check the manifest.csv and the folder where the files were staged. Make sure that the folder listed in the manifest (this is under the column headed "object") is a) the correct folder and b) not empty. If the manifest points to an empty folder, accessioning will complete successfully but with no file attached (because the empty folder is treated as the content).
  • Note: there are situations where it's desirable to publish a Purl with no files, so accessioning an empty folder is allowable. The discovery report should give you an indication of whether an object will contain no files.
• If the manifest is correct and the folder is not empty, check the names of the files against the list of constraints on filenames in SDR. Certain punctuation characters, such as brackets [] lead Preassembly to skip those files. Either rename the files to not use those characters or contact the Repository Manager for help. In some cases, it will be possible to accession the files via back-end processes that skip Preassembly. More development work is required to expand SDR's support for characters in filenames.

For situation #2 (files are accessioned but not on the Purl):

The default behavior for Preassembly is to evaluate files according to mimetype (essentially, the file format type) in order to determine whether they should be "preserved" (stored only in the preservation system) or if they should be "published" (listed on the Purl) and "shelved" (copied to public-facing storage, known as "Stacks"). These defaults are very helpful for managing storage locations for common content types where the expectation is that one file, such as a TIFF, is for preservation, while a corresponding file in a different format, such as JPEG2000, is for display in the viewer.

But these defaults are not always appropriate for your content, and in some cases you will find that they result in all of your files being treated as "preservation-only" and thus not available from the Purl. In this situation, you will need to set the "preserve", "publish", and "shelve" settings to the specific values that you need.

You have two options for overriding the defaults, depending on the needs of your content:

• Option 1: you want all files to be accessible from the Purl.
  • Process: Re-run preassembly with all of the same settings, except: select the option "Preserve=Yes, Shelve=Yes, Publish=Yes". This will make all files in the object publicly available.
• Option 2: you want some files to be on the Purl and others only to be in preservation
  • This situation is more complicated, but possible. You will need to run Preassembly with a file manifest to provide these settings on a per-file basis.

I submitted a new version of an image but the viewer is still showing the old version to the public

When accessioning new versions of image or book content, you may find that it takes a long time for your files to be updated in the public display. If you find that:

• you've accessioned an image and then found you needed to modify it (rotate, re-crop, etc.)
• you've accessioned the modified image without seeing any errors
• the public display still shows the older version of the image even after you've refreshed the page in the browser
• but when you download the image file from within Argo you see that it's the correct, newer version of the image

then what you're seeing is likely to be the effect of image caching on the server itself. Eventually, this cache will be renewed with the new version of the file that you submitted, but for a period of days (or, unfortunately, possibly even weeks) the old version of the image will still be presented to the public. There is an open issue to address the problem, as it requires changes within the internal components of SDR.

But for the moment there is only one reliable way to make new versions of images appear in the viewer right away: re-name the modified files so that the images are treated as new, un-cached files. When re-naming a file within a multi-image object, make sure the new name does not change the order in which the filenames are sorted. In some cases it might be simpler to rename all files (for example, add an extra '0' to pad a numeric sequence) consistently than to rename only the changed file(s). If renaming files is not an option, you will unfortunately have to wait for the cache to refresh on its own.

The image viewer shows a black screen and an error message like "JSON parse error"

Generally, this issue occurs if the image viewer is attempting to display non-image content, or image content that does not have the expected image file format (JP2, aka JPEG2000). This error can occur if a druid is given the content type of "image" or "book" but the files in the druid are not image files. A druid that contains only a PDF copy of a book should be given the "document" content type, for example.

Possible solutions:

• if the druid is not displaying properly and it does not contain image files
  • use Argo to change the content type/resource type to "document"/"document" (if it only contains PDF) or "file"/"file" (if it contains a combination of file format types)
• if the druid should contain image content (i.e. the submitted files are common image formats like JPG, TIFF, etc.) but no JP2 files were created for the viewer
• please check your Preassembly settings and try again. You must choose "image" or "book" in Preassembly to have the JP2 copies created properly. If you still experience problems, please contact the Repository Manager or ask for help on the #dlss-aaas Slack channel.

My image is rotated incorrectly in the viewer but it looks right on my computer

[Note: as of 2023, we believe this issue has been fixed for newly deposited content but remediation may be necessary for older content.]

Some images have their orientation set using image metadata, rather than by rotating the image by changing the arrangement of the underlying pixels themselves. Many, if not all, image viewer applications read this image rotation flag correctly, with the result being that the image appears on your screen in the correct orientation.

Unfortunately, the SDR accessioning process does not currently apply this rotation flag when creating the copies of the image files that appear in the image viewer. (An issue has been filed to fix this.) If your images are not rotated correctly in the viewer, it is likely that their rotation is set via a metadata flag.

To resolve this issue, you will need to:

• Rotate the files on your own computer using an option that rotates the image content itself, rather than just setting the metadata flag
• Accession the object again with the modified files

Note: when accessioning the rotated images, please be aware that the images in the public display may not be updated immediately. This is the result of image caching (this issue is addressed in the section below). If you have the option of renaming the rotated files, it is best to do so. This will ensure that the public display is updated immediately.