When each DICOM instance arrives, I use a simple lua script to modify the instance, using the recommended REST interface.
Because I am preserving the (study/series/SOP) instance UIDs, I need to delete the existing instance before Orthanc allows me to save it. If I do not delete the original instance, my changes are discarded, as orthanc believes it is an identical copy of the existing file.
When I delete the original instance file and immediately provide the replacement, it appears to be successful. However, when I try to query the file later, I see the above error.
Is it a bad idea to be modifying/deleting an instance from the OnStoreInstance hook? If so, is there an alternative?
Thanks.
Nick.
Hi Nick,
You could use the “OverwriteInstances” option to avoid deleting before uploading again.
Note that the “Unable to read attachment dicom” error should really never happen. We only observe this kind of error in case of a corrupted file system, wrong permissions, disk full (for write error obviously), …
Best regards,
Alain
Alain, thanks for suggesting that configuration setting. Unfortunately, that has not helped solve the problem. I have tried to replicate the problem in a simple docker compose setup which I could share with you or others, but have not yet been successful.
When I enable OverwriteInstances and simplify the lua script to not delete the images, I can confirm the new versions of the instances are being saved, when using the verbose logging. However, at least when using private dicom tags, I still get the original internal error. I will follow up in the next day or two when I have a reproducible package for others to verify the problem with.
Note that I am highly confident that there are resource issues, disk or otherwise. It occurs inside fresh docker containers with have no mounted volumes, etc.
Regards,
Nick.