I am seeing the same issue described here. However it is occurring due to network congestion rather than just a slow link and it doesn't always happen after 1 image is sent (I've seen stalls happen after 400+ images have been recieved).  With a 100Mbit connection I see the stalls when 100-200 studies are being recieved at once. 

The fact that the stalls occur is not the issue. What concerns me is that there is no error message in the 'Recieve Activity Monitor' and after the 'last active time' reaches 2 hours they are cleared from the queue as if they finished the transfer successfully. The only way a user can know that a transfer completed successfully is to compare the number of instances they recieved against the number of instances on the server.

Hi, a lot of DICOM SCPs will limit the number of concurrent associations to 25 or so because it's not really reasonable to receive 200 studies at once. The workstation was not designed for this, and in fact I've always intended to add something in to reject incoming associations if there's too much going on.

You can increase the purge time to whatever you want - there is a setting in the ShredHostService.exe.config file.

Hope this helps,
Stewart

I agree that this is not a standard use case. However there are a number of reasons why there could be network congestion (including completely unrelated applications). It just seems that it should display an error message to the user when the connection times out rather than failing silently.

Could somebody move this thread to bug reports? After some more testing I have seen these timeouts occur with as little as 10 simultaneous transfers.

It doesn't show anything in the Receive Queue?

I need a clarification before I enter a ticket: is this a *Retrieve* (e.g. initiated by the workstation) or a *Receive* (e.g. an auto-route), or both? In the latter case, there is nothing that can be done because the store was initiated elsewhere and the workstation has no knowledge of success or failure. This is a limitation of DICOM.

In the former case, the SCP storing the images is supposed to send a failure status back to the MOVE-SCU (the workstation), the results of which are shown in the Receive Queue, at least the last time I checked. Again, it's up to the SCP storing the images to send the failure status. If the MOVE-SCU times out on the workstation, then any retrieve status is lost and cannot be recovered, but I was pretty sure this timeout situation also appears in the Receive Queue.

Anyway, please let me know which of these situations matches the conditions under which you see the problem.

Also, is your PACS a CC ImageServer?

Thanks,
Stewart

The PACS is CC ImageServer. I am doing a retrieve with CC Workstation. The more studies I retrieve at once the more likely the timeout occurs (as mentioned above I have seen it happen occasionally with as few as 10 simultaneous transfers). No error message is displayed in the receive activity monitor and the 'Failed' count remains at zero. When the last active time reaches the purge time the study is cleared from the queue as if it finished successfully.

Hi, ok, that's pretty troubling.  I've entered this ticket and I've set it to a high priority.  Have you tried changing the Read and Write timeout in the app.config (DicomNetworkSettings) in the ShredHostService.exe.config?  Theoretically, if you set those to be really big, it *could* fix the problem.

Thanks,

Stewart

I will try increasing the timeouts as a work around and report back if I see it happen again.

Hi, just following up on this. Did increasing the read and write timeouts on both the client and the server fix the problem?

Thanks,
Stewart