Orthanc docker instance does not store all incoming data

Google Groups archive
1

Hi,
I am currently using two docker instances - one for main storage and second one for temporal storage and modifications. What bothers me is that when I send a whole Patient to the second instance some data is missing.

To be specific I send the data with REST command:

curl -X POST http://user:pass1978@192.168.201.1:8080/modalities/temp/store -d $patient_id

…

“InstancesCount” : 2859

I receive only ~1700 dicoms, which is 17 scans out of 27.

It works fine when I send the same data, from the same Orthanc server to eg. XNAT or Horos. All data is being stored correctly.

I’ve got two different images now and I attach configuration for the target container.

SOURCE Orthanc version: mainline (20190123T134658)

TARGET Orthanc version: mainline (20190626T062603)

Please let me know if there is something I can do with that.

B.

xnat-router.json (20.7 KB)

2

Hello,

If you expect help from this forum, please provide a minimal working example for other people to be able to independently reproduce your issue, as explained in the Orthanc Book:
https://book.orthanc-server.com/users/support.html#discussing-a-minimal-working-example

Sébastien-

3

Sure I would really appreciate Your help. It is kind of difficult to me to reproduce all the mentioned log files on our working PACS environment. Currently, I can interact only with the second instance.

Data - it seems that the type is irrelevant, it has to be 1800+ DICOMS in one specific Patient. Also I can send all the missing data one by one (eg. series).
Operation - DICOM Store of a single Patient (curl -X POST http://user:pass1978@192.168.201.1:8080/modalities/temp/store -d $patient_id)
Target - Orthanc docker instance (config in previous message)Logs - I can produce logs from targeted instance:

… 1802 repetitions of storing sequence which reflects number of stored scans (out of 2800)

I0918 08:33:51.486371 PluginsManager.cpp:172] New instance has been added to series 62374129-f7aceefc-03d47a89-ac39bb06-ddc1b462, invalidating it

I0918 08:33:51.486386 OrthancPlugins.cpp:1495] Plugin making REST GET call on URI /instances/bb60be3c-dfec5518-c2483d33-8ccf615f-2d328496 (built-in API)

I0918 08:33:51.566260 main.cpp:215] Incoming Store request from AET MV300_3110 on IP 172.17.0.1, calling AET XNAT-ROUTER

I0918 08:33:51.569761 FilesystemStorage.cpp:118] Creating attachment “2e08f8d5-4dd5-4dce-8f87-b744808ee2ff” of “DICOM” type (size: 1MB)

I0918 08:33:51.571550 FilesystemStorage.cpp:118] Creating attachment “c568f32a-c2db-4ebd-a35d-634f4e4dcae5” of “JSON summary of DICOM” type (size: 1MB)

I0918 08:33:51.572549 ServerContext.cpp:408] New instance stored

I0918 08:33:51.572599 PluginsManager.cpp:172] New instance has been added to series 62374129-f7aceefc-03d47a89-ac39bb06-ddc1b462, invalidating it

I0918 08:33:51.572654 OrthancPlugins.cpp:1495] Plugin making REST GET call on URI /instances/7a63688f-96ba07b5-605703b5-e879e460-9e1c47ba (built-in API)

I0918 08:33:51.652977 main.cpp:215] Incoming Store request from AET MV300_3110 on IP 172.17.0.1, calling AET XNAT-ROUTER

I0918 08:33:51.656769 FilesystemStorage.cpp:118] Creating attachment “dbeb2abc-0252-49f0-9988-51485a2cbbe2” of “DICOM” type (size: 1MB)

I0918 08:33:51.658572 FilesystemStorage.cpp:118] Creating attachment “04edd9b5-1625-4763-9427-f07bbd45c107” of “JSON summary of DICOM” type (size: 1MB)

I0918 08:33:51.659648 ServerContext.cpp:408] New instance stored

I0918 08:33:51.659822 PluginsManager.cpp:172] New instance has been added to series 62374129-f7aceefc-03d47a89-ac39bb06-ddc1b462, invalidating it

I0918 08:33:51.659872 OrthancPlugins.cpp:1495] Plugin making REST GET call on URI /instances/53b1fb60-1b1ac762-b05e8c00-ec85b4c1-d26e7f24 (built-in API)

I0918 08:33:51.719671 CommandDispatcher.cpp:913] DUL Peer Requested Release

I0918 08:33:51.719705 CommandDispatcher.cpp:920] Association Release

I0918 08:33:51.721251 CommandDispatcher.cpp:507] Association Received from AET MV300_3110 on IP 172.17.0.1

I0918 08:33:51.767816 main.cpp:195] Incoming connection from AET MV300_3110 on IP 172.17.0.1, calling AET XNAT-ROUTER

I0918 08:33:51.768060 CommandDispatcher.cpp:710] Association Acknowledged (Max Send PDV: 16372)

I0918 08:33:51.768885 CommandDispatcher.cpp:913] DUL Peer Requested Release

I0918 08:33:51.768917 CommandDispatcher.cpp:920] Association Release

I hope this may give You some more information. If not please let me know, I will try to create more logs.

B.

W dniu wtorek, 17 września 2019 15:29:26 UTC+2 użytkownik Sébastien Jodogne napisał:

4

I have identified broken DICOMs. They come from rf mapping service sequence. If I send them to Horos/XNAT that series is just omitted. Can You tell me how to do the same with Orthanc?
B.

W dniu środa, 18 września 2019 10:57:04 UTC+2 użytkownik Bartosz Kossowski napisał:

MR000000.dcm (105 KB)

5

I have tried using ReceiveFilter but is does not help - DICOM communication still breaks on that file.

function ReceivedInstanceFilter**(dicom, origin)**

if dicom.SeriesDescription == ‘rf_map’ then

return false

else

return true

end

end

W dniu środa, 18 września 2019 11:30:26 UTC+2 użytkownik Bartosz Kossowski napisał:

6

I have tested your Lua script on your “MR000000.dcm” file, and it properly discards it.

So, your script is OK but the issue is elsewhere.

7

Then my problem is can’t send that file from one Orthanc to another. When the file is in a middle series the communications breaks down immediately and following series are not send. However, XNAT or Horos do receive all the following data from the same Orthanc instance apart from the broken files.
I’d expect the same from Orthanc to prevent from data loss.
B.

8

Again, please provide a complete minimal working example:
https://book.orthanc-server.com/users/support.html

9

Never mind. I can somehow overcome the problem by sending series separately one by one.
B.

W dniu czwartek, 19 września 2019 08:38:29 UTC+2 użytkownik Sébastien Jodogne napisał: