[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.
[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.
[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
[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
[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.