Trouble with DCMQR on a batch list of Unique StudyUID's

[Jason Collins]

OS: Windows 7-64

Two different versions of DCM4CHE (the most recent, downloaded last week and an older version?)

 

I am running a list of StudyUID's through the same command.  Copying the list from excel and pasting in to CMD prompt like below:

 

dcmqr STENT...@192.168.111.20:107 -qStudyInstanceUID=1.2.124.113532.1.1.192.168.8.11.20081019152706.953.3 -dest CP_PACS (older version)

dcmqr STENT...@192.168.111.20:107 -qStudyInstanceUID=1.2.124.113532.1.1.192.168.8.11.20081019152706.953.3 -cmove CP_PACS (newer version)

 

Bascially, just trying to find a Study by StudyUID in source PACS then move it to a different PACS.  This command has worked fine for me in the past.  But, on this list, many [but not all] studies seem to get 'hung.' By hung, I mean that they start displaying the following output and do not stop until I kill the script manually:

 

13:53:52,955 INFO   - STENTOR_QRP(1) >> 2:C-MOVE-RSP[pcid=7, remaining=1, completed=0, failed=0, warning=0, status=ff00H]
13:53:57,975 INFO   - STENTOR_QRP(1) >> 2:C-MOVE-RSP[pcid=7, remaining=1, completed=0, failed=0, warning=0, status=ff00H]
13:54:02,992 INFO   - STENTOR_QRP(1) >> 2:C-MOVE-RSP[pcid=7, remaining=1, completed=0, failed=0, warning=0, status=ff00H]

 

Any ideas?

[mmess...@gmail.com]

Not an idea. Just a vague guess. Perhaps there is a configuration difference between the two versions?

A couple questions:

If you try twice, is it the same set of studies that hang each time? Or does a study that hangs one time succeed on a subsequent try?

Can you get better diagnostics by turning up the log to debug level?

[Damien Evans]

The Stentor SCP looks like it is trying to move the studies.  I see it responding to you with pending messages.  Are there any problems with these studies on the Stentor server?  Are there any problems with the destination SCP (CP_PACS )?

 -- Damien

--
You received this message because you are subscribed to the Google Groups "dcm4che" group.
To post to this group, send email to dcm...@googlegroups.com.
To unsubscribe from this group, send email to dcm4che+u...@googlegroups.com.
Visit this group at http://groups.google.com/group/dcm4che?hl=en.
 
 

[JayByrd721]

Thanks mmesser,

 

I have no logging set up yet.  Working on that now with basic DOS batch script commands.  I haven't been able to isolate specific studies, retries, etc... yet.  But, that's what I will work on now.

[JayByrd721]

Thanks Damien,

 

I suspect issues with specific studies.  I've never had this issue before.  Plus, these are studies that failed (or slipped by) an initial proprietary migration.  Just trying to clean them up with a more standard DICOM migration now.  Will move on to better logging and trying to weed out the problem study(ies).

[JayByrd721]

After finding a way to log the list of commands that I was running, I was able to locate the specific studies that kept hanging this way.

 

After investigating those studies, I found that the source PACS had a 'record' of the study existing at one time, but no image files were available anymore.  So, the source PACS just kept retrying to send the study to the destination.  I'm assuming the destination was replying that it did not receive any images; hence the conitnuous retry.

 

I'll check with the PACS support team to see why those stale records exist in the source PACS.  But, I'm still wondering if there is some sort of retry max switch that dcmqr could use for this type of scenario?

[Damien Evans]

dcmqr is really at the mercy of the source PACS.  In this C-MOVE scenario, dcmqr sends one C-MOVE request to the PACS, and waits for a response.  The PACS repeatedly sends "pending" responses to dcmqr, which keeps it hanging on.  The failsafe needs to be on the PACS side in this case.

--

[Jason Collins]

That makes sense.  Thanks for the education and all of the great tools.