| reicht | |
| Aug 7 2014, 5:34 PM |
| F1133: DCM_log_petersen_20150827.txt | |
| Aug 27 2015, 9:06 AM |
Hi,
Installed the official release version 2014-03 of MITK on Win7 64bit. When performing DICOM Q/R, query works as expected, but receive does not. In the statusbar of the plugin following information is rendered: "Failed to start storage provider: No such file or directory"
Performed DIOCM Q/R on wDB - tested Q/R on the same machine with other software and worked. wDB seems to be configured correctly.
attached a file of of the MBIlog output.
cheers
Tried to reproduce this on Linux with current master.
Initial console output is the same as in attachment.
Additionally, the transfer is marked as successful:
GET responses report for study: 1.2.276.0.7230010.3.1.2.69332360.5336.1415132775.623
1 images transferred, and
0 images transferred with warning, and
0 images transfers failed
Retrieve success
... but no image is transferred to local storage.
The DCMTK module has two executable storescp files, in DCMTK-install and -build.
When running the DICOM plugin, the path points to the install folder. This executable is not runnable from console, but the one in the build folder is.
Is there any difference?
(In reply to Nils Lichtenberg from comment #2)
Tried to reproduce this on Linux with current master.
Initial console output is the same as in attachment.
Additionally, the transfer is marked as successful:
GET responses report for study:
1.2.276.0.7230010.3.1.2.69332360.5336.1415132775.623
1 images transferred, and
0 images transferred with warning, and
0 images transfers failed
Retrieve success... but no image is transferred to local storage.
The DCMTK module has two executable storescp files, in DCMTK-install and
-build.
When running the DICOM plugin, the path points to the install folder. This
executable is not runnable from console, but the one in the build folder is.
Is there any difference?
I think this error mainly occurs within the workbench installer. Maybe the dcmstorescp is not considered during packaging
This bug could not be fixed during the 2015.05 release.
Setting target_milestone to AfterNextRelease
Could someone confirm that the executable is completely missing in the installer? Does it work if started from the build tree?
I just built the latest master and it works (Ubuntu 14.04).
However, it's not possible for me to change the port for the SCP. I would expect that upon changing the storage port (maybe a "restart SCP" button would be nice too) the SCP is restarted on the new port. If I change the port, close the DICOM plugin and reopen it, I think it tries to start the SCP on the specified port, but fails. If I again change the port to 11112, close and reopen, it works fine.
The actual retrieval is still not working, will test this in more detail later.
Retrieval is not working for me, regardless of whether I check CGET or not. Tested with the dicomserver.co.uk, find requests work fine. When I click retrieve, the GUI freezes for a couple of seconds and then comes back, with the local dicom storage still empty.
Maybe an attempt at retrieval is made (but not in a new thread?), but the saving process fails? Where would received files be stored?
In part answering my own question, I attached the log from my attempts.
Also, is this beyond the scope of this bug?
The storescpd executable (and all other DCMTK executables) are built in superbuild/ep/bin and also in superbuild/ep/src/DCMTK-build/bin, while the application uses the former? Is there a reason for this?
(In reply to Jens Petersen from comment #12)
The storescpd executable (and all other DCMTK executables) are built in
superbuild/ep/bin and also in superbuild/ep/src/DCMTK-build/bin, while the
application uses the former? Is there a reason for this?
Most 3rd party toolkits in the superbuild (including DCMTK) are installed using "make install" to ep/bin , ep/lib, ep/include ... , so this is correct.
From the FSE perspective yes, because quite a view researchers within FSE want to use MITK-QR to access the wDB.
User goch has pushed new remote branch:
bug-17984-include-dicom-storescp-in-installer
[88821f]: Merge branch 'bug-17984-include-dicom-storescp-in-installer'
2016-04-07 15:57:56 Caspar Goch [44ea30]
Add required keyword when calling install macro