Troubleshooting Failed DICOM retrieves

Hi all –

I have an Orthanc installation that is communicating fluently with the hospital PACS. I have been primarily working with CT and MR, and Orthanc has no problem retrieving volumetric data.

I recently began querying against CR (radiography) and, while Orthanc properly returns “find” information about these studies, when I try to retrieve them, the PACS opens a connection very briefly, and then immediately requests a disassociation. It seems to fail for about 50% of the studies.

I can see these images fine on the regular hospital PACS and the tags don’t have anything too suspicious in them. I turned on “AcceptUnknownSOPClasses” and turned off “LoadDictionary” in the Orthanc config to be safe, but it didn’t make a difference. I also tried scaling up and down the number of threads/jobs and turned on “SynchronousCMOVE” with no effect.

I already have verbose logging on, but Orthanc doesn’t tell me anything about the failed negotiation between itself and the PACS for these images. Any advice on trouble-shooting this?


Our PACS admin admitted that “there was something fishy” about the files I was unable to load. He said that on an older system, he also couldn’t receive them, but on a newer system he could. So I recompiled Orthanc against DCMTK 3.6.4 and it works now. That doesn’t explain what was going wrong, but it maybe a useful bit of troubleshooting advice for someone else.

Now back to downloading 2 million x-rays for an AI project. At 20 per minute, I’ll just have to check back in about 70 days…


Thanks for sharing this interesting information!

Here is our roadmap wrt. DCMTK 3.6.4:

  • As you noticed, it is already possible to dynamically link Orthanc 1.5.3 against DCMTK 3.6.4. But the LSB/Docker/Windows binaries still embed DCMTK 3.6.2.
  • Orthanc 1.5.4 will be released in the next few hours/days, and will behave like Orthanc 1.5.3 as far as DCMTK 3.6.4 is concerned (dynamic linking only).
  • Orthanc 1.5.5 will provide support to statically link against DCMTK 3.6.4, and the LSB/Docker/Windows binaries will embed DCMTK 3.6.4.


Dear Derek,

Just a thought: Would it be possible for you to share an image (possibly anonymized) that is problematic with DCMTK 3.6.2, but that works fine with DCMTK 3.6.4?

This would help us in our quality assurance process. TIA!