Bug 128

Summary:	C-MOVE - invalid number of remaining sub-operations
Product:	Orthanc	Reporter:	Sébastien Jodogne <s.jodogne>
Component:	Orthanc Core	Assignee:	Sébastien Jodogne <s.jodogne>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	---
Version:	unspecified
Hardware:	All
OS:	All

Description Sébastien Jodogne 2020-06-29 15:15:08 CEST

[BitBucket user: Didier Lesage]
[BitBucket date: 2019-01-22.12:33:06]

Since 1.4, Orthanc is sending invalid status when managing a c-move operation.

The problem is identified as follow, in Core/DicomNetworking/Internals/MoveScp.cpp ...

data.subOperationCount_ = data.iterator_->GetSubOperationCount();

GetSubOperationCount() returns 1, when initializing the number of sub operations (files to send), even if multiple files are to be send. So, when the MoveScpCallback function is called after the first c-store operation is done, a "success" status is send to caller instead of a "pending" status.

When receiving this status, our caller close the association ... 

Thanks.

Comment 1 Sébastien Jodogne 2020-06-29 15:24:04 CEST

[BitBucket user: Sébastien Jodogne]
[BitBucket date: 2019-01-23.07:31:55]

Hello, have you tried setting the option `SynchronousCMove` to `true` in the [Orthanc configuration](https://hg.orthanc-server.com/orthanc/file/default/Resources/Configuration.json)? This should revert to the default behavior of Orthanc < 1.4.0.

Comment 2 Sébastien Jodogne 2020-06-29 15:24:05 CEST

[BitBucket user: Didier Lesage]
[BitBucket date: 2019-01-23.08:06:20]

Hello Sébastien,

Sorry but I didn't know this options. Effectively, setting **SynchronousCMove** to **true** makes our DICOM caller feeling better (so this issue is no more a *bug*), receiving a final status code at the end of the c-store sub-operations processing.

But I don't really understand the value of this option ... no more signification for "sub operations" ? When/how can we get the real status of the c-move request ?

But anyway, thank you for your prompt answer and your help.

Didier

Comment 3 Sébastien Jodogne 2020-06-29 15:24:06 CEST

[BitBucket user: Sébastien Jodogne]
[BitBucket date: 2019-01-23.08:33:08]

Fix issue #128 (Asynchronous C-MOVE: invalid number of remaining sub-operations)

→ https://hg.orthanc-server.com/orthanc/changeset/8a9eb767280c

Comment 4 Sébastien Jodogne 2020-06-29 15:24:07 CEST

[BitBucket user: Sébastien Jodogne]
[BitBucket date: 2019-01-23.08:51:21]

I have just published a changeset that provides the same number of "sub-operations" in both synchronous and asynchronous C-MOVE modes. This change will be part of forthcoming Orthanc 1.5.3, and was indeed necessary for consistency between the two C-MOVE modes.

Note that `SynchronousCMove` is back to `true` by default on Orthanc >= 1.5.0, so you should consider updating, as you are visibly using Orthanc 1.4.0, 1.4.1 or 1.4.2, or a configuration file inherited from those versions that sets `SynchronousCMove` to a non-default value.

Regarding the question "how can we get the real status of the c-move request", you simply cannot do this with plain C-MOVE, as the sending might be delayed from the request depending on the PACS configuration (as can be seen if `SynchronousCMove` is `false`). What you need is [DICOM Storage Commitment](http://www.otpedia.com/entryDetails.cfm?id=150), or to implement the check manually by yourself using C-FIND/REST API. DICOM Storage Commitment is [part of our roadmap](https://hg.orthanc-server.com/orthanc/file/default/TODO), but we try and gather funding from the industry to implement it: Let us know if you can help.