movescu only returns 1st image, then hangs

[Tullhead]

Query with findscu works fine. Then

The file 'Query.ret' is created with dump2dcm from this ascii file:

(0008,0050) SH []
(0020,000d) UI [1.2.392.200046.100.2.1.50175.23230.20101228192642]


Call to movescu is this:

movescu -v -d -S -aec MetronSQL_AE -aet METRON_AE2 +P 4002 -k "0008,0052=STUDY" ip.ip.ip.ip 4006 C:/Epona/QR/Query.ret

One image is retrieved, but them movescu does not finish or complete even if there is only one image in the requested study. Behaviour is the same if there are 2 or more images: returns one image then gets stuck.

The PACs I am querying is a ClearCanvas system.

I suppose I am doing something wrong -- this is my first attempt at doing Q/R with the DCMTK binaries.

Here is transcript from -v and -d mode:

Request Parameters:
Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.5.4
Our Implementation Version Name: OFFIS_DCMTK_354
Their Implementation Class UID:
Their Implementation Version Name:
Application Context Name: 1.2.840.10008.3.1.1.1
Calling Application Name: METRON_AE2
Called Application Name: MetronSQL_AE
Responding Application Name: resp AP Title
Our Max PDU Receive Size: 16384
Their Max PDU Receive Size: 0
Presentation Contexts:
Context ID: 1 (Proposed)
Abstract Syntax: =FINDStudyRootQueryRetrieveInformationModel
Proposed SCP/SCU Role: Default
Accepted SCP/SCU Role: Default
Proposed Transfer Syntax(es):
=LittleEndianExplicit
=BigEndianExplicit
=LittleEndianImplicit
Context ID: 3 (Proposed)
Abstract Syntax: =MOVEStudyRootQueryRetrieveInformationModel
Proposed SCP/SCU Role: Default
Accepted SCP/SCU Role: Default
Proposed Transfer Syntax(es):
=LittleEndianExplicit
=BigEndianExplicit
=LittleEndianImplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation: none
Requesting Association
Constructing Associate RQ PDU
PDU Type: Associate Accept, PDU Length: 207 + 6 bytes PDU header
02 00 00 00 00 cf 00 01 00 00 4d 65 74 72 6f 6e
53 51 4c 5f 41 45 20 20 20 20 4d 45 54 52 4f 4e
5f 41 45 32 20 20 20 20 20 20 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 10 00 00 15 31 2e
32 2e 38 34 30 2e 31 30 30 30 38 2e 33 2e 31 2e
31 2e 31 21 00 00 1b 01 00 00 00 40 00 00 13 31
2e 32 2e 38 34 30 2e 31 30 30 30 38 2e 31 2e 32
2e 31 21 00 00 1b 03 00 00 00 40 00 00 13 31 2e
32 2e 38 34 30 2e 31 30 30 30 38 2e 31 2e 32 2e
31 50 00 00 30 51 00 00 04 00 01 c8 3a 52 00 00
17 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 32 35 34
30 33 2e 31 2e 31 2e 31 55 00 00 09 44 69 63 6f
6d 20 30 2e 31
Association Parameters Negotiated:
Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.5.4
Our Implementation Version Name: OFFIS_DCMTK_354
Their Implementation Class UID: 1.3.6.1.4.1.25403.1.1.1
Their Implementation Version Name: Dicom 0.1
Application Context Name: 1.2.840.10008.3.1.1.1
Calling Application Name: METRON_AE2
Called Application Name: MetronSQL_AE
Responding Application Name: MetronSQL_AE
Our Max PDU Receive Size: 16384
Their Max PDU Receive Size: 116794
Presentation Contexts:
Context ID: 1 (Accepted)
Abstract Syntax: =FINDStudyRootQueryRetrieveInformationModel
Proposed SCP/SCU Role: Default
Accepted SCP/SCU Role: Default
Accepted Transfer Syntax: =LittleEndianExplicit
Context ID: 3 (Accepted)
Abstract Syntax: =MOVEStudyRootQueryRetrieveInformationModel
Proposed SCP/SCU Role: Default
Accepted SCP/SCU Role: Default
Accepted Transfer Syntax: =LittleEndianExplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation: none
Association Accepted (Max Send PDV: 116782)
================================
Sending query file: C:/Epona/QR/Query.ret
Move SCU RQ: MsgID 1
Request:

# Dicom-Data-Set
# Used TransferSyntax: LittleEndianExplicit
(0008,0050) SH (no value available) # 0, 0 AccessionNumber
(0008,0052) CS [STUDY] # 6, 1 QueryRetrieveLevel
(0020,000d) UI [1.2.392.200046.100.2.1.50175.23230.20101228192642] # 50, 1 StudyInstanceUID

DIMSE Command To Send:

# Dicom-Data-Set
# Used TransferSyntax: UnknownTransferSyntax
(0000,0000) UL 0 # 4, 1 CommandGroupLength
(0000,0002) UI =MOVEStudyRootQueryRetrieveInformationModel # 28, 1 AffectedSOPClassUID
(0000,0100) US 33 # 2, 1 CommandField
(0000,0110) US 1 # 2, 1 MessageID
(0000,0600) AE [METRON_AE2] # 10, 1 MoveDestination
(0000,0700) US 0 # 2, 1 Priority
(0000,0800) US 1 # 2, 1 DataSetType

DIMSE sendDcmDataset: sending 106 bytes
DIMSE sendDcmDataset: sending 80 bytes
PDU Type: Associate Request, PDU Length: 226 + 6 bytes PDU header
01 00 00 00 00 e2 00 01 00 00 4d 45 54 52 4f 4e
5f 41 45 32 20 20 20 20 20 20 4d 65 74 72 6f 6e
53 51 4c 5f 41 45 20 20 20 20 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 10 00 00 15 31 2e
32 2e 38 34 30 2e 31 30 30 30 38 2e 33 2e 31 2e
31 2e 31 20 00 00 4d 01 00 00 00 30 00 00 19 31
2e 32 2e 38 34 30 2e 31 30 30 30 38 2e 35 2e 31
2e 34 2e 31 2e 31 2e 31 40 00 00 13 31 2e 32 2e
38 34 30 2e 31 30 30 30 38 2e 31 2e 32 2e 31 40
00 00 11 31 2e 32 2e 38 34 30 2e 31 30 30 30 38
2e 31 2e 32 50 00 00 30 51 00 00 04 00 01 c8 3a
52 00 00 17 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e
32 35 34 30 33 2e 31 2e 31 2e 31 55 00 00 09 44
69 63 6f 6d 20 30 2e 31
Constructing Associate AC PDU
DIMSE receiveCommand
DIMSE receiveCommand: 1 pdv's (150 bytes), presID=1
DIMSE Command Received:

# Dicom-Data-Set
# Used TransferSyntax: LittleEndianImplicit
(0000,0002) UI =ComputedRadiographyImageStorage # 26, 1 AffectedSOPClassUID
(0000,0100) US 1 # 2, 1 CommandField
(0000,0110) US 1 # 2, 1 MessageID
(0000,0700) US 0 # 2, 1 Priority
(0000,0800) US 514 # 2, 1 DataSetType
(0000,1000) UI [1.2.392.200046.100.2.1.50175.23230.20101228192642.1.1.1] # 56,1 AffectedSOPInstanceUID

Received C-Store RQ: MsgID: 1
AffectedSOPClassUID: =ComputedRadiographyImageStorage
AffectedSOPInstanceUID: 1.2.392.200046.100.2.1.50175.23230.20101228192642.1.1.1
Priority: 0
Data Set: Present

RECV:DIMSE receiveFileData: 16222 bytes read (last: NO)
.DIMSE receiveFileData: 16378 bytes read (last: NO)
.DIMSE receiveFileData: 16378 bytes read (last: NO)
.DIMSE receiveFileData: 16378 bytes read (last: NO)
.
. (skip a bit here(
.
.DIMSE receiveFileData: 16378 bytes read (last: NO)
.DIMSE receiveFileData: 16378 bytes read (last: NO)
.DIMSE receiveFileData: 8814 bytes read (last: YES)
.
DIMSE Command To Send:

# Dicom-Data-Set
# Used TransferSyntax: UnknownTransferSyntax
(0000,0000) UL 0 # 4, 1 CommandGroupLength
(0000,0002) UI =ComputedRadiographyImageStorage # 26, 1 AffectedSOPClassUID
(0000,0100) US 32769 # 2, 1 CommandField
(0000,0120) US 1 # 2, 1 MessageIDBeingRespondedTo
(0000,0800) US 257 # 2, 1 DataSetType
(0000,0900) US 0 # 2, 1 Status
(0000,1000) UI [1.2.392.200046.100.2.1.50175.23230.20101228192642.1.1.1] # 56,1 AffectedSOPInstanceUID
DIMSE sendDcmDataset: sending 150 bytes
DIMSE receiveCommand


Here it has hung - movescu is still running (as seen in task manager)
--------------------------------------------------------------------------------

Thanks in advance if you can spot what I've done wrong.

[Tullhead]

Might it be a BUG in movescu in 3.5.4? Should I try binary from 3.6.0?

[omarelgazzar]

I guess the problem in the negotiated transfer syntax of the second file. MOVESCU will accept by default the explicit VR local byte order transfer syntax. If the DICOM files are stored as compressed TS on the PACS, the PACS (ClearCanvas) should be able to convert it to the accepted transfer syntax by MOVESCU before sending it. If it fails to convert the file, then this is most probably the cause of your problem.

[Tullhead]

Omarelgazzer -- Thank you for your post. If this is the problem, is there anything I can do to avoid it? Or, is it a problem of the PACs I am querying?

[omarelgazzar]

You could check the transfer syntax of the second file which is stored on the server. If it is different from the transfer syntax accepted by MOVESCU (explicit VR local byte order), then the PACS should convert it. If this conversion was not possible by the PACS, you could still get the file by prefering the proposed TS of the file to avoid this conversion.

[Tullhead]

I tried my code against an Eklin Pacs system (instead of the ClearCanvas Pacs I was testing against) -- and now my Q/R works perfectly! I have a theory that perhaps it is a timeout issue -- the Eklin Pacs happens to be faster (or faster network connetion to it) so it works, but if the sytsem or network is slower, it hangs. Possible? So, I tried experimenting with the -td option in movescu, but things then didn't work at all -- but I think I recall seeing a post that there is abug with the -td option in movescu in 3.5.4. So, I will be looking into that. Anyway, its some progress...

[Tullhead]

I tried using the -td option for movescu and with that option present movescu doesn't work at all. Even tried it in 3.6.0. Anyone know about this?