storescu problem

[ilan...@gmail.com]

I am trying to send a file with 0002 group as follows
0002,0002 Media Storage SOP Class UID: 1.2.840.10008.5.1.4.1.1.4
0002,0003 Media Storage SOP Inst UID: 1.3.12.2.1107.5.2.36.62009.2014032614155670206958671
0002,0010 Transfer Syntax UID: 1.2.840.10008.1.2.1
0002,0012 Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.1
0002,0013 Implementation Version Name: OFFIS_DCMTK_361
0002,0016 Source Application Entity Title: ORSSCP
0008,0008 Image Type: DERIVED\PRIMARY\M\ND\NORM
0008,0012 Instance Creation Date: 20140326
0008,0013 Instance Creation Time: 141557.179000

It fails and the following appears on the Console

Scanning files to send
.
Scanned 1 files in 0.001s (=1ms/file)
Initiate connection from 0.0.0.0/0.0.0.0:0 to salouma2.dyndns.tv:4242
Established connection Socket[addr=salouma2.dyndns.tv/90.76.250.185,port=4242,localport=33249]
STORESCU->ORTHANC(160) << A-ASSOCIATE-RQ
STORESCU->ORTHANC(160) >> A-ASSOCIATE-AC
Connected to ORTHANC in 185ms
STORESCU->ORTHANC(160) << 1:C-STORE-RQ[pcid=5, prior=0
cuid=1.2.840.10008.5.1.4.1.1.4 - MR Image Storage
iuid=1.3.12.2.1107.5.2.36.62009.2014032614155670206958671 - ?
tsuid=1.2.840.10008.1.2.1 - Explicit VR Little Endian
STORESCU->ORTHANC(160) >> 1:C-STORE-RSP[pcid=5, status=a900H
cuid=1.2.840.10008.5.1.4.1.1.4 - MR Image Storage
iuid=1.3.12.2.1107.5.2.36.62009.2014032614155670206958671 - ?
tsuid=1.2.840.10008.1.2.1 - Explicit VR Little Endian
E"ERROR: Received C-STORE-RSP with Status A900H for /home/ilan/JJWTTI00_dcm/1.2.276.0.7230010.3.1.4.3244495638.5236.1400824554.612.dcm"
(0000,0002) UI [1.2.840.10008.5.1.4.1.1.4] AffectedSOPClassUID
(0000,0100) US [32769] CommandField
(0000,0120) US [1] MessageIDBeingRespondedTo
(0000,0800) US [257] CommandDataSetType
(0000,0900) US [43264] Status
(0000,1000) UI [1.3.12.2.1107.5.2.36.62009.2014032614155670206958671] Affected

STORESCU->ORTHANC(160) << A-RELEASE-RQ
STORESCU->ORTHANC(160) >> A-RELEASE-RP
STORESCU->ORTHANC(160): close Socket[addr=salouma2.dyndns.tv/90.76.250.185,port=4242,localport=33249]
Sent 0 objects (=0MB) in 0.403s (=0MB/s)

There is no group 0000 in the file.
Can someone give me a hint what is objectionable here?

Thanks,
Ilan

[Sébastien Jodogne]

Hello,

Please post a sample problematic DICOM file so that the community can provide some help.

Regards,

Sébastien-

[Ilan Tal]

With Bless editor I erased the name. Still, please delete after use.

[Sébastien Jodogne]

Hello,

I encounter no problem sending your DICOM file from storescu (from DCMTK) to Orthanc 1.2.0, as depicted in the attached screenshot.

From the perspective of Orthanc, everything is OK.

Regards,

Sébastien-

[salim....@gmail.com]

I have duplicated Ilan's error.
We are both using DCM4CHE storescu package to send dicom.

I thought about a DCM4CHE bug but the problem is that sending to Conquest server is OK and Orthanc is failing (with the same DCM4CHE storescu and the same dicom file of course)

Best regards,

Salim

[Sébastien Jodogne]

OK. I have found the issue.

The problem is that your DICOM file is invalid. David Clunie's dciodvfy tool reports that the tags "MediaStorageSOPInstanceUID" and "SOPInstanceUID" are not equal, but they should have the same value. If I manually fix the file, everything goes fine, including with dcm4che's storescu.

You will find all my findings in the attached screenshot.

Regards,

Sébastien-

[Ilan Tal]

Thanks Sebastien,

I suspected the file may be faulty.

We do have a work around available.

I have a "myDicom" available. The default is to send the file with no changes, but if I change something (series name, number) a new SOPInstanceUID is generated.

In such a case, it is inserted in group 2 and group 8, and of course the same value is used in both groups.

This is essentially the same as your fix.

[Ilan Tal]

Dear Sebastien,

I jumped too soon with myDicom work around. It is true and not true.

The problem, on my system at least, is that the bad file will knock over your orthanc server.

Any further sendscu activity whether the subsequent is good or bad will be rejected.

Even worse the attempt may also knock over Fiji itself.

To fix the problem the user absolutely must restart the orthanc server.

This is probably a bit much for the average user.

If 0002,0003 must be equal to 0008,0018, it means that we have superfluous information.

Since group 0002 need not even be supplied, one solution could be to ignore 0002,0003.

Another possibility is to update 0002,0003 whenever 0008,0018 arrives.

I don't know who made that file. It has a Siemens tag in it, but that doesn't mean Siemens made it.

In any case it means the possibility of bad files is a fact of life.

It might well be in your interest to guard your orthanc server against such bad files, and keep it rock solid.

Now I need to tell you my situation, which is probably unusual.

I put a lot of effort into trying to make docker work and failed.

I rather guess that I have several versions of docker installed and they may be conflicting with one another.

I could reformat my whole Ubuntu partition, but that is a bit drastic.

If you could give me a simple script to purge all versions of docker along with whatever else might be in the mess, that would be much nicer.

(What I do know is the update to 17.04 changed my orthanc server from 1.1.0 to 1.2.0. That was nice.)

I don't know if Salim's orthanc server is knocked over or not.

In other words, how wide is the problem?

Finally a very small point. When I restart the orthanc server I purge orthanc_supervisor.log.

At 10MB in length, it was totally useless, so each time I am forced to restart the server I start again with an empty log.

Then it is again something I can look at.

Thanks for all your help,

Ilan

[salim....@gmail.com]

Dear Sebastien,

I'm importing a large dataset into orthanc (360 PET/CT).
The transfert goes well for almost all PET/CT except 2 patients.

I put in attachment a file that generate errors with storescu. This file comes from a commercial PACS for clinical studies, I can't exclude error in it but it "should" be ok.

When I upload it with the upload function of orthanc explorer it is OK but the storescu fails.

The error log is in attachement.

Best regards,

Salim

[Thibault Nélis]

On Wed, 2017-05-10 at 07:22 +0300, Ilan Tal wrote:
> I rather guess that I have several versions of docker installed and
> they may be conflicting with one another.
> I could reformat my whole Ubuntu partition, but that is a bit
> drastic.
> If you could give me a simple script to purge all versions of docker
> along with whatever else might be in the mess, that would be much
> nicer.

On Ubuntu:
- systemctl stop docker
- dpkg -l '*docker*' and remove all relevant packages (marked "ii" for
installed).
- rm -r /var/lib/docker. This will destroy all Docker images (safe),
named data volumes (if you use that and the data is important make a
backup), as well as containers, virtual networks and possibly other
things (safe). This really does wipe all Docker-related data.
- Reinstall Docker.

> (What I do know is the update to 17.04 changed my orthanc server from
> 1.1.0 to 1.2.0. That was nice.)

Actually I'm surprised this would happen. If you target the "latest"
tag on the Orthanc Docker image repository then you must have issued a
"docker pull" command or something that triggered it somehow. You can
target a specific version if you want to avoid this in the future.

> Finally a very small point. When I restart the orthanc server I purge
> orthanc_supervisor.log.
> At 10MB in length, it was totally useless, so each time I am forced
> to restart the server I start again with an empty log.
> Then it is again something I can look at.

It sounds like you are using the setup we (Osimis) previously
recommended for using Orthanc with Docker. Nowadays we don't recommend
the use of supervisor in this case, you might be interested in this
approach instead: https://bitbucket.org/snippets/osimis/eynLn.
--
Thibault Nélis <t...@osimis.io>
Osimis

[Sébastien Jodogne]

Dear Salim,

Sorry for the delay.

The DICOM file you sent is also broken. As can be seen from the attached screenshot, it contains a private tag "0029,1001" with an odd length, whereas the DICOM standard mandates an even length.

If I remove this ill-conditioned DICOM tag using "dcmodify", it makes the "storescu" command-line tool from dcm4che happy (as shown in the screenshot).

You should report this issue to your GE Medical Systems support team (for reference to ease search in this forum, the model of the modality is GE Discovery 710).

HTH,

Sébastien-