Replies: 5 comments 3 replies
-
I will answer my own question here: Fallback C-MOVE SCP works indeed, but in my setup only if the "C-STORE SCU of C-MOVE SCP" field is configured with the AE titles of the Remote Archive and Original Requester, respectively. The documentation should perhaps mention this, or offer some minimal working example. |
Beta Was this translation helpful? Give feedback.
-
Proxy retrieve requests to another Archive - Proxy Retrieve Config on archive1 - followed https://github.com/dcm4che/dcm4chee-arc-light/wiki/Proxy-retrieve-requests-to-another-Archive#configuration (replacing ![]() ![]() Verify no studies on archive 1 ![]() Study present on archive 2 ![]() Trigger C-MOVE request to archive 1 ![]() archive1 server.log
archive2 server.log
|
Beta Was this translation helpful? Give feedback.
-
Proxy retrieve requests to another Archive - Cache Retrieve Config on archive1 - followed https://github.com/dcm4che/dcm4chee-arc-light/wiki/Proxy-retrieve-requests-to-another-Archive#configuration-1 (replacing ![]() Verify no studies on archive 1 ![]() Study present on archive 2 ![]() Trigger C-MOVE request to archive 1 ![]() archive1 server.log
archive2 server.log
|
Beta Was this translation helpful? Give feedback.
-
Thank-you for your kind reply and for the snapshots, which make it easier to follow the setup. This is indeed the way I had it setup, but it never worked until I added "C-STORE SCU of C-MOVE SCP". In you example, I can see that you use DCM4CHEE as called AE title in the movescu request. But the message flow in the documentation states that this should be "QRSCP" instead (so, DCM4CHEE2 in your example). Am I misunderstanding something? |
Beta Was this translation helpful? Give feedback.
-
Thanks, it is perfectly clear explained that way. Then, wouldn't you agree that this part of the diagram is wrong, and the first ASSOCIATE-RQ should go to DCM4CHEE and not to QRSCP? ![]() |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe the bug
Fallback C-Move SCP (cache retrieve) is not working
To Reproduce
Setup a Fallback C-Move SCP System as described in the documentation and perform a Q/R request from any DICOM client
Expected behavior
If the requested DICOM object does not exist in the archive, DCM4 starts a fallback C-Move SCP request against an external system and retrieves the missing objects. This part works perfectly.
After the objects have been retrieved and stored into DCM4, the original request from the client should be fulfilled by having DCM4 perform C-Store operations. This never happens, and the log do not contain any errors or hints.
Additional context
Connectivity issues are ruled out; if the client sends the request a second time, after the DICOM objects have been retrieved from remote, then the C-MOVE is fulfilled immediately and successfully.
I am also perplexed by the poorly documented setting "C-STORE SCU of C-MOVE SCP"; must this be set in any special way for this function to work?
Thanks everybody for your valuable feedback!
Beta Was this translation helpful? Give feedback.
All reactions